MCP gateways: The thing that sits in front of your MCP servers
· 10 min read · Blog
An MCP gateway decides which tools an agent can reach and which it cannot. What it controls, what it does not, and how it differs from an LLM gateway.
AI agents and MCP (Model Context Protocol) servers are where automations become really powerful.
Together, they allow AI systems to access external data sources, call out to tools, and perform actions across your entire stack.
However, that very reach brings risk, sensitive data exposure, quite limited visibility over what your AI agents and MCP servers are doing, and there's no clear control plane if things go south. In short, the potential blast radius for agents creating issues becomes very big.
An MCP gateway is one way of solving that problem. It introduces order, authenticates and enforces policies within your MCP environment, sitting between every MCP client and the many MCP servers they are contacting, so all governance is handled in one spot rather than being bolted onto each connector one by one.
For any organization deploying AI agents against live production systems, an MCP gateway has rapidly shifted from being an option to being crucially necessary.
In this guide, we'll explain exactly what an MCP gateway is, what it does and doesn't do, how it differs from an MCP proxy and an LLM gateway, when your team might need one, and most importantly, what it simply cannot protect you against.
What is an MCP gateway?
An MCP gateway is a broker between MCP clients and the MCP servers they contact, centralizing authentication, routing, logging, and policy enforcement in one location rather than repeating them in each connector.
MCP stands for Model Context Protocol, an open protocol released by Anthropic on 25 November 2024 and donated to the Linux Foundation's Agentic AI Foundation on 9 December 2025. It defines exactly how an AI application establishes a connection with external tools and data.
You can think of an MCP server as the entity that exposes tools and data over MCP: a connector to Salesforce, a file system, a database. The MCP host is the AI application that contacts it — a chat client or a programming assistant — and it runs one MCP client for each server it connects to.
There's a widespread assumption that MCP was created to increase the capabilities of AI agents. However, the opposite is much truer to reality: MCP was created to restrict them. It lays down exactly what they can get access to and how. A gateway carries that logic and acts like the control plane for your entire MCP ecosystem.
What exactly does an MCP gateway really do?
Understanding the MCP gateway requires taking into account the six fundamental things that the industry largely accepts. These cover all aspects of what actual gateway-level control will appear as over an MCP stack.
The six capabilities
Every serious MCP gateway provides some form of these six capabilities:
1. Inventory and discovery. The gateway holds a record of the MCP servers that are connected and the tools presented by each server. You can see your entire MCP environment in one spot.
2. One endpoint. Instead of every AI agent establishing a separate connection to each MCP server, all agents hit one URL. That gives you one identity surface, one policy layer and one audit log.
3. Determination of the client making the call. The gateway immediately identifies who or what is making the MCP request. This is the non-human identity (NHI) problem: the caller is a machine, a service, or an agent instead of a human being.
4. Permissions by tool. Rather than setting up access on a server-by-server basis, a gateway may establish access controls at the level of each individual tool.
5. Curating your catalog. The gateway decides which tools an agent should find. The specification is clear: the list of tools might be different with every request because of the authorization given, since credentials are given for each request too.
6. One audit log. Every MCP tool call goes through one location, so every single call is recorded there. That audit trail is vital for incident response.
All six are elements of the connection, not the decision-making process. They reveal what was called, by whom, and when. However, they don't show you whether the call should have happened.
What is the difference between an MCP proxy and an MCP gateway?
In vendor terminology
In everyday vendor parlance, an MCP proxy and MCP gateway essentially mean the same thing. There isn't an accepted, industry-wide way to tell them apart. Vendors aren't misusing a technical term here - the term is overused and the specification doesn't even provide a definition of 'MCP gateway'.
In the specification
What MCP's security guidelines outline is a very narrow OAuth role called an "MCP proxy server": an MCP server that acts as a link between MCP clients and third-party APIs, giving out MCP functions whilst handing over operations and acting as a single OAuth client to the third-party API server. It has a very challenging requirement alongside it: "to prevent confused deputy attacks, MCP proxy servers are required to have per-client consent and to implement appropriate security controls."
That 'must' is the countermeasure against an attack requiring all four of the following conditions occurring simultaneously: a fixed client ID using a third party's authorization server, a dynamic client registration process so that every MCP client gets its very own client_id, a third party's consent cookie right after the initial authorization and no per-client consent prior to forwarding.
The practical takeaway from this is as follows: if the product you are currently evaluating terminates OAuth on behalf of your end users and displays a single, static client ID to the systems behind it, then that is an MCP proxy server according to the specification's definition - regardless of what it calls it. Per-client consent is a 'must'. This would be something to ask during your vendor call.
The token rule: One of the most important parts of the MCP specification says
A gateway is a server to the client and the client to the backend at the same time. That means the authorization specification binds it twice. The specification says that MCP servers should never accept or pass through any token that wasn't issued by their own authorization server. MCP clients should never send tokens to an MCP server except for those issued by that server's own authorization server.
What is the difference between an MCP gateway and an LLM gateway?
The answer is short: different traffic at different layers, and one does not replace the other.
An LLM gateway acts as a broker between an application and model suppliers, directing prompts, managing costs and controlling rate limits. An MCP gateway acts as a broker between an AI agent and the tools it invokes, which occurs once the model has determined that a tool invocation should take place.
Speakeasy really nails it: the LLM gateway governs the discussion between the agent and the model. The MCP gateway governs the conversation between the agent and the tools. Noma Security states essentially the same thing in a much more concise manner: AI gateways deal with the model side, MCP gateways deal with the tool side.
A business can actually operate both. Several firms (Netskope, Kong, Azure API Management, Cloudflare, Traefik and Gravitee) are shipping MCP support right inside their pre-existing API gateway products as opposed to developing them as separate tools. This implies that a team that is currently managing an AI gateway might be pretty close, but still far off from having the complete picture.
When do you need an MCP gateway?
Published thresholds actually exist, but these are all simply stated rather than based on evidence. Truly comprehending what these state and exactly where they come up short will assist you in establishing a far more realistic benchmark for your very own scenario.
What the industry is saying
The published thresholds gather around two and five MCP servers. Explore Agentic expresses it like so: "beyond three servers within the same environment nearly always yes. By server number five you probably have had to build out the majority of a gateway yourself."
Kong describes having four or more servers as a management overhead trigger point. MCP Beast views things somewhat differently: "that first server capable of writing to a production dataset or spending money, then you'll definitely need policies and audits."
Our threshold
We couldn't find a published threshold that holds up under scrutiny, so here's ours. You'll need an MCP gateway if both these conditions are true:
- More than one team is using MCP connections to a system of record.
- You can't say "which MCP servers are running here?" from one place.
If both of those are true, you already have a governance problem and a gateway would help with it. If neither is, you probably don't need one yet.
Can an MCP gateway stop prompt injection?
No. This is fundamentally inherent within the structure, not a shortcoming of any particular vendor's implementation. Understanding this helps you set the right expectations before you deploy.
Why the structure means it can't be prevented
Your gateway stands at the top of the JSON-RPC transport between the MCP client and the MCP servers it contacts. Injection prompts are part of what gets into the model's context - which resides on the opposite side of the client. Your gateway won't even be able to see that content.
This isn't a product shortcoming. It's purely a consequence of your gateway's place in the workflow sequence. Operant AI claims its gateway identifies prompt injections, jailbreaks, tool poisoning and unauthorized access patterns throughout all MCP client-server communications in real time. Such statements must be tested using the available evidence.
Back in October 2025, a team at Google DeepMind, along with their partners, carried out attacks on twelve completely different publicly accessible countermeasures against prompt injection and jailbreaking, using adaptive approaches each time - aiming for a constant change in the nature of the attack to evade the defense's very design features, rather than just playing back pre-defined strings.
Their paper recorded attack success rates of more than 90% against virtually every one of the countermeasures they tested - including four content-filtering models almost identical to those that your gateway would use to scan traffic. Protect AI's detector, Meta's PromptGuard and Google Cloud's own Model Armor were all vulnerable to over 90% of the attacks.
Simon Willison noted in January 2025: "In terms of security, a filter that catches 99% of attacks is basically pointless. The objective of an adversarial attacker is to establish that very small fraction of attacks that will continue to succeed."
Anthropic's own research too demonstrated a residual attack success rate of one percent whilst scanning the content as it was entering the model's context frame - having a much better view than any gateway ever could hold. "No browser agent is resistant to prompt injection and we present our results here to show progress rather than saying this problem has now been totally solved."
What an MCP gateway cannot do
Every webpage ranked under this particular search term essentially forms an endless list of capabilities. This is something your competitor will have difficulty improving next month because it's not just a product statement; it's a description based on how the pattern actually operates.
A gateway will see the tool calls but won't know whether that particular call was meant to be made.
Every single signal defining a read operation from a write operation depends upon the server you're actually trying to restrict access to. The July 28, 2026 protocol version offers far more details than previously existed. The tool name arrives as a required HTTP header and the tool annotation includes readOnlyHint and destructiveHint.
However, the protocol schema says: "All properties within ToolAnnotations are hints. They aren't assuredly going to provide an accurate description of the tool's behavior. Clients should never base their decision about tool use on ToolAnnotations obtained from a server they can't trust."
In fact, a gateway can enforce policy based on the string update_opportunity. It can't be certain that a tool named update_opportunity will behave precisely as described. Nor can it tell whether the call should have happened at all.
The control determining whether you're dealing with a governance issue isn't "which MCP servers this agent is contacting", it's "can this agent create a change without anyone actually authorizing it?" Two limitations really need to be clearly identified because acknowledging them makes everything else appear much more reasonable.
First: A gateway can't see a server that it isn't right in front of. An MCP server started by the AI application itself — on any machine running that app, not just a developer laptop — skips the gateway whenever the app starts the server itself, and back in April 2026 OX Security Research documented remote code execution risks in that local transport.
Second: If a gateway never observes the model's context, it won't have the slightest idea why a particular call was made. In September 2025, a malicious MCP server was spotted on npm that sent out copies of all emails it sent to an address controlled by its author.
Over the wire, it looked no different than a regular send-email call that returned a regular success. There was absolutely nothing unusual for an intermediary to notice because the data exfiltration happened entirely on the server-side and left via a completely separate route altogether (Koi Security via the Hacker News).
Common questions
What is an MCP gateway?
An MCP gateway acts as a mediator sitting between MCP clients and the MCP servers they contact, centralizing authentication, routing, logging and access control in a single control plane, so that policy enforcement happens only once rather than having to be redefined in each connector across your entire MCP ecosystem.
Is there an MCP gateway?
Yes, numerous ones, and they aren't all part of one product. [Docker's open-source](https://docs.docker.com/ai/mcp-gateway/) gateway is described as a centralized proxy between clients and servers that handles configuration, credentials, and access control. Kong's gateway sits on top of their pre-existing API gateway infrastructure, adding a level of trust and control for proxying MCP traffic.
What is the difference between an MCP proxy and an MCP gateway?
In vendor parlance, the two terms are used almost interchangeably. Within the MCP specification, "MCP proxy server" refers to a rather specific OAuth role, namely, an MCP server that acts as a front end to a third-party API and behaves like a single OAuth client towards it, although it has a strict per-client consent requirement built in to stop confused deputy attacks.
What is the Microsoft MCP gateway?
The Microsoft MCP gateway is an open-source repository from Microsoft, described as a reverse proxy and management layer for MCP servers, with session-aware routing for Kubernetes environments. It is a deployable component rather than a hosted product. Protocol version 2026-07-28 removed protocol-level sessions, so that routing now sits above the protocol.