Home/Guides/MCP Direct vs Gateway

Guide · Updated October 2026 for MCP 2026-07-28

MCP Server Access: Direct vs Gateway-Brokered

Your agents need GitHub, Jira and Salesforce. You can let each one connect directly, run an open-source gateway yourself or broker every call through a managed trust layer. The 2026-07-28 specification made direct connections better at connecting. Nothing in it governs what happens after. This guide covers the real risks of going direct, what a self-hosted gateway costs once you count the CVEs and a decision framework for regulated environments.

Three MCP architectures compared. Direct: every agent holds a grant for every server, and local stdio servers run unseen. Self-hosted gateway: an OSS proxy that holds every credential and ships its own CVEs. Trust layer: the IdP approves connections and a service edge governs every call, with local servers covered by the endpoint agent. Below, the three kill points: identity, operations and coverage.

What changed

MCP 2026-07-28 moved the goalposts

The July revision is the largest since launch and the first with breaking changes. Two consequences matter for this decision. Direct connections are no longer the bearer-token free-for-all they were in 2025. And feature checklists between gateways have converged, so the real differences now sit in operations, content and coverage.

Stateless core

The initialize handshake and Mcp-Session-Id are gone. Every request carries its own version and capabilities, and Streamable HTTP mirrors the method and tool name into Mcp-Method and Mcp-Name headers so gateways can route and authorize without parsing the body.

Enterprise-Managed Authorization is stable

The IdP can now approve an agent's connection to an MCP server with an ID-JAG, replacing the per-agent, per-server consent screen. It decides who may connect. It does not see the calls that follow.

CIMD replaces DCR

Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. Clients must also validate the issuer on authorization responses (RFC 9207), and client credentials are bound to the issuer that minted them.

Servers no longer send requests

Multi Round-Trip Requests replace server-initiated sampling, roots and elicitation. A server that needs input returns input_required and the client retries. Secrets still have to be collected out of band: the spec forbids collecting them in-band.

Extensions are official

MCP Apps and Enterprise-Managed Authorization are stable extensions. Tasks is in beta. Roots, Sampling and Logging are deprecated with a twelve-month window.

Three architectures

Same problem, three different owners for the risk.

Direct

The risks of going direct

Direct got better in 2026. Remote servers speak OAuth, clients identify themselves with metadata documents and EMA lets the IdP approve connections. What direct still lacks is anything between the agent and the server that the enterprise controls. Seven risks follow from that.

Token sprawl

Every agent holds its own grant for every server. Four agents and five servers make twenty refresh tokens, stored in four places, invisible to the IdP and revoked one at a time. Background agents like a Slackbot or a CI job keep long-lived tokens because there is no browser to consent again.

EMA removes the consent screen only where both the agent and the server support it.

Scopes granted up front

When a server's challenge names no scope, the spec tells clients to request every scope the server lists in scopes_supported. That broad token then lives on a laptop or in a config file. The spec's own security guidance lists omnibus scopes as a common mistake.

MCP Security Best Practices, Scope Minimization.

The IdP stops at the door

EMA settles whether a connection may be made. After that the agent calls tools at machine speed and none of those calls go back through the IdP. Nothing can tell a routine query from a bulk export, require approval for a payment or stop a prompt-injected agent halfway through a task.

Per-call policy is left to each SaaS vendor, in each vendor's terms.

Poisoned and changed tools

Tool descriptions are instructions to the model. In June 2026 Microsoft described a chain where a silently edited description makes an agent send invoices to an attacker through tools the user already approved. postmark-mcp did it for real in September 2025, blind-copying every outgoing email to an outside address.

Whether a changed description gets re-approved depends on the client.

Injected results, leaked arguments

Tool results are untrusted content. A GitHub issue, a support ticket or an email body can carry instructions, and in May 2025 a poisoned public issue led an agent to leak private repositories through the GitHub MCP server. Going the other way, nothing stops a customer record or an API key pasted into a tool argument.

Direct means nothing reads tool inputs or results except the model.

Local servers run as you

A local stdio server is a process with the user's privileges, environment variables and keys. OX Security showed in April 2026 that the SDKs run the configured command as given. Adversa's TrustFall showed a cloned repository can start its own servers after one folder-trust prompt. Safari and Xcode now ship local MCP servers, with Pages, Keynote and Numbers to follow.

No network control sees a process talking to another process on the same laptop.

No common record

Each vendor logs MCP calls in its own format, if it logs them at all. When an agent misbehaves across GitHub, Jira and Salesforce, there is no single record of who asked, which agent acted, which tool ran and what allowed it.

An auditor asks for one timeline. Direct gives you five partial ones.

If you stay direct

✓Prefer remote servers with per-user OAuth over personal access tokens and API keys.
✓Turn on EMA wherever both the agent and the server support it.
✓Disable auto-start of project-scoped MCP servers and review MCP config files in pull requests.
✓Allowlist servers by publisher and pin versions of local servers.
✓Require human approval for tools that move money, send external messages or change permissions.
✓Rotate every token an MCP server or agent has held since your last review.

At a glance

Where each architecture lands across the dimensions that matter for enterprise MCP access.

Dimension	Direct	Self-Hosted Gateway	Trust Layer
Who approves the connection	The user, on a consent screen per agent per server. The IdP only where both sides support EMA.	Your gateway config. Per-user OAuth and ID-JAG are available in some projects; many deployments still use shared service credentials.	Your IdP. Agents sign in through SSO, and upstream tokens come from outbound EMA or per-user OAuth.
Identity the MCP server sees	The user, for servers that support OAuth. A shared PAT or API key for the many that still do not.	The user if per-user OAuth is set up. Otherwise the gateway's service identity. Passthrough modes forward the client's token unchanged, which the spec calls an anti-pattern.	The verified user, with the agent recorded alongside them on every call.
Where credentials live	In every agent: refresh tokens, PATs and API keys on laptops, in CI and in config files.	In the gateway's database and environment, which makes the gateway the most valuable target in the stack.	Vaulted per tenant under envelope encryption. Agents hold one Ferentin token and never the upstream credential.
Per-call authorization	Whatever each server enforces through OAuth scopes, which are often broad.	Tool allow and deny lists per key or team. Argument-level policy and approvals are yours to build.	Per-tool and per-argument policy, step-up and human approval on every call, before it reaches the upstream.
Content inspection	None. Results go straight into model context and arguments go straight to the server.	Guardrail plugins in some projects. You choose, tune and maintain them.	DLP and prompt-injection sanitization on tool inputs and results, in both directions.
Tool supply chain	Descriptions arrive from the server and are trusted. Re-approval on change depends on the client.	Registries and allowlists. Scanning descriptions and gating changes is yours to add.	Catalogs scanned on import. Tools are re-gated when an upstream server changes its surface.
Local and shadow servers	Invisible. Local stdio servers never touch the network.	Invisible. A network gateway only sees traffic routed to it.	The endpoint agent inventories MCP configs on managed devices and flags or quarantines servers that bypass the gateway.
Secrets and third-party consent	Up to each server and client to use URL mode correctly.	Whatever the upstream server does. The gateway passes it along.	Collected out of band on a hosted page. Never in the prompt, never in the agent.
Audit	Spread across each vendor's logs, in each vendor's format.	Request logs in your database, writable by whoever runs the gateway.	A signed receipt per call, verifiable offline with a standalone CLI.
Protocol currency	Each client and server upgrades on its own schedule.	You track the spec: header validation, CIMD, issuer checks and the stateless core, while still serving 2025-11-25 clients.	Both protocol versions served at the edge. Upgrades ship without your change window.
Patching and compliance	Each agent and server vendor's.	Yours. Gateway CVEs reached the CISA KEV catalog in 2026, and the gateway is in scope of your audit.	Ferentin's, under SOC 2 Type II.

Kill point 1

The IdP approves the connection. Someone has to govern the calls.

The best case for direct is a fleet of agents that all support Enterprise-Managed Authorization, talking to servers that all accept ID-JAGs. Your IdP approves each connection and the MCP server sees the real user. That is a genuine improvement, and it is still only the front door. After the token is issued, the agent calls tools many times a minute and none of those calls return to the IdP.

Most fleets are not the best case. Some agents have no EMA client, many servers still take a personal access token and background agents need offline access with no browser to consent in. Each of those is another long-lived grant on another device.

A trust layer collapses the grid. Every agent signs in to one endpoint through your IdP and holds one token. The edge uses outbound EMA to get each user's upstream token from your IdP, so even agents with no EMA support get IdP-approved access. Then every call passes through the same chain: identity, per-tool policy, DLP in both directions, the credential mint and a signed receipt. Disable the user at the IdP and every agent they own loses upstream access at the next refresh.

Kill point 2

A self-hosted gateway becomes your most valuable target

On features, open-source gateways have caught up. LiteLLM ships per-user OAuth and on-behalf-of token exchange. agentgateway and Kong support ID-JAG. A feature checklist will not separate them from a managed trust layer, so stop comparing checklists and ask who carries the operational risk.

A gateway that brokers MCP holds every upstream credential your agents use. That makes it the single most valuable system to compromise, and 2026 showed it. The LiteLLM supply chain attack in March exposed credentials stored in plaintext. Then the MCP-facing code itself started shipping CVEs:

CVE-2026-42271LiteLLMFixed May 2026. Added to CISA KEV June 8, 2026.

Command injection through the MCP test endpoints. Any holder of a proxy API key could run commands on the gateway host. Chained with a Starlette Host-header bypass, it became unauthenticated remote code execution. Observed follow-on activity included credential harvesting.

CVE-2026-55887Docker MCP GatewayFixed in 0.42.2.

Argument injection from a crafted OCI image label into the docker run command the gateway builds, exposing the host filesystem as root.

CVE-2026-8355IBM ContextForge MCP GatewayPublished October 2026.

Server-side request forgery through the OAuth token URL accepted during gateway registration, reaching internal and cloud metadata endpoints.

None of this means the projects are careless. It means running one puts you on the hook to patch on CISA's timeline, to keep its admin and test endpoints off the network and to treat its database as a credential store.

The specification is now a moving part too. Under 2026-07-28, a gateway that authorizes on the Mcp-Method and Mcp-Name headers has to make sure they match the body. The spec spells out the attack: a load balancer routing on the header while the server executes the body. It also says intermediaries enforcing header policy should reject older protocol versions, while most fleets still run 2025-11-25 clients. Add CIMD fetches (which the spec flags as a server-side request forgery surface), issuer validation and the DCR deprecation. Each is a backlog item for your platform team and another place to get it wrong.

Self-hosting is a legitimate choice for a team that wants to own all of that. A managed trust layer is the choice for a team that would rather own the policy than the plumbing. It replaces the gateway. You do not run both.

Kill point 3

A gateway only governs what goes through it

Direct and self-hosted share a blind spot: the laptop. A developer can paste a GitHub server with a personal token into ~/.cursor/mcp.json and skip any gateway. A cloned repository can carry a project config that starts its own servers. Apple is turning Mac apps into local MCP servers. Every one of these talks to the agent over stdio or localhost, and no network control ever sees it. As we argued when OX Security published its research, this is the same old local execution problem, not a protocol flaw. That makes it no less real.

A trust layer has to reach the device. Ferentin's endpoint agent watches the MCP configuration files of Claude Code, Codex, Cursor and other AI clients on managed devices. It inventories local servers, reports the ones that bypass the gateway and can quarantine them, so the governed path is the only path.

Decision framework

Which one should we run?

Two questions get most teams to the right answer. The first is scale: is this one developer on one laptop, or people and agents across the company reaching shared systems? The second is evidence: when something goes wrong, will someone need to prove who called what and why it was allowed?

Direct

One developer, their own accounts, low-stakes data. Prefer OAuth over tokens, use EMA where it exists and follow the stay-direct checklist. Revisit the moment a second agent or a shared service account appears.

Self-hosted gateway

Internal data and a platform team that wants to own the stack. Budget for KEV-speed patching, two protocol versions, content controls, evidence for your auditor and a separate answer for local servers. See the OSS gateways comparison for project-by-project detail.

Trust layer

Many agents, regulated data, an auditor in the room. Your IdP approves connections, every call is checked against policy and DLP, credentials never reach the agent, local servers are covered on the device and every call leaves a receipt you can verify offline. SOC 2 Type II covers the boundary.

FAQ

EMA and a gateway answer different questions. EMA lets your IdP decide whether an agent may connect to a server. Once connected, the agent calls tools directly and the IdP never sees those calls. A gateway decides what each call may do, inspects what goes in and comes out and records it. EMA is also only as broad as its adoption: it needs both the agent and the server to support it. A trust layer can use outbound EMA on the user's behalf, so even agents with no EMA client get IdP-approved upstream access.

Sources

Broker MCP through a trust layer

Your IdP approves every connection. Every call is checked, inspected and signed. Local servers are covered on the device. Nothing for you to patch.

Get Started Free Book a Demo