An agent gateway needs a bypass budget

In short: An agent gateway becomes a control only when teams measure direct-call bypasses, credential exceptions, ownership gaps and revocation time.

DoorDash reported on 30 July 2026 that its Agent Gateway had more than 200 MCP servers, more than 30 agents and services, thousands of employee users and millions of tool calls each week. Those are substantial adoption numbers. They still do not answer the control question: how much agent traffic can go around the gateway?

An agent gateway becomes a control only when the enterprise measures the bypass path as carefully as the governed path. My proposed scorecard has four numbers: governed-call share, raw-credential exceptions, tools without an accountable owner, and tested revocation time. Registration counts show inventory. A bypass budget shows whether the inventory actually governs anything.

DoorDash's agent gateway makes the governed path concrete

DoorDash's engineering account is unusually useful because it describes the boring production layers around MCP. The proxy authenticates a caller, checks policy, applies rate limits, injects the right credential, routes the request and emits telemetry. The registry holds agents, servers, owners, auth modes, policies and filtered tool surfaces.

That separation matters. An MCP server can advertise hundreds of operations while a workflow needs five. DoorDash bundles selected tools from several servers into one task-shaped endpoint, then applies policy during both discovery and execution. The agent sees a curated product surface, not the organisation's entire capability catalogue.

The official MCP authorization specification defines transport-level OAuth behaviour for HTTP, including audience-bound tokens and per-request authorization. It also says authorization is optional for MCP implementations. Even perfect protocol compliance on one server cannot tell a platform owner whether another team copied an API key into an agent and connected directly.

That is the missing denominator. DoorDash says the gateway is the default path and reports millions of governed calls. It does not publish the number of direct connections, copied secrets or unregistered tools outside that path. This is not a criticism of DoorDash; those may be internal measures. It is the measurement gap another enterprise must close before borrowing the architecture diagram.

A bypass budget turns gateway adoption into a control

I would review an agent gateway as a migration programme, not as a launch. Start with governed-call share: of all detectable agent-to-tool calls, what proportion passed through the policy point? The denominator will be imperfect at first. That is useful. Unknown traffic is itself an inventory failure, not a reason to report only the clean numerator.

Then count raw-credential exceptions. DoorDash says none of its gateway users handle raw credentials. The MCP security guidance forbids token passthrough because it can bypass rate limits, validation and monitoring while damaging attribution. A temporary exception may be necessary during migration, but it needs an owner and an expiry date.

Third, count tools without an accountable owner. Ownership is what turns a failed call or a policy change into work somebody must accept. A registered tool with no team responsible for its description, scopes, failure modes and retirement is governed only on paper.

Finally, test revocation time. Do not ask whether a kill switch exists. Disable one low-risk credential or bundle in a rehearsal, measure how long enforcement takes, and verify that new calls fail while the audit trail preserves who acted and why. This extends my earlier argument in MCP needs revocation before reach: after you build the off switch, measure whether it covers the routes people actually use.

rendering diagram…

The budget is not zero on day one. It is a declared maximum with a direction, an owner and a review date. An undeclared exception is shadow infrastructure. A declared exception is migration work.

My practitioner judgment is to reward migration, not registration

This is labelled editorial judgment, not a DoorDash deployment I reproduced at Trigent or for a client. If I were reviewing an enterprise rollout, I would put the four bypass measures beside the usual platform numbers and refuse to call the gateway complete while the exception column could only grow.

The reason is behavioural. Platform teams naturally celebrate what their system can count: registered servers, published tools, connected agents and gateway calls. Teams going direct are harder to see, so the dashboard makes the paved road look more universal than it is. A bypass budget forces the review to search for the missing traffic.

It also changes incentives. If the governed path is slow, teams will route around it. DoorDash's self-service onboarding is therefore a control property, not developer-experience polish. The platform must make the safe route easier than copying a secret, while detection makes the unsafe route visible enough to retire.

I could not independently reproduce DoorDash's scale, inspect its internal bypass data, or verify a reduction in incidents or model errors. The public evidence supports the architecture and reported adoption. The four-number budget is my synthesis for testing whether that architecture has become the default in another organisation.

What's in it for you

Add governed-call share and raw-credential exceptions to the next agent-platform review.
Give every direct connection an owner, expiry date and migration decision.
Rehearse one low-risk revocation and record the enforcement time, not just the button click.

Do not call an agent gateway governed because it has many registrations; call it governed when bypasses are visible, owned and shrinking.