A gateway only governs what routes through it

An engineer added an MCP server this morning. It reads from your production database and it took about four minutes to set up.

It did not route through your gateway.

That is not defiance and it is not a policy failure. He did not know there was a gateway to route through, because nothing in the act of adding an MCP server tells you that. The config file asked for a command and some arguments, he gave it a command and some arguments, and it worked.

Gateways are genuinely good at their job#

Worth being clear, because the criticism that follows is narrow.

A gateway that sits in the path of a call is real enforcement. Not a hook that can be skipped, not a check that fails open under load. The request physically passes through it, so a refusal there actually refuses. You get a chokepoint, one place to write policy, one place to log, and it works whatever is on the other end.

We use the same shape ourselves for model traffic. Route an agent's model calls through a per-agent credential and you get metering, attribution and a budget that stops the eleven-millionth token from ever leaving, rather than a dashboard that reports it afterwards. That is the gateway pattern, and it is the right pattern.

The critique is not that gateways are weak. It is that a gateway's coverage is exactly its configuration, and configuration is the part that decays.

What routes around one, in practice#

Not hypotheticals. This is the ordinary week of a normal engineering org.

A new MCP server. Added to a local config, launched as a subprocess, talking to whatever it talks to. There is no step where anyone was prompted to point it at a gateway.

A coding agent's built-in tools. The shell, the file writes, the git operations. Those never touch a model gateway at all, because they are not model calls. They are the agent doing things to your machine and your repositories.

A direct API call. An agent with a token calling your internal service. If the token works from anywhere, the gateway is one of the places it can be used, not the only one.

A vendor's agent. The one your CRM turned on in a product update. It runs in the vendor's cloud, calls the vendor's models, and reaches your data through an integration you approved years ago. It will never route through anything of yours.

Every new tool, on the day it arrives. Coverage is not a state you reach. It is a state you maintain against a stream of new tools, each of which defaults to not routing through you.

Opt-in by configuration versus opt-in by necessity#

This is the whole distinction, and it is worth stating carefully because it is the difference between a control that decays and one that does not.

A gateway is opt-in by configuration. Someone has to point traffic at it. That works beautifully for traffic somebody remembered to point, and it silently excludes everything else. The failure is quiet: nothing errors, nothing alerts, the tool just works and the gateway simply never sees it.

A credential is opt-in by necessity. An agent cannot reach your database without a database credential. It cannot push to your repository without a token your git host accepts. It cannot call your internal API without something that authenticates. There is no version of doing the work that skips the credential, because the credential is the work.

Same for the resource. Every path to your git host ends at your git host. Configure around a proxy all you like: the push still arrives at the door, and the door is yours.

That is why we put the decision at the keys and the doors. Not because a chokepoint is a bad idea, but because we want the chokepoint at the one place nothing can route around: the place the action was always going to arrive.

The honest version of the trade#

A gateway gives you something the credential does not: it sees the request in flight, so it can act on the content of a call, shape it, cache it, rewrite it. That is real, and if what you need is model-level policy on model traffic, a gateway is the right tool and you should buy one.

What it cannot give you is coverage of things nobody pointed at it. And it is worth noticing that the two are not competitors. The strongest arrangement is both: route what you can, and put the decision at the credential and the resource for everything else, so the coverage does not depend on whether an engineer knew about a config value.

The question to ask#

To any vendor whose answer to governance is a gateway, including where we use the pattern ourselves:

An engineer adds an MCP server this afternoon and does not point it at you. What happens?

If the answer is a policy document or a training session, that is a hope, not a control.

If the answer is that the credential it needs was never issued for that system, or that the door it arrives at refuses it, that is a control, and it did not need anybody to remember anything.

The agents that most need governing are the ones nobody configured. That is the case worth designing for.