MCP adoption has run ahead of MCP governance. Your developers are already spinning up servers from Cursor, Windsurf and Claude Desktop, and each connection is a new credential scattered across config files. Underneath, the STDIO transport treats every configured server as a trusted local process, turning each into an executable supply-chain link. The useful question is where the boundary that contains the risk sits.
This article resolves whether an MCP gateway or a direct connection actually contains the risk, judged on blast radius rather than vendor framing. It fits inside the broader MCP security picture and builds on why MCP-specific attack classes differ from what conventional scanners catch.
Why was Anthropic’s STDIO transport design flaw called “the mother of all AI supply chains”?
The label comes from OX Security’s April 2026 disclosure, and it names a design choice. The STDIO transport accepts a command string and hands it to the operating system without checking the target is actually an MCP server, so every configured server becomes a supply-chain link.
The local-process trust assumption is the root: STDIO spawns each server as a child process with no validation of what it launches. Anthropic’s response was that the behaviour is by design and sanitisation is the developer’s responsibility. OX Security measured the consequence at 200,000 vulnerable instances and 7,000 publicly exposed servers.
CVE-2025-6514 made the pattern concrete. The mcp-remote OAuth proxy passed a crafted authorisation endpoint straight to the system shell, achieving remote code execution on the client machine. It carried a CVSS score of 9.6 across environments totalling 437,000 downloads, turning any unpatched install into a supply-chain backdoor able to steal API keys, cloud credentials and local files.
Be honest about the framing. Config-to-exec predates MCP: several mature toolchains already turn config fields into commands, and MCP’s trust gate sits mid-pack. The new element is the agent writing or auto-executing that surface under prompt injection. Track the follow-on CVEs, such as CVE-2026-30615, alongside the vendor advisories, because the pattern is what conventional scanners miss.
Before you can act on any of that, you need to see what is already running.
How do I inventory the MCP servers already running across Cursor, Windsurf and Claude Desktop?
You cannot contain what you cannot see. Start with the per-tool config files, because they both launch servers and hoard the credentials those servers use. Enumerate every developer endpoint, extract server definitions and secrets, then reconcile each against registry provenance.
The config file is the concentration point. Claude Desktop keeps its servers in a JSON config as command strings the host executes, and the same pattern recurs across Cursor, Windsurf and VS Code, so discovery has to sweep each editor, not one canonical file. One scan found 24,008 secrets in MCP config files on public GitHub, 2,117 of them still valid.
The registry made sprawl inevitable: published servers grew from around 1,200 to over 9,400, a surface that outpaced any governance tracking it.
The deliverable is a mapping: which agents connect to which servers, with what permissions and whose ownership, treating MCP credentials as non-human identities. That register is the precondition for everything else — the foundation for the full MCP security lifecycle — and it leads straight into the next question, whether a gateway or a direct connection actually contains the risk. The confused-deputy and token-passthrough failures those credentials enable are what is at stake.
MCP gateway or direct MCP server connection: which actually contains the risk?
A gateway contains risk where a direct connection concentrates it, but only for traffic that routes through it. Direct connections scatter long-lived credentials across editor configs with no control plane; a gateway centralises authentication, tool curation, token binding and audit, and brokers credentials so the agent never sees the upstream secret.
Direct connection is the default and the problem. Every agent owns its credential storage, so API keys and connection strings scatter across codebases, environment variables and config files. A compromised agent inherits every credential its config holds.
A gateway reverses that. One OAuth-protected URL handles authentication, publishes read-only tool subsets, and uses RFC 8707 resource indicators so a token issued for one server is rejected at another, closing the confused-deputy attack the spec calls out. Credential brokering keeps the upstream secret out of the agent’s context, and per-call audit gives the visibility a direct connection never will.
A gateway is a single point of failure, and it only blocks direct egress if you force traffic through it. Both of Anthropic’s worst incidents were egress failures: a red team phished an employee into having Claude exfiltrate AWS credentials, and a second incident let hidden instructions reach an allowed domain. In both cases the sandbox held while the data still left, which is why egress control belongs to the gateway. The division of labour is clean: the gateway owns the network and credential plane, the sandbox owns the host plane. An allowlist grants capability, so scope by capability and identity rather than hostname, and note how a gateway changes the assumption that MCP authorisation relies on human consent. It is one control within the broader work of securing the Model Context Protocol from adoption to containment, not a substitute for the programme around it.
Build versus buy for MCP security controls: what should you own internally?
Own your policy and your registry; buy the isolation primitives and gateway plumbing, and treat the custom auth glue around them as the part most likely to fail.
The agent-to-MCP mapping, approval and scope policy, credential-brokering policy, and audit and ownership are risk decisions, and no vendor feature substitutes for them. Buy scanner coverage across repos, CI/CD and collaboration tools, and gateway infrastructure that stacks OAuth 2.1, PKCE and RFC 8707 resource indicators correctly, because getting MCP authorisation right means implementing it once, not once per server. The mature primitives have survived more adversarial attention than anything you will build.
Sandbox any integration with write or execute tools, servers that touch production or regulated data, integrations that ingest untrusted content, and anything requiring outbound egress, then apply the lethal-trifecta test: private data plus untrusted content plus external communication. A small to mid-sized engineering organisation rarely has the staffing to own a bespoke OAuth server or container runtime, so spend scarce engineering effort on the policy and host-plane problems that are yours. The governance programme you own, and the evidence you demand before adopting a server, sit in the governance framework and the server-evaluation guide.
Wrapping it all up
Containment is an enforcement property assembled from inventory you own, policy you author, a boundary you force, and isolation primitives you rent. Judge any MCP security claim by whether it makes the gateway the only path and whether it supervises capability rather than hostname.
The sequence from one CVE, to invisible sprawl, to the egress boundary, to the ownership split leaves you a decision rule: force traffic through a gateway, scope by capability and identity, and sandbox the lethal trifecta. Draw the build-versus-buy line at the trust boundary: own the mapping and policy, buy the mature scanner and gateway primitives, and never hand-roll the authorisation glue.
Your next action is the agent-to-MCP inventory, because it is the first control that is yours and the place where containing MCP risk end to end begins.
Frequently Asked Questions
What is an MCP gateway, in plain terms?
An MCP gateway is a single control plane that sits between your AI agents and the MCP servers they call. Instead of each editor config talking straight to a server, every request passes through one OAuth-protected endpoint that handles authentication, tool curation, token binding, credential brokering and per-call audit. Think of it as the front door for agent-to-tool traffic: one place to see, scope and log what agents can actually reach.
Is MCP genuinely unsafe, or is this just vendor hype?
Partly both, and the honest answer is that the protocol is fine while the deployment surface is not. The STDIO transport flaw is a real design choice, proven by CVE-2025-6514, but config-to-exec is older than MCP and its trust gate sits mid-pack. What is genuinely new is an agent writing or auto-executing that surface under prompt injection. Judge the exposure, not the marketing.
Do I need a gateway if every MCP server I use is internal and pre-approved?
Yes, because “internal” and “pre-approved” cap who published a server, not what a compromised agent can do with it. An approved server still holds credentials, still executes locally, and still inherits everything the calling agent can reach. A gateway lets you scope each connection by capability and identity and keeps credentials out of config files, which internal status alone does nothing to fix.
What actually happens if a developer approves a malicious MCP server?
The blast radius is whatever that server’s credentials and process context allow. Once approved, it can execute commands, read files the agent can read, and use any token sitting in the config, which is why one poisoned server can reach far beyond its own function. That is precisely why containment focuses on capping capability and brokering credentials rather than trusting approval alone.
Does connecting to a remote hosted MCP server remove the supply-chain risk?
No, it relocates it. A remote server still has provenance you must verify, a maintainer and publish history you do not control, and a token that grants access to your upstream systems. It removes local process execution but adds an egress path you have to supervise. Supply-chain risk follows the trust relationship, not the deployment location.
Is a gateway a replacement for sandboxing, or do they solve different problems?
They solve different halves of the same problem. The gateway owns the network, tool, MCP and API plane: authentication, credential brokering and egress. The sandbox owns the host plane: process and filesystem isolation. Anthropic’s two worst incidents were egress failures, so a correctly built gateway closes one layer and a sandbox closes the other. You generally want both.
How do I tell whether my existing MCP connections are overprivileged?
Ask what each server can reach if its token is stolen, then compare that to what the agent actually needs. Overprivilege usually shows up as broad scopes, long-lived credentials with no expiry, tokens shared across servers, and write or execute access granted for read-only tasks. Map each agent-to-server link by capability and identity; anything broader than the task demands is overprivileged.
Where are the authoritative CVE records and advisories for MCP SDKs and servers?
Start with the CVE and NVD entries themselves, for example CVE-2025-6514 for the mcp-remote command injection, then read the vendor advisories around them. Anthropic’s response, the CSA research note and OX Security’s disclosure all matter, and follow-on CVEs such as CVE-2026-30615 show the pattern. Track the registry’s publish history alongside the CVE feed rather than relying on any single source.
What signals tell me an MCP integration belongs in a sandboxed or isolated process context?
Four signals point to isolation: tools that write or execute, servers touching production or regulated data, integrations that ingest untrusted content, and anything requiring outbound egress. Apply the lethal-trifecta test: private data plus untrusted content plus external communication. If an integration hits all three, or any of the four signals, run it in an isolated process context rather than trusting the agent’s own judgement.
Can a gateway introduce new risk of its own?
Yes, and pretending otherwise is vendor framing. A gateway concentrates traffic, so it becomes a single point of failure and, in the aggregator pattern, a high-value target holding brokered credentials for many servers. That risk is acceptable only when the gateway is hardened, the tokens it brokers are audience-bound and short-lived, and you accept the concentration as the price of seeing and scoping every call.
How often should I re-inventory my MCP servers, and what triggers a re-check?
Treat inventory as continuous, not annual. Re-run discovery whenever a new editor or agent is onboarded, a server version changes, a new CVE lands against a server in your register, or a developer adds a config file. The registry’s growth from about 1,200 servers to 9,400-plus means the surface moves faster than any yearly review, so trigger-based discovery is the realistic cadence.
What is the lethal trifecta, and how do I test an MCP integration against it?
The lethal trifecta is the combination of private data, untrusted content and external communication in one agent context. Test any integration by asking three questions: can it read data you would not publish, can it ingest content an attacker controls, and can it send data outward? If all three are true, the integration can exfiltrate, and it needs containment rather than trust.
