The MCP gateway pattern: one controlled door to every server

Direct MCP connections are how everyone starts: each client config points straight at each server, credentials live in each config, and every laptop is its own perimeter. That is fine for five developers and three servers. At fifty developers and thirty servers it becomes ungovernable — you cannot answer “who called what”, you cannot revoke one credential without touching every machine, and your allowlist is a wiki page nobody reads.

The gateway pattern fixes this with one move: put a single controlled door between all clients and all servers. Every MCP request goes through it; nothing else is reachable.

What a gateway actually does

A gateway is an MCP-aware proxy. Because MCP is JSON-RPC over a transport, the gateway can understand the traffic it forwards — it knows the difference between tools/list and tools/call, and it can see tool names and arguments. That awareness is what enables each control:

• Auth termination. Clients authenticate once, to the gateway, with organizational identity (your IdP — the Enterprise-Managed Authorization extension, stable July 2026, makes this SSO-native). The gateway then holds and injects the per-server credentials upstream. Developers never handle server secrets; rotating a credential touches one place. The gateway must mint or exchange proper tokens for upstream servers — never forward the client’s inbound token, which the spec explicitly forbids as token passthrough.
• Allowlisting. The gateway maps identity → permitted servers. A server not on your team’s list is simply not routable, regardless of what a local config file claims. This turns the paper allowlist from your governance process into an enforced one.
• Tool filtering. Approving a server rarely means approving all its tools. The gateway filters the tools/list response — the model never sees the removed tools — and rejects tools/call for anything filtered, in case a client misbehaves. Filtering the list also cuts context cost, since every exposed tool definition is paid for on every request (see controlling token cost).
• Logging. One choke point sees every tool call from every user. This is the audit trail, in one place, in one format.
• Rate limits and quotas. Per-user and per-server caps stop a looping agent from hammering a production API at machine speed, and give you a budget lever per team.

Architecture options

There are three realistic shapes, and they differ mainly in where enforcement lives.

Option 1 — Central gateway service

One shared service (highly available, behind TLS) that all clients connect to over Streamable HTTP. Server-side allowlists, central credential vault, one log stream.

graph LR
  A[Claude Code] --> G[MCP Gateway]
  B[Claude Desktop] --> G
  C[VS Code / Cursor] --> G
  G --> S1[Internal DB server]
  G --> S2[Ticketing server]
  G --> S3[Vendor SaaS server]
  G --> L[(Audit log)]

This is the strongest posture: enforcement is server-side, so nothing a user edits locally widens their access. It is also the biggest lift — you are now operating a piece of critical infrastructure with uptime expectations, because when the gateway is down, all agent tooling is down.

Option 2 — Sidecar proxy

A small proxy process runs next to each client (on the developer’s machine or in the same pod), and local stdio servers plus remote connections route through it. Configuration for the sidecar is pulled from a central policy service.

You keep low latency and stdio compatibility — the sidecar can wrap local processes that a remote gateway never could — and you still get uniform logging and filtering. The weakness is that enforcement runs on hardware the user controls; a determined developer can bypass a local proxy. Pair it with config management and treat it as guardrails for the honest majority, not a security boundary against insiders.

Option 3 — Client-config-only control

No proxy at all: you centrally manage the client configuration files (.mcp.json in repos, managed claude_desktop_config.json on desktops) so that only approved servers appear. Cheapest by far, and where most organizations should start.

Its limits are structural: no central log (you rely on per-client logs, where they exist), no tool filtering beyond what each client offers, credentials still distributed to endpoints, and enforcement is only as strong as your config-drift detection.

Choosing

	Enforcement	Logging	Ops cost	Best for
Central gateway	Server-side, strong	Complete, one stream	High	Org-wide rollouts, regulated environments
Sidecar proxy	Local, bypassable	Complete if sidecar honest	Medium	stdio-heavy fleets, mixed local/remote
Config-only	Convention + review	Fragmented	Low	Pilots and small teams

Verdict: start config-only during your pilot, and move to a central gateway the moment you have write-capable tools or more than a handful of teams. Use sidecars only where stdio servers genuinely cannot be replaced by remote equivalents.

What to log — and what to redact

Log every tools/call with:

• Timestamp, user identity, client application, session identifier.
• Server name and version, tool name.
• Arguments — redacted at capture. Hash or mask values for argument keys matching your sensitive patterns (password, token, ssn, free-text bodies over a size threshold). Redaction must happen before the log line is written, not in the reporting layer; once a secret is in the log pipeline you have a second incident.
• Decision: allowed / denied-by-allowlist / denied-by-filter / rate-limited, and whether a human approved the call.
• Outcome: success or error code, duration, and response size (response size, not response content — logging full tool results re-creates your data-exfiltration problem inside the log store).

Also log the control plane: allowlist changes, credential rotations, filter updates — each with who and why. During an incident, “what changed” is the first question.

Two log-review habits pay for themselves: alert on denied-call spikes (an agent repeatedly hitting a filtered tool is either a broken prompt or something worse), and alert on new-tool appearance — if a server’s tools/list response changes between versions, that is a re-review trigger, because tool definitions are an attack surface (see the threat model).

Trade-offs versus direct connections

Be honest about what the gateway costs you:

• Latency. One extra hop per call. For remote servers this is usually negligible against LLM inference time; for chatty local stdio tooling it can be noticeable.
• Availability coupling. The gateway is a single point of failure. Run it like production, because it is.
• Protocol lag. The gateway must keep pace with the spec. As of 2025-11-25 that means Streamable HTTP, the MCP-Protocol-Version header, and OAuth resource-server semantics; the 2026-07-28 revision’s stateless core (removing the initialize handshake and Mcp-Session-Id) lands soon and will actually make gateways simpler — stateless requests are far easier to proxy and load-balance. Budget for that migration.
• A rich target. The gateway concentrates credentials and traffic, so it inherits your hardest security requirements: audience-validated tokens on both legs, no passthrough, private-IP egress blocking (SSRF), and its own audit trail.
• Developer friction. If adding a server through the gateway takes weeks, developers will route around it with local configs. Keep the intake path fast, and treat bypass attempts as a signal about your process, not just about the developer.

Direct connections keep none of the control but all of the simplicity. The honest framing: direct is a development posture, gateway is a production posture — the same distinction you already apply to databases, which no one queries from a laptop with shared admin credentials either.

Where this fits

The gateway is the enforcement layer for the paper controls in the governance framework, and its logs are the raw material for the audit trail that framework demands. For hardening the servers behind the gateway — audience validation, origin checks, session handling — work through the security hardening tutorial next.