The MCP Gateway:
Why AI Needs a Front Door to Your Tools
What MCP is, and why it spread
Introduced by Anthropic in November 2024, the Model Context Protocol (MCP) is an open standard for connecting AI assistants to the systems where work actually happens — repositories, databases, business tools, internal services [1]. It caught on quickly because it replaced a mess of bespoke integrations with one protocol. An agent that speaks MCP can, in principle, use any tool that speaks MCP.
That is also the problem. "Any tool" includes tools authored by third parties, installed with a copy-paste, and granted access to a running agent — and the protocol's trust model turned out to have sharp edges that only became visible under security scrutiny.
The attacks are architectural, not incidental
The most important MCP vulnerabilities are not bugs in one server that a patch can fix. They are properties of how the protocol composes trust:
- Tool poisoning. Invariant Labs demonstrated that a malicious server can hide instructions inside a tool's description — invisible to the user, fully visible to the model — causing an agent to leak SSH keys or silently redirect actions [2].
- Line jumping. Trail of Bits showed that because tool descriptions enter the model's context the moment a server connects, a hostile server can influence behaviour before any tool is ever invoked, sidestepping the protocol's consent step entirely [3].
- Rug pulls. A server approved as benign can later mutate its own tool definitions, because trust is bound to the tool's name, not its content — catalogued as CVE-2025-54136 ("MCPoison") in one popular client [4].
- Toxic agent flows. Invariant Labs also showed a malicious GitHub issue in a public repo hijacking an agent into reading a user's private repositories and leaking them into a public pull request — no bug in GitHub's code, purely an agent-level flaw [5].
In an academic study of 1,899 open-source MCP servers, 7.2% carried general security vulnerabilities and 5.5% contained MCP-specific tool-poisoning flaws; credential exposure was the single most common issue [6].
Real, catalogued CVEs already exist: CVE-2025-49596 (MCP Inspector RCE, CVSS 9.8) [7] and CVE-2025-6514 (mcp-remote RCE, CVSS 9.6) [8].
This is not theoretical debt
The vulnerabilities have already crossed from research into the CVE database. CVE-2025-49596, a critical remote-code-execution flaw in Anthropic's own MCP Inspector tool, scored 9.8 and was exploitable straight from a browser [7]. CVE-2025-6514, in the widely used mcp-remote proxy, let a malicious server run arbitrary commands on the client during connection, scoring 9.6 [8]. A study of nearly 1,900 public MCP servers found that 7.2% carried conventional vulnerabilities and 5.5% had tool-poisoning-specific flaws, with leaked credentials the most common problem of all [6].
When trust is decided per-tool, at the edge, by whoever installed the server, you do not have a security model. You have a collection of independent decisions no one is reviewing.
The case for a gateway
Because these weaknesses are architectural, the fix is architectural too. An MCP gateway is a single, governed entry point that sits between your agents and the MCP servers they use — the equivalent of an API gateway for the agent era. Instead of every client trusting every server directly, all traffic flows through one controlled layer where policy can actually be enforced:
- Allow-listing with default-deny. Agents reach only the servers and tools an administrator has explicitly approved — not whatever a developer pasted in.
- Tool-definition pinning. Descriptions are captured and version-locked, so a server that mutates its tools after approval — the rug-pull — is caught rather than silently trusted.
- Egress control. Centralised outbound policy breaks the lethal trifecta by denying the exfiltration path even if an injection succeeds.
- Centralised authentication and audit. One place to enforce identity, and one immutable log of which agent invoked which tool, with what arguments — the record every incident response and every auditor will ask for.
MCP is genuinely useful, and it is not going away; the productivity case for giving agents real tools is too strong. But connecting an autonomous system to your internal tooling through an unvetted, edge-trusted protocol is not a decision to make one server at a time. It is a decision to make once, at the front door — which is exactly what a gateway is for.