The Centralized Agent Gateway: What DoorDash Got Right and What Most Enterprise Architectures Still Get Wrong

When organizations begin deploying AI agents at scale, the first infrastructure problem they encounter is rarely the model. It is access. Each agent needs credentials, each team builds its own auth flow, and within a few months the enterprise is running a dozen parallel approaches to the same problem with no visibility across any of them. DoorDash's decision to centralize agent-tool connectivity through a dedicated gateway layer addresses this directly, and the architectural reasoning behind it offers a useful frame for any engineering leader currently watching their agent footprint grow faster than their ability to govern it.

Companion piece to our broader work on enterprise agent infrastructure. See Internal MCP Gateway: Enterprise Agent Architecture for access control patterns and context quality constraints when connecting AI agents to internal systems at scale.

The Problem With Per-Agent Auth Wiring

The default pattern in most enterprises is straightforward: the team building an agent also builds the connection to whatever tools that agent needs. This produces working software quickly, which is why it persists. The mechanism that makes it dangerous is duplication of trust surface area. Every new agent that owns its own credentials creates a new point of exposure, a new rotation schedule to miss, and a new audit trail that lives outside any centralized view.

The operational cost compounds faster than teams anticipate. When credential rotation is required, whether by policy or incident response, the work is proportional to the number of independent stores rather than the number of logical services. At ten agents this is inconvenient. At fifty it is an incident in waiting.

The deeper issue is that per-agent wiring makes policy enforcement structurally impossible. If each agent negotiates its own access to a downstream API, there is no single place to apply rate limits, audit logging, or scope restrictions uniformly. Governance becomes a documentation exercise rather than an architectural property.

What the Gateway Model Actually Changes

A centralized agent gateway interposes a dedicated infrastructure layer between agents and the tools they call. Agents do not hold credentials directly. They authenticate to the gateway, declare intent, and the gateway handles downstream auth on their behalf. This shifts credential custody from the application layer to the infrastructure layer, which is where it can actually be managed.

The practical implication is that rotating a downstream API credential becomes a single operation regardless of how many agents consume that tool. The gateway holds the secret; the agents hold only a scoped token that identifies who they are and what they are permitted to request. Revocation is equally centralized.

Per-agent tool scoping becomes enforceable at the gateway boundary rather than by convention. An agent provisioned for customer support workflows can be restricted from calling internal financial APIs not because the financial API has been configured to reject it, but because the gateway will not route that request category at all. This is a meaningful security property: the restriction does not depend on the downstream system behaving correctly.

OAuth Delegation and the Credential Routing Question

The credential routing model that makes this work in practice typically relies on OAuth delegation patterns. The gateway acts as an authorization server proxy, issuing short-lived downstream tokens scoped to the specific tool and operation the agent has been provisioned to use. The agent presents a gateway-issued assertion; the gateway exchanges it for a downstream credential with the appropriate scope.

This matters because it preserves the downstream system's native auth model while abstracting it from the agent developer. The team building an agent does not need to understand the OAuth flow for each API they want to call. They register the tool requirement with the gateway, the gateway handles the exchange, and the agent receives a result. The credential complexity is contained at the infrastructure layer rather than distributed across every agent codebase.

The tradeoff worth naming is latency. Every tool call that routes through a gateway adds a hop. For synchronous, user-facing workflows this requires careful measurement. For async agent pipelines, which represent the majority of enterprise use cases, the overhead is generally acceptable and the operational benefits justify it.

Where Multi-Agent Architectures Create New Pressure

Single-agent deployments expose the credential management problem. Multi-agent architectures expose the authorization inheritance problem. When an orchestrator agent delegates a subtask to a worker agent, the question of what permissions the worker inherits is not trivial. Without a gateway layer, the answer is often whatever credentials the worker was provisioned with at build time, which may be broader or narrower than the task actually requires.

A centralized gateway can enforce scoped delegation explicitly. The orchestrator presents a delegation token that constrains what the worker is permitted to do within that task context. The worker cannot exceed the scope of the delegation even if its base provisioning would otherwise permit it. This is the architectural equivalent of least-privilege applied to agent-to-agent communication, and it is not achievable when each agent manages its own auth independently.

The audit trail benefit is equally significant. When every tool call passes through a single gateway, the log of what each agent did, on whose behalf, and with what authorization is a single coherent record. Reconstructing an agent's behavior during an incident review becomes a query against one system rather than an archaeology exercise across a dozen independent logs.

The Operational Gaps That Persist Even With a Gateway

A gateway solves credential custody and routing. It does not solve context quality, which is a separate and equally important failure mode. An agent that has clean access to a tool can still produce poor results if the context it passes to that tool is malformed, incomplete, or misaligned with what the tool expects. We have written about this distinction in detail in our work on internal MCP gateway implementations, where access control and context quality turn out to be independent axes of failure.

The other gap is provisioning governance. A gateway is only as useful as the discipline applied to what gets registered in it. If teams can self-serve tool registrations without review, the gateway becomes a well-instrumented version of the original problem rather than a solution to it. The architectural pattern requires an accompanying process for approving new tool scopes, reviewing provisioning requests, and periodically auditing active registrations against actual usage.

Finally, gateway availability becomes a critical dependency. When every agent routes tool calls through a single layer, that layer's reliability directly determines the reliability of every agent in the estate. This is an argument for investment in the gateway's operational posture, not an argument against centralization, but it is a cost that needs to be planned for rather than discovered.