MCP Gateway Security: Enterprise MCP Gateway Governance for AI Agents
Connecting an agent to a third-party MCP server is a trust decision, and most teams make it once, in a config file, and never again. A gateway turns that into a policy you can change, inspect, and prove.
Direct answer
An MCP gateway is a proxy that sits between your AI agents and the Model Context Protocol servers they call, so that connection policy is enforced in one place instead of in every agent config. It does five things a direct agent-to-server connection cannot: it allowlists which MCP servers an agent may reach at all, it inspects each server tool manifest before the description enters the model context, it detects when a previously approved tool definition changes, it scopes which specific tools and arguments each agent may use, and it writes one audit record for every MCP call across every agent. The Cloud Security Alliance research note on MCP tool poisoning, published July 2, 2026, names gateway or proxy deployment for manifest inspection as a recommended control, alongside tool definition hash pinning and explicit server allowlisting. Agentshield is that enforcement point: MCP traffic is routed through it, every tool description and tool result is treated as untrusted input, and each call is checked against the scope granted to that agent.
Try it live
Watch Agentshield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
The MCP config is a JSON file in a repo. Someone added a server to it in March to unblock a demo, the review was a thumbs-up in a pull request, and the description that server publishes has been going straight into the model context on every session since. Nobody has read it since the day it was approved, nobody would notice if the server changed it tonight, and the same file has been copied into four other projects.
How Agentshield handles it
Agentshield terminates the MCP connection instead of letting each agent open its own. Servers are allowlisted centrally, so an agent cannot reach one that has not been approved. Tool manifests are fetched and inspected through the gateway, so a description carrying hidden instructions is caught before the model reads it, and a definition that changes after approval is flagged rather than silently trusted. Each agent gets a scope, so being connected to a server does not mean being allowed to call every tool on it. Tool results come back through the same path and are inspected as untrusted input. Every call, allow or deny, lands in one append-only trail.
The controls
The controls that secure every MCP server your agents connect to, from one policy point in front of them all.
What is an MCP gateway?
An MCP gateway is a single network and policy hop between your agents and the Model Context Protocol servers they use. Without one, each agent holds its own server list, its own credentials, and its own implicit trust in whatever those servers return. With one, that becomes centralized configuration: which servers exist, who may reach them, what each caller may do, and what happened.
The pattern is familiar because it is the same argument that produced the API gateway twenty years ago. What is different is the payload. An API gateway routes calls whose shape is fixed by code. An MCP gateway routes calls that a language model decides to make, partly on the basis of text the MCP server itself supplied. The server does not just receive requests, it also writes the tool descriptions that influence which requests get made. That feedback loop is the reason a proxy here is a security control and not only an operational convenience.
Three distinct jobs tend to get bundled under the phrase, and it is worth separating them when comparing products. Connection management handles transport, credentials, retries, and pooling many servers behind one endpoint. Discovery and cataloging maintain the list of servers and tools an organization has approved. Policy enforcement decides whether a given agent may call a given tool with given arguments right now, and inspects what comes back. Plenty of open-source projects do the first well. The third is where an agent actually gets stopped, and it is what we build.
MCP gateway vs MCP server vs API gateway vs LLM gateway
These four sit at different points in the same request and get confused constantly, usually in procurement, when a team discovers the thing they bought does not do the thing they assumed. This is the fastest way to keep them straight.
| Component | What it is | What it decides | Who runs it |
|---|---|---|---|
| MCP server | The thing that exposes tools and resources over the protocol, for example a GitHub, database, or filesystem server | What tools exist and what they return | You, a vendor, or an unknown third party |
| MCP gateway | A proxy in front of many MCP servers | Which servers an agent may reach, which tools it may call, and whether the manifest and the result are safe to read | You |
| MCP registry | A catalog of servers and their metadata | What is discoverable and approved. It lists, it does not enforce | You or a public index |
| LLM gateway or AI gateway | A proxy in front of model providers | Which model gets the prompt, plus cost, routing, caching, and rate limits | You. Covered on our AI gateway page |
| API gateway | A proxy in front of conventional HTTP services | Auth, routing, and quotas for requests generated by code | You. See AI gateway vs API gateway |
The practical takeaway is that an LLM gateway and an MCP gateway solve non-overlapping halves of the problem, and owning one does not cover the other. An LLM gateway sees the prompt going to the model and the completion coming back. It does not see the agent then call a payments tool, because that call goes to an MCP server, not to the model provider. Teams that route model traffic through a gateway and feel covered are usually missing the entire tool-call path, which is the half where irreversible things happen.
A registry deserves its own warning. Cataloging approved servers is genuinely useful, and it is not a control. A registry entry records that someone approved a server on a date. It does not re-check what that server publishes today, and it does not sit in the path to refuse a call. If your plan for MCP governance is a spreadsheet or a catalog, you have inventory, not enforcement.
MCP gateway security: what it is there to stop
The attacks below are documented, most of them in the MCP specification's own security guidance or in published research. A gateway is not equally effective against all of them, so the last column is deliberately honest about where the fix has to live somewhere else.
| Attack | How it works | What a gateway can do |
|---|---|---|
| Tool poisoning | Hidden instructions inside a tool description, which the model reads and the user never sees | Strong. Inspect the manifest at the proxy before the description reaches model context. See MCP tool poisoning |
| Rug pull | A server serves a benign definition at approval time and a malicious one later | Strong. Hash and pin definitions, compare on every fetch, flag on change |
| Poisoned tool output | A normal-looking result carries instructions the agent then follows | Strong. Treat the return path as untrusted input and inspect it |
| Cross-server shadowing | One malicious server publishes a description that alters how the agent uses a different, trusted server | Partial. Isolating servers per agent scope limits reach, but the model still sees both manifests unless you segment sessions |
| Token passthrough | A server accepts a token that was not issued for it. The MCP spec states servers MUST NOT do this | Partial. The gateway can issue correctly scoped downstream credentials, but a server you do not control still has to refuse foreign tokens |
| Confused deputy in OAuth proxying | A static client ID plus a consent cookie lets an attacker skip a consent screen | Weak. This is a flaw in the proxy or server's own consent flow. No gateway retrofits a correct consent implementation |
| SSRF during metadata discovery | A hostile server returns discovery URLs pointing at link-local or private addresses such as the cloud metadata endpoint | Strong, if the gateway is your egress point. Enforce HTTPS and block private and link-local ranges |
On the scale of the problem, the Cloud Security Alliance research note of July 2, 2026 reports benchmarking across more than 45 real-world MCP servers with attack success rates above 60 percent, and 72.8 percent against the strongest agent model tested. It also cites CVE-2025-54136, rated CVSS 8.8 and disclosed in July 2025, which established that approving a tool definition once does not survive later server-side changes. That single finding is the argument for pinning, and pinning is only enforceable somewhere that sees every fetch.
How to deploy an MCP gateway without breaking working agents
The order matters. Each step below is reversible and produces evidence before it produces enforcement, which is the only way to introduce a chokepoint in front of agents that people already depend on.
- Inventory what is actually connected. Collect every MCP config across every repo, notebook, and developer machine. This step alone usually finds servers nobody remembers approving. CSA research covering 445 practitioners, published April 2026, found 82 percent of enterprises have unknown AI agents in their environment, and the tool connections follow the same pattern.
- Point agents at the gateway, still allowing everything. Change the endpoint, not the policy. Nothing should break, because nothing is being denied yet.
- Watch in observe mode. Log every server contacted, every tool called, and every manifest fetched, for at least a couple of weeks. You are building the allowlist from evidence rather than from what the design document claims.
- Pin the tool definitions you have. Hash each approved manifest so a later change is a detectable event rather than a silent one. This is the control that catches rug pulls and CVE-2025-54136 style behavior.
- Allowlist servers, then scope tools per agent. Reaching a server is not the same permission as calling every tool on it. A read-only research agent has no reason to hold the write tools that server also exposes. See tool permissions.
- Turn on manifest and output inspection. Descriptions on the way in, results on the way back. Both are text the model will read as instruction. See prompt injection detection.
- Gate the irreversible calls. Deletes, transfers, external sends, and bulk operations get a human. Keep the low-risk majority automatic so the gate stays meaningful. See human in the loop.
- Switch to enforce and keep the trail. Observe mode has already told you what denying will break. The audit trail is what makes the whole arrangement provable to an auditor.
Per-agent identity is worth doing before step five rather than after. Shared credentials make the audit trail nearly useless, because every call attributes to the same service account. The CSA and Aembit survey of 228 practitioners released at RSAC 2026 found 68 percent could not distinguish AI agent activity from human activity in their logs. Scoping is only enforceable once you can tell callers apart, which is covered on AI agent identity.
What an MCP gateway does not solve
Worth stating plainly, because a pilot judged against the wrong expectation fails for reasons that have nothing to do with the product.
| Problem | Does an MCP gateway fix it? | What actually does |
|---|---|---|
| A malicious server's own OAuth consent flow | No | The server or proxy operator implementing per-client consent and exact redirect URI matching, as the spec requires |
| Agents that bypass the gateway entirely | No | Network policy and egress control. A chokepoint only governs traffic that goes through it |
| A tool that is genuinely dangerous by design | No | Not connecting it, or scoping it out. If a task legitimately requires deleting records, policy will allow it |
| Vulnerabilities inside a server you run | No | Ordinary application security on that server. See MCP server security |
| A model that is simply wrong | No | Evaluation and human review. A gateway judges permission, not correctness |
| Compliance on its own | Partly | It produces most of the evidence an auditor wants, but the program and owners are yours. See AI compliance |
The honest summary is that an MCP gateway narrows what a compromised or hostile server can achieve, and proves what every server was asked and what it answered. It does not make third-party servers trustworthy, and it governs exactly the traffic you route through it and nothing else. Pair it with runtime security across the rest of the agent path, because MCP is one surface among several.
FAQ
Common questions about mcp gateway.
What is an MCP gateway?
An MCP gateway is a proxy between your AI agents and the Model Context Protocol servers they call. It centralizes what each agent may reach, inspects tool manifests before their descriptions enter model context, detects definitions that change after approval, scopes which tools each agent may call, and records every call in one audit trail instead of leaving that policy scattered across per-agent config files.
What is the difference between an MCP gateway and an MCP server?
An MCP server exposes tools and resources over the protocol, such as a GitHub or database server, and it is often built by a third party. An MCP gateway is a proxy you run in front of many servers. The server provides capability, the gateway decides which agents may use that capability, with which tools and arguments, and inspects what passes in both directions.
How does an MCP gateway work?
Agents connect to the gateway rather than opening their own connection to each server. On every request the gateway checks the target server against an allowlist, checks the requested tool and its arguments against the scope granted to that agent, inspects the tool manifest and the returned result as untrusted input, holds irreversible calls for approval, and writes an append-only record of the decision.
What is the difference between an MCP gateway and an API gateway?
An API gateway fronts conventional services and handles auth, routing, and quotas for requests generated by code, so the set of possible calls is fixed. An MCP gateway fronts servers whose tool descriptions influence what a language model decides to call next. That feedback loop means the gateway must inspect content, not just route it, which an API gateway was never designed to do.
What is the difference between an MCP gateway and an LLM gateway?
An LLM gateway sits in front of model providers and governs prompts, routing, cost, and rate limits. An MCP gateway sits in front of tool servers and governs which tools an agent may call and what those tools return. They cover non-overlapping halves of the request path, so routing model traffic through a gateway leaves the entire tool-call path ungoverned.
Do I need an MCP gateway?
If your agents connect to more than two MCP servers, or to any server you did not build, then yes. Below that threshold, per-agent config is manageable. Past it, you cannot answer basic questions such as which agents reach which servers, whether a tool definition changed since approval, or what a given server was asked last Tuesday, and none of those answers exist without a common path.
How does an MCP gateway handle OAuth?
It terminates the agent side and issues correctly scoped credentials downstream, so a token minted for one server is never replayed at another. The MCP specification states servers MUST NOT accept tokens that were not issued for them. A gateway helps by not creating those tokens in the first place, but it cannot fix a server that accepts foreign tokens anyway.
Is an open source MCP gateway enough?
It depends which of the three jobs you need. Open-source projects handle connection management and cataloging well, and if pooling servers behind one endpoint is the goal, they are a reasonable choice. What they generally do not provide is per-agent authorization, manifest inspection for injected instructions, definition pinning, approval gates, and an audit trail an auditor accepts.
What are MCP gateway best practices?
Route all agent traffic through one path, run in observe mode before enforcing, build the server allowlist from observed traffic rather than intent, hash and pin approved tool definitions, scope tools per agent instead of per server, treat both manifests and tool results as untrusted input, gate irreversible calls behind human approval, and give every agent its own identity so the trail attributes correctly.
More use cases