Per-host MCP configs do not scale past 10 developers. The pattern that does is a gateway: a central control plane that authenticates, scopes, rate-limits and audits every MCP call across the org. Here is what to build, what to centralise, and the migration path that does not break anyone.
Why a gateway, not just per-host config
Three problems the gateway solves and per-host config cannot:
- Credential spread — a hundred laptops each with a copy of a production token is not a security model.
- Policy drift — a change to a tool scope reaches some hosts immediately and others in three weeks.
- No audit — without a central choke point, you cannot answer "what did this user touch last Thursday?"
The gateway becomes the one place credentials live, the one place scopes are defined, the one place audit is collected.
What the gateway centralises
Four responsibilities:
- Authentication — every host identifies itself with a short-lived token; gateway validates against an IdP.
- Authorisation — every tool call is checked against a policy: this user, for this tool, with these arguments?
- Rate limiting — per-user and per-tool caps to stop runaway agents from bankrupting you.
- Audit — every call logged to an append-only store. Feeds the audit trail.
Tool implementation stays at the upstream MCP server. The gateway is policy + visibility, not business logic.
Reference architecture
agent host (laptop)
│ stdio: bridge MCP client
▼
local bridge process
│ HTTPS + SSE, mTLS
▼
MCP gateway (HA pair)
│ policy decision · rate limit · audit
▼
upstream MCP servers (postgres, github, internal)
The local bridge keeps host-side configs small (one entry: the gateway URL) and translates between stdio (what hosts speak) and HTTPS (what the gateway accepts).
Deployment patterns
Three viable patterns:
Sidecar
A bridge runs alongside each Claude Desktop / Cursor instance. Lowest latency. Simplest to roll out. Cannot enforce auth on hosts that bypass it.
Central
One regional gateway per region. Stricter, audit-complete, tolerates rogue hosts. Adds 30–80 ms latency.
Hybrid
Sidecars for low-risk dev tools, central gateway for production-touching tools. Most enterprises land here.
A minimal policy
Policies live as YAML in version control:
- subject: { group: data-platform }
resource: { server: postgres-prod }
action: read
conditions:
schemas: [public, analytics]
rate_limit_per_minute: 60
- subject: { group: support }
resource: { server: zendesk }
action: ['*']
conditions:
rate_limit_per_minute: 30
Gateway evaluates the policy on every tool call. Decisions are cached for 30 seconds; updates roll out via gitops in minutes.
Migration path
Don't bolt the gateway in front of an established fleet on day one. Stage:
- Shadow — bridge sends every call through both the gateway and the legacy direct path; gateway only logs.
- Enforce non-prod — flip the gateway to enforcement for non-prod tools first.
- Enforce prod read-only — production reads first; writes still direct.
- Enforce prod writes — last, after a full month of clean shadow data.
Total migration: 6–10 weeks for a 50-developer org.
What to leave at the host
Three things the gateway should not touch:
- Personal-scope dev tools — local filesystem, scratch repos. Not worth the policy churn.
- Synchronous low-latency reads — schema introspection on a developer's laptop database. Bridge directly.
- Offline workflows — flights, dev environments behind no internet. Have a fallback config.
Audit and compliance hooks
Wire the gateway to:
- An immutable audit store (S3 with object-lock or a managed log) for retention.
- Your SIEM for anomaly detection on tool-call patterns.
- Your IdP for identity, no local accounts.
This satisfies most SOC2 and EU AI Act audit requirements. See the EU AI Act guide for specifics.
Build vs buy
A working gateway is roughly 1 engineer-month. Three managed offerings exist as of 2026 (search "MCP gateway" on this site). Buy if you want it running in a week; build if your policy needs are unusual or if data residency rules out SaaS.
Common mistakes
- Putting business logic in the gateway — it is policy, not implementation.
- Forgetting the bridge — hosts speak stdio; without a translator, the gateway is unreachable.
- No bypass workflow — incidents require a one-button bypass with an audit trail. Hard-wired-only fails closed at the worst time.
- Single instance — the gateway is a SPOF on every agent in your org. Run two minimum.
Where this is heading
Expect MCP-native gateway features to land in the 2027 protocol spec: standardised policy attributes, gateway-aware servers, a bridge protocol. Build the abstraction now, swap implementations later.