Every tool behind one MCP gateway. One breach reaches all of them.

You are wiring a fifth MCP server into your agent and the config has become a thicket: five endpoints, five credential blobs, five transports to keep straight. A gateway collapses that to one connection, and that convenience is the whole reason teams reach for one. The decision in front of you carries more weight than the config cleanup suggests. You are choosing whether every tool your agent can touch now shares one front door, one credential store, and one process that takes all of them down when it degrades.

An MCP gateway is one server that fronts many MCP servers, merging their tools into a single endpoint and brokering auth, credentials, and policy on every call. Run one when you have several servers that need shared authentication, one audit trail, or a central kill switch. Before you do, size the propagation radius: a gateway that holds every tool’s credentials inherits the union of every tool’s permissions the moment it is compromised, and takes every tool offline the moment it stalls. Skip that sizing and your first outage takes down everything at once, and your first breach reaches every integration the gateway can touch.

What is an MCP gateway?

An MCP gateway is one server that sits between your agent, the MCP client, and many MCP servers, doing three jobs a direct connection does not. It aggregates: the agent connects once and sees one merged list of every server’s tools, prompts, and resources. It brokers: it authenticates the caller, holds the upstream credentials, and applies access policy before a call lands. It observes: every invocation flows through one place, so one log captures the whole surface.

The word that trips people up is proxy. An MCP proxy server also sits inline and forwards MCP traffic, and many proxies bridge transports, wrapping a local stdio server so a remote client can reach it over HTTP. What a proxy does not do is form an opinion. It moves bytes between a client and a server without deciding who the caller is, which credential to attach, or whether the call is allowed. A gateway is the proxy that took on identity, credential brokering, and policy. Every gateway is a proxy; most proxies are not gateways.

MCP proxy server vs MCP gateway: the difference is who holds the policy

Short answer: a proxy forwards MCP traffic without deciding who the caller is, which credential to attach, or whether the call is allowed; a gateway makes all three of those decisions and merges every server’s tools into one endpoint. The three topologies differ on one axis that decides everything downstream: where identity and policy live. Read the table by that column, and the failure surface in the next-to-last row follows from it.

The verdict: a direct connection contains a failure to one tool and scatters your credentials; a gateway contains your credentials to one vault and scatters a single failure across every tool. You are choosing the shape your risk takes: many small contained failures, or one large correlated one.

An MCP architecture diagram makes that axis literal in a way the table cannot. In a direct topology the agent draws a separate credentialed line to each server, so keys and connections fan out one-to-one and one server going dark removes only its own tools. In a gateway topology those lines collapse into a single box that holds every key and exposes one merged tool list, which makes that same box both the single credential store and the single point of failure: a compromise there inherits the union of every server’s permissions, and a stall there takes all of the tools offline at once. The shape of the wiring is where the credentials and the failures live.

Docker’s MCP Gateway is the reference build to reason from

The clearest concrete gateway to study is Docker’s, because it is open source under the MIT license and its docs spell out the defaults.¹ Docker frames it plainly: the Docker MCP Gateway is “a centralized proxy between clients and servers, managing configuration, credentials, and access control,” and when a call arrives “the Gateway identifies which server handles that tool.”² That is the aggregation-plus-brokering shape stated as a product.

Four of its defaults map straight onto the failure modes below:

• Container isolation. It runs each MCP server “in isolated Docker containers with restricted privileges, network access, and resource usage.”² Isolation is how you keep one bad server from becoming a bad gateway.
• Scoped secrets. Credentials “are mounted only into the target container at runtime, nothing else can see them,” so a token for one server does not sit in ambient reach of another.³
• Supply-chain checks. On pull and run it does “provenance verification, ensuring Docker built the image, checking for an SBOM, and running supply-chain checks (via Docker Scout).”³ The gateway is the natural chokepoint to verify what you are about to execute.
• Tool filtering and one log. You can “filter tools, prompts, and resources so the client only gets the subset you want,”³ and built-in “logging and call-tracing” give you a single trace of every tool call.²

That tool filtering is also the least-privilege lever the closing section calls for, and it is two commands to pull:

# Allow one profile only the two tools this agent needs
docker mcp profile tools dev-tools --enable github.create_issue --enable github.list_repos

# Front those servers as one endpoint (default stdio transport)
docker mcp gateway run --profile dev-tools

The --enable allowlist is where “least privilege” stops being advice and becomes a flag.¹

Those are real reliability primitives. They also describe, feature by feature, exactly how much a single process is now responsible for. A gateway that filters tools, mounts secrets, verifies images, and logs every call is a gateway whose compromise or outage touches all of that at once.

The MCP gateway field: what actually runs one

Docker’s is the easiest to reason from, but it is one of several. The ones worth knowing differ mostly in what they layer on top of the multiplexing, and every one of them inherits the same concentration problem this page is about.

• Docker MCP Gateway (MIT) runs each server in an isolated container with scoped secrets and supply-chain checks, the reference build above.¹
• IBM ContextForge (Apache-2.0) is “an open source registry and proxy that federates MCP, A2A, and REST/gRPC APIs with centralized governance, discovery, and observability,” pushing the gateway toward a full service registry.⁴
• agentgateway (Apache-2.0), a Linux Foundation project, is a Rust data-plane proxy for “AI Agents and MCP servers” with OAuth and JWT auth and fine-grained RBAC through a policy engine, aimed at teams that already run a mesh.⁵
• Lasso mcp-gateway (MIT) is a “plugin-based gateway that orchestrates other MCPs,” built security-first: it masks secrets and PII in responses and scans a server’s reputation before loading it.⁶

Managed commercial gateways exist too, sold on hosted policy and observability. Whichever you pick, the reliability read is identical: the more a gateway centralizes, the more its single compromise or single stall is worth, so judge it on how hard it makes per-server credential scoping and how easily you can run more than one of it.

The gateway becomes your credential vault, for better and worse

Once a gateway brokers auth, it inherits the role the MCP spec assigns any protected server. A protected MCP server “acts as an OAuth 2.1 resource server,” and the authorization spec requires that servers “implement OAuth 2.0 Protected Resource Metadata” (RFC 9728) while clients “use OAuth 2.0 Protected Resource Metadata for authorization server discovery.”⁷ The discovery flow is three hops:

1. The server answers an unauthenticated call with a 401 and a WWW-Authenticate header.
2. That header points the client at resource metadata, which names the authorization server.
3. The authorization server, embedded in the gateway or run separately, issues a token the client replays.

A gateway typically plays resource server for many upstreams at once and brokers a token for each.

That is the convenience. One place does the OAuth dance, the agent never handles a raw provider token, and rotation happens centrally. The cost is that the one place now holds many services’ keys. OWASP’s MCP guidance is blunt about the failure this invites: the confused deputy, where “the MCP server executes actions with its own (often broad) privileges, not the requesting user’s permissions,” and broad-scope aggregation, where a server that requests “full Gmail access vs. read-only” turns every over-broad grant into shared exposure.⁸

OWASP’s standing recommendation runs the other way: treat each MCP server as an “untrusted, independent security domain,” give each one credentials scoped to its own needs, and “never share tokens across servers.”⁸ A gateway is the design that makes sharing tokens the path of least resistance, so it is the design that has to work hardest to follow that advice.

A gateway holds the keys to every service it fronts. That is the feature. It is also the thing an attacker only has to reach once.

Aggregation is the feature and the failure mode

A gateway concentrates two things that reliability engineering usually wants spread out: permission and availability. Take them one at a time, on round schematic numbers so the shape is clear, then name the quieter third failure that rides along.

Permission: every key on one hook

Permission first. Put ten tools behind one gateway and the gateway, to broker on their behalf, holds credentials that sum to all ten tools’ access. The propagation radius of that one process, the reach of a single compromise, is the entire toolset. A direct-connection agent that leaks one server’s token leaks one tool; a gatewayed agent that leaks the gateway leaks ten. Consolidating credentials hangs every key on one hook, and the gateway’s endpoint is the label that tells an attacker where the hook is.

Availability: no sibling to route around

Availability second. Suppose the gateway is healthy 99% of the time and each of five servers is independently healthy 99% of the time. Wire the servers directly and a bad minute costs you one tool: the other four keep working, and a failure contains itself to the one server that broke. Put them behind the gateway and the gateway’s own 1% of bad minutes takes all five down together, no matter how healthy the individual servers are that minute. On those round numbers the gap is stark: the gateway’s 1% of bad minutes is roughly 14 minutes a day of every tool going dark at once, while all five independent 99% servers failing in the same minute is 0.01 to the fifth power, well under a second a year. The gateway sets a floor on your total-outage rate that no amount of server reliability can lift, because a gateway fault is uncontainable by construction: there is no sibling to route around it. That is a cascade-resistance property, and a single-front-door topology has the worst of it.

Degradation: the quietly wrong state

The subtler failure is degradation. A gateway that stays up but slows down, or silently drops a server from its merged tool list, hands the agent a well-formed-but-wrong view of what it can do. An orphaned or missing tool that the agent still plans around is exactly the kind of quietly wrong state that propagates instead of stopping, and it does so from a component every request already trusts. The related pain at the session layer, when a gateway routes by a session ID the protocol is about to delete, gets its own teardown: the MCP session removal hits sticky-routing gateways first.

A gateway relocates reliability. You move failure from many small contained events to one large uncontained one, and you move credentials from many small leaks to one total one. Whether that trade is good depends entirely on whether you can make the gateway more reliable than the sum of what it fronts.

When do you actually need an MCP gateway?

The trade pays off in a recognizable shape. Reach for a gateway when three or more servers need the same authentication and policy, when compliance wants one audit trail and one kill switch over all tool use, or when several clients must be handed an identical, filtered server set without configuring each one. Docker’s container-per-server isolation and scoped secrets are built for exactly that multi-server, multi-client governance case, and they are a genuine upgrade over hand-rolled fan-in.

Stay with direct connections when you have one or two servers you already trust, or when you cannot make the gateway redundant. A single gateway instance in front of everything, with no failover and no monitoring of its own health, is a single point of failure you built on purpose. If you run a gateway, run it the way its concentration demands:

• More than one instance behind health checks, so a single fault has a sibling to route around.
• Per-server scoped credentials, so a compromise is not automatically total.
• Tool filtering set to least privilege, the --enable allowlist from the Docker section.
• Its own trace watched at least as closely as any server it fronts.

The design that centralizes your risk has to be the most reliable thing you operate, because everything downstream inherits its bad minutes.

To take the concentration seriously as a measured reliability lever, budget it: work the end-to-end availability math and the per-step failure budget in reliable AI agents in production, and if the gateway is fanning tools out to subagents, the topologies that keep a single fault local are in multi-agent orchestration patterns. Put the gateway itself on the list of things whose health you score, alongside every server it fronts.