MCP Gateway vs Direct MCP Connections: Decision Guide

Every organisation running AI agents eventually has to decide whether MCP clients should talk to MCP servers directly or go through a gateway, and getting it wrong either leaves credentials and audit scattered across hundreds of endpoints or creates one box that holds the keys to everything. This guide is a decision guide, not an architecture tutorial: it sets out when brokering is worth the cost, what each model protects against and what it introduces, and how to stop direct connections quietly bypassing a gateway once you have one. It is for security architects, platform and identity teams. Gateway functions, approval workflows and client allowlist settings are covered in the MCP Gateway and MCP Server Governance Guide, and protocol threats in the MCP Security Guide; this page links to them rather than repeating them. Protocol details reflect MCP specification revision 2026-07-28, checked on 13 November 2026.

Key takeaways

Short answer: direct connections suit a small number of vendor-hosted or local servers with per-user OAuth; a gateway pays off once you have shared downstream credentials to broker, internal servers, several agent platforms, or an audit requirement the clients cannot meet.
The gateway moves risk, it does not remove it. It concentrates tokens, routing and policy in one place, so its compromise is worse than the compromise of any single server. Treat it as a tier 0 identity system.
A gateway only governs traffic that goes through it. Without client policy and egress control, a developer can add a direct connection in one line of configuration and the gateway never sees it.
Brokering must never mean passthrough. The MCP specification says servers must not accept or transit tokens not issued for them, so a gateway authenticates the caller and obtains its own audience-bound credential for each downstream server.
stdio servers sit outside any network gateway. Local servers are governed on the endpoint by managed client policy and sandboxing, whichever model you choose.

The two models in plain terms

Direct connection: each MCP client (an IDE assistant, a desktop chat app, an agent framework running in a pipeline) holds its own list of servers and connects to each one itself. For a remote server over Streamable HTTP, the client runs the OAuth flow, receives an access token bound to that server's canonical URI through the RFC 8707 resource parameter, and sends it in the Authorization: Bearer header on every request. For a local server over stdio, the client launches the process and the server takes credentials from its environment, which the authorisation specification says stdio implementations should do instead of following the OAuth flow. Policy, logging and credentials live in every client.

Brokered through a gateway: clients connect to one MCP endpoint that the gateway exposes. The gateway authenticates the user and agent, decides which servers and tools that caller may see, obtains a separate credential for each downstream server, forwards the call, and records it. The gateway is an MCP server towards the client and an MCP client towards each downstream server, so it takes on obligations from both sides of the specification. In zero trust terms (NIST SP 800-207) it moves enforcement close to the resource instead of trusting network location.

Most estates end up hybrid: remote and internal servers through the gateway, stdio servers governed on the endpoint, and a short exception list for direct remote connections.

Side-by-side comparison

Dimension	Direct MCP connections	MCP gateway (broker)
Where policy is enforced	In each client, through managed allowlists and consent prompts	Centrally, per caller, server and tool, plus client policy to force routing
Where downstream credentials live	On every endpoint or pipeline that runs the client	In the gateway or its vault; clients hold only a gateway token
Blast radius of one compromise	One client compromise exposes that user's tokens; one server compromise exposes callers of that server	Gateway compromise exposes every brokered credential and every routed session
Audit evidence	Fragmented across client telemetry and each server's logs, in different formats	One record per call with user, agent, server, tool, arguments and result size
Tool filtering	Limited to what each client supports	Per tool, per group, and by argument pattern where the product supports it
Latency and availability	One hop; each server is an independent dependency	Extra hop and a shared dependency; gateway outage stops every brokered agent
Change management	Each server's tool list reaches clients as published	Gateway can pin, diff and hold tool list changes before clients see them
stdio servers	Launched and governed by the client	Not visible unless the gateway hosts them, for example in containers
Operating cost	Low platform cost, high per-endpoint effort	A platform to run, patch and staff

Threat model: direct connections

With direct connections the main assets are the tokens and secrets held by each client, and the main trust decision is made separately on every endpoint.

Credential sprawl: every user who connects to a SaaS MCP server holds a refresh token for it on their laptop, and every pipeline that runs an agent holds API keys in its environment. See the MCP Static Token Audit.
Tool poisoning reaches the model unfiltered: tool names, descriptions and schemas come straight from the server into the model's context. The tools specification says clients must treat tool annotations as untrusted unless they come from trusted servers, and a description can carry hidden instructions (ATLAS AML.T0110 AI Agent Tool Poisoning). Nothing central diffs or holds a changed tool list. See MCP Tool Poisoning Detection.
Malicious or compromised server packages: a local server is code with the user's privileges. The postmark-mcp Malicious MCP Server 2025 worked normally for fifteen versions before one added line blind-copied every email the agent sent; it ran with users' own email service tokens, so no gateway would have seen it, but version pinning on the endpoint would have stopped the silent upgrade.
Client-side discovery attacks: during OAuth discovery a client fetches URLs supplied by the server. The security best practices describe a malicious server pointing resource_metadata or authorisation server URLs at internal addresses such as 169.254.169.254, and say clients should require HTTPS, block private and link-local ranges and, for server-side deployments, use an egress proxy. Every direct client has to get this right on its own.

Threat model: the gateway

A gateway removes most of the sprawl, but its risks are concentrated.

Single point of compromise: the gateway holds, or can mint, credentials for every downstream server. In the LiteLLM MCP Auth Bypass 2026, key validation fell back to an empty authentication object instead of rejecting the request, so any bearer token opened a full MCP session; attackers chained it with a command injection to read the master key, provider keys and credentials for connected MCP servers.
Token passthrough and confused deputy: a gateway that forwards the caller's token downstream breaks audience binding, and one compromised server can replay it elsewhere. A gateway that acts as a single OAuth client to third-party APIs while letting MCP clients register dynamically is exactly the "MCP proxy server" in the specification's confused deputy section, and must implement per-client consent, exact redirect URI matching and single-use state values. See the Confused Deputy in AI Agents Guide.
Cross-user cache leakage: revision 2026-07-28 lets list and read results carry cacheScope. A "public" response may be cached by a shared gateway and served across authorisation contexts; a "private" one must not be shared across authorisation contexts. Lists may vary by the caller's scopes, so caching a private list as public can show one user's tools or data to another.
Header and body disagreement: Streamable HTTP mirrors Mcp-Method, Mcp-Name and x-mcp-header parameters into HTTP headers for intermediaries, but the server executes on the body; the specification says intermediaries enforcing policy on headers should reject protocol versions that do not require header and body validation. A gateway that allows Mcp-Name: read_ticket while the body calls delete_ticket has no policy at all.
Over-privileged gateway identity: a gateway running in the cloud with a broad role, or with access to the instance metadata service, turns a gateway bug into cloud compromise (ATT&CK T1552.005 Cloud Instance Metadata API).

Decision criteria: when brokering is worth it

No standard sets a numeric threshold. The triggers below are practitioner judgement; one strong trigger usually justifies a gateway, two weak ones together often do.

Factor	Direct is usually enough	Gateway is usually justified
Downstream credentials	Every remote server supports per-user OAuth with audience-bound tokens	Any server needs a shared service credential or static key that you do not want on endpoints
Server count and ownership	A handful of vendor-hosted servers, no internal servers	Internal servers built by several teams, or more servers than you can review client by client
Client diversity	One managed client with enforceable allowlists	Several IDEs, chat apps and agent frameworks with different policy support
Autonomous agents	Interactive use with a human approving tools	Pipelines, scheduled agents or multi-agent systems with nobody to approve calls
Audit and regulation	Per-server vendor logs satisfy your obligations	You must show who called which tool with which arguments, across all servers, in one place
Data classification	Public or low-sensitivity data only	Tools that reach customer data, source code, production systems or payments
Latency tolerance	Interactive coding or chat where tens of milliseconds matter and calls are chatty	Agent tasks measured in seconds where an extra hop is immaterial
Platform capacity	No team to run a highly available, patched tier 0 service	A platform team that already runs identity-aware proxies or API gateways

Small organisations: managed client allowlists, vendor-hosted servers with per-user OAuth, and egress logging are a defensible starting point. A self-run gateway you cannot patch quickly can leave you worse off. Large organisations: a gateway is close to unavoidable once internal servers and autonomous agents appear, but plan for two or more instances separated by trust zone so one compromise does not reach everything. For how the MCP gateway relates to model-traffic brokers, see the AI Gateway and LLM Gateway Guide; combining both in one product concentrates provider keys and tool credentials together.

Failure mode: shadow direct connections bypassing the gateway

The most common gateway failure is not a gateway bug; it is traffic that never reaches it. Adding a remote server to a client is one configuration entry, and a repository can ship its own server definitions. Typical bypass routes:

User-scope configuration: a user adds a vendor's MCP URL to their personal settings because the gateway does not yet offer it.
Project-scope configuration: a cloned repository defines servers that start when the project opens. In the Amazon Q MCP Config Vulnerability 2026, servers defined in a repository's configuration started, according to the researchers, without an approval dialog and inherited the developer's AWS session.
Pipelines and SDK use: agent code in CI builds its own MCP client outside managed client policy.
Vendor-side connectors: a model provider's platform connects to remote MCP servers on your behalf, from the provider's network, so neither your gateway nor your egress proxy sees it.

Controls that make the gateway the only path:

Deliver managed client policy that allows only the gateway URL for remote servers and locks the allowlist to managed scope, so user-level entries cannot widen it. The governance guide lists the client settings.
Deny or require approval for project-defined servers on managed devices; treat repository configuration as untrusted input.
Have downstream systems accept only tokens whose audience and client identity are the gateway's. Where a SaaS vendor supports conditional access or IP restrictions for its MCP endpoint, restrict it to gateway egress addresses.
At the egress proxy, alert on HTTPS sessions to known MCP endpoints from anything other than the gateway, and on POST requests carrying MCP-Protocol-Version or Mcp-Method headers where TLS inspection is in place.
On endpoints, inventory MCP configuration files and running server processes. See How to audit MCP servers on developer laptops and the Unsanctioned AI Agents and MCP Servers Guide.
Remove the reason to bypass: publish a fast request path so a new server is available through the gateway in days, not weeks.

Controls compared by model

Control	With direct connections	With a gateway
Server allowlist	Managed client policy matching exact URL and exact command with pinned versions	Gateway registry decides reachable servers; client policy allows only the gateway
Tool allowlist	Client tool filtering where supported; otherwise rely on OAuth scopes	Per-group tool filtering; hide destructive tools; hold changed tool lists for review
Token handling	Per-user OAuth, RFC 8707 audience binding, tokens in OS credential stores; no static keys in config	Inbound token issued for the gateway; separate audience-bound downstream credential per server; no passthrough
Brokered secrets	Avoid; if unavoidable, inject from a vault at launch	Vault-held, scoped to the server's approved tools, end user recorded on every call
Human approval	Client confirmation prompts, which the tools specification says should exist	Approval workflows bound to the exact call and arguments, usable for unattended agents
Logging	Client telemetry plus each vendor's logs, correlated in the SIEM	Gateway call log as the primary record; client and egress logs to detect bypass

Hardening the gateway as a crown jewel

Fail closed, no default keys: any authentication or policy error rejects the request; an empty or one-character bearer token must return HTTP 401. Administrative access goes through the IdP with phishing-resistant MFA.
Segment by trust zone: separate gateway instances, or at least separate signing keys and credential stores, for developer tools and production automation.
Disambiguate aggregated tools: tool name uniqueness is scoped to one server, and the specification says aggregating proxies should prefix names with a server identifier rather than relying on the server name, which is not guaranteed unique. Collisions let a low-trust server shadow a high-trust tool.

Worked scenario

A software company of about 2,000 staff has 600 developers using two IDE assistants, a support team using a chat client, and a platform team building autonomous agents that run in CI. Connected servers include a vendor-hosted ticketing server (per-user OAuth), a code hosting server (per-user OAuth), an internal deployment server built in-house, a database query server that only supports a service account, and around 40 local stdio servers developers have installed themselves.

Decision: the database server's shared credential, the internal deployment server and the CI agents with nobody to approve calls are each strong triggers. The company adopts a gateway for all remote and internal servers, in two instances: one for interactive developer and support use, one for CI automation with no route to the deployment server's production tools.
OAuth servers: ticketing and code hosting stay per-user OAuth, brokered by the gateway with its own audience-bound tokens; the applications accept only the gateway's client identity.
Local servers: the 40 stdio servers are reduced to 12 approved ones, pinned by exact command and version through managed client policy, with project-defined servers denied on managed devices.
Bypass detection: the egress proxy alerts on MCP traffic to SaaS endpoints from anything other than gateway addresses. Early hits are personal entries for a vendor server, which is added to the gateway catalogue.
Gateway hardening: both instances sit on private networks behind the IdP with no metadata access; a quarterly test confirms malformed tokens are rejected and an outage stops agents rather than rerouting them.

Implementation path

Inventory: list every client, server, transport and credential type, including pipelines. Use the MCP Server Inventory Template.
Classify and decide: classify each server by transport, credential type and data sensitivity, then decide gateway or direct per server, and record the reason for every direct exception with an owner and review date.
Pilot: route one team and two or three servers through the gateway in monitor mode, logging calls without blocking, and measure added latency per call against your tolerance.
Enforce: switch client policy to gateway-only for remote servers for the pilot group, then widen by ring. Keep the previous policy package ready for rollback.
Close the bypass: restrict downstream applications to the gateway's identity and turn egress alerts into blocks once false positives are understood.
Operate: include the gateway in tier 0 patching, access reviews and incident playbooks. See the MCP Incident Response Playbook.

Detection and measurement

Signals to log: gateway authentication failures and policy denials, tool list changes, downstream token issuance per caller, routing and filter changes, and egress sessions to MCP endpoints from non-gateway sources.
Abuse indicators: gateway-issued tokens presented from addresses other than the gateway (T1550.001 Application Access Token), gateway processes calling the metadata service (T1552.005), and bulk results through a single tool (T1567 Exfiltration Over Web Service). For log design, see Agent Observability vs Audit Logging.

Metric	What it shows	Direction
Share of remote MCP calls routed through the gateway	Enforcement coverage	Close to 100% on managed devices and pipelines
Direct-connection exceptions with a current owner and review date	Whether exceptions are deliberate	100%
Bypass sessions detected per month at the egress proxy	Shadow connection pressure	Falling after enforcement
Downstream credentials held by the gateway that are long-lived	Concentrated credential exposure	Falling towards zero
Median added latency per brokered call	Whether users have a reason to bypass	Stable and inside the agreed budget
Days from gateway security advisory to patch	Crown jewel hygiene	Within the critical patch window

Common failure patterns

Passthrough by convenience: forwarding the user's token to every server because downstream OAuth is hard, which breaks audience binding and audit on both sides.
Gateway-only policy with no client enforcement: dashboards show full coverage while project files and personal settings carry direct connections.
Fallback to direct on outage: clients configured with the gateway and the original server URLs, so an outage silently removes every control. Agents should stop instead.
Public caching of private lists: one shared cache for tool and resource lists that vary by caller scope.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	AC-3 Access Enforcement; AC-4 Information Flow Enforcement; AC-6 Least Privilege	Gateway as enforcement point; tool and server filtering; scoped downstream credentials
NIST SP 800-53 Rev 5	SC-7 Boundary Protection; AU-12 Audit Record Generation; CM-7 Least Functionality	Egress control and bypass blocking; per-call records; hiding unneeded tools
NIST CSF 2.0	PR.AA-05; PR.IR-01; DE.CM-09; ID.AM-02	Access policy; protecting environments from unauthorised access; monitoring runtime; server inventory
MITRE ATLAS	AML.T0110 AI Agent Tool Poisoning; AML.M0029 Human In-the-Loop for AI Agent Actions	Tool metadata threat; approval control a gateway can centralise
MITRE ATT&CK v20	T1550.001; T1552.005; T1567	Token reuse, metadata credential theft and exfiltration through tools
OWASP Top 10 for LLM Applications 2025	LLM06:2025 Excessive Agency	Minimising extensions, functionality and permissions exposed to agents

Practitioner checklist

Inventory every MCP client, server, transport and credential, including pipelines and provider-side connectors.
Decide gateway or direct per server using credential type, ownership, autonomy, audit need and latency, and record each direct exception.
Configure the gateway to authenticate callers and obtain its own audience-bound downstream credentials; never forward caller tokens.
Run the gateway as tier 0: private network, fail-closed authentication, no default keys, least-privilege role, no metadata access, fast patching.
Enforce gateway-only routing in managed client policy and deny project-defined servers on managed devices.
Restrict downstream applications to the gateway's identity or addresses so bypass fails visibly, and alert on MCP traffic from non-gateway sources.
Govern stdio servers on the endpoint with pinned commands, versions and sandboxing regardless of the gateway decision.

MCP Gateway vs Direct MCP Connections: When Brokering Agent Tool Access Pays Off