MCP Gateways: What They Cover and What They Miss
An MCP gateway is a proxy that sits between your agents and the MCP servers they call, inspecting that traffic and applying policy to it – allowing, blocking, logging, or rewriting requests as they pass. For MCP traffic it works well, and it is a reasonable first control for an organization standardizing on MCP. Its limits are structural rather than immature: a gateway sees the traffic that crosses it, which means tool types that never cross it are invisible, and in most gateway products the component doing the inspecting is also the component doing the enforcing.
What is an MCP gateway?
The Model Context Protocol standardizes how agents connect to external tools and data sources. An MCP gateway applies the familiar proxy pattern to that protocol: instead of each agent connecting directly to each MCP server, connections route through a central point where policy can be applied.
In practice a gateway typically offers some combination of a central registry of approved MCP servers, authentication and credential brokering so individual agents don’t hold long-lived secrets, allow and deny listing by server or by tool, request and response logging, and rate limiting. Some add scanning of tool definitions for known-malicious patterns.
This is genuinely useful. It gives a security team a single place to see which MCP servers are in use, a way to stop an agent reaching a server it shouldn’t, and a credential boundary that doesn’t depend on every developer handling secrets correctly. If your agents are standardized on MCP and your main worry is which servers they reach, a gateway addresses that directly.
What do MCP gateways cover well?
Three things, and it’s worth being specific rather than damning with faint praise.
Server-level access control. Deciding that agents may reach an internal documentation server and may not reach an arbitrary community-published one is exactly what a gateway is built for, and it does it reliably.
Credential brokering. Having the gateway hold credentials and vend scoped tokens is better practice than distributing long-lived secrets to every agent that needs them, and it gives you one place to rotate.
A traffic record for MCP calls. For anything that passes through it, a gateway produces a log. That’s a real input to investigation, and it’s more than most organizations have.
What can’t an MCP gateway see?
Four gaps, each following from the architecture rather than from any product’s maturity.
Tool types that don’t produce gateway traffic. MCP is one way an agent gains a capability. Skills, plugins, extensions, packages, and SaaS connectors are others, and they behave differently. Skills in particular are defined inside the agent’s own configuration and don’t generate an outbound call to an MCP server for a gateway to intercept – which makes them a known blind spot for gateway-only approaches, not because gateways are badly built but because there is nothing at the boundary to inspect. This is the same distinction covered in MCP vs Skills.
Agents that route around it. A gateway governs the agents configured to use it. An agent running on a developer’s machine with a directly configured MCP server, or an unsanctioned agent nobody registered, simply doesn’t appear. Gateway coverage is a function of adoption, and adoption is exactly what’s uncertain in an environment with shadow AI and agent sprawl.
This last point turns out to be what organizations furthest along with gateways actually worry about. A recurring pattern among teams that have already built one – including those running an internal registry of pre-approved servers scoped by role – is that they don’t want the gateway replaced. They want a way to confirm it’s being used: that coding agents and assistants on endpoints are genuinely routing through it rather than pulling an MCP server directly from an open-source repository. A gateway is a control, and like any control it can’t attest to its own coverage. That question has to be answered from outside it.
Why the agent made the call. A gateway sees a request arrive. It doesn’t see the instruction that produced it, the context the agent was operating in, or what the agent was told about why it needed the tool. A legitimate-looking request generated by a prompt-injected agent and the same request generated by an agent doing its job are identical at the boundary.
Anything between the edges. This is the general form of the point. A gateway operates at the boundary where an agent’s traffic exits toward a tool. That’s one stage of the agent lifecycle. What the agent was instructed to prioritize, what it retrieved into context, why it chose one tool over another, what it retained from a previous turn – none of that crosses a network boundary, so none of it is visible to a control that only watches boundaries.
The evidence that these gaps are material rather than theoretical: a British bank had already run employee surveys and deployed MCP gateways for its developer population, and a subsequent assessment still surfaced significantly more tool connections than those efforts had captured – concentrated in exactly the tool types a gateway never sees.
Why does it matter that the gateway is both the inspector and the enforcer?
This is the architectural question worth asking, and it applies to proxy-based controls generally rather than to MCP gateways specifically.
In most gateway products, the component that intercepts traffic is the same component that applies policy. Interception and enforcement are fused. Three consequences follow:
Coverage caps control. Anything the gateway can’t see, it also can’t act on. The blind spots above aren’t just visibility gaps, they’re enforcement gaps, and the two can’t be addressed separately.
Enforcement is blunt. What a proxy can do at an interception point is essentially allow or deny. That produces a fail-open or fail-close binary with no room for the context that would distinguish an agent in finance legitimately processing financial data from an agent in marketing that shouldn’t be. Both requests look the same crossing the wire.
It’s a single point of failure in the execution path. Every governed agent call depends on the gateway being available and fast. At enterprise volumes this becomes an operational question rather than a security one. One hedge fund put it plainly: downtime from failed controls could cost more than a security incident. That’s the concern that makes proxy architectures hard to scale to environments running hundreds of thousands of agent operations daily.
There’s also a quieter maintenance cost. A gateway has to be kept current with the MCP estate behind it, so as teams add servers the routing layer needs revisiting – a re-architecture tax that grows with adoption rather than leveling off.
One further consideration comes up less often and is worth more attention than it gets. A security engineer at one organization framed the gateway as a two-way risk rather than a one-way control: the useful thing about an MCP server is reading from it, but a connection that reads is also a connection that can send. Their concern was outbound – what an agent might transmit to a third-party server in the course of a legitimate-looking call. Most gateway evaluations focus on whether an agent should reach a server at all, and comparatively few ask what leaves the organization once it does.
Separating the two changes the shape of the problem. Multiple interception mechanisms across cloud, code, endpoint, and browser can feed a single enforcement layer that applies controls through the agent’s own configuration and context rather than at a chokepoint in its execution path. Coverage stops being capped by any one sensor’s reach, enforcement gains enough context to be specific rather than binary, and there’s no queue for agent traffic to wait in.
Should you deploy an MCP gateway?
If you’ve standardized on MCP and want server-level access control and credential brokering, yes – it does that job and it’s a reasonable place to start. The question isn’t whether to have one. It’s what you assume it covers once it’s deployed.
The failure mode worth naming is treating gateway deployment as the completion of agent governance rather than one component of it. Three questions will tell you where you stand:
- What proportion of your agents’ capabilities arrive through MCP? If skills, plugins, and SaaS connectors are also in use, the gateway is covering a slice, and you should know roughly how large that slice is.
- How do you know every agent is actually routed through it? If the answer relies on developers configuring it correctly, treat coverage as a floor rather than a fact. This is the question teams with mature gateway deployments raise most often, and it isn’t answerable from gateway logs alone – those show you what arrived, not what went elsewhere.
- What happens when the gateway is unavailable? Whether the answer is fail-open or fail-close, both are bad on a busy day, and the choice you’ve made is worth making deliberately.
A gateway and agent-level instrumentation are complementary rather than competing. The gateway covers the traffic it can see; instrumentation that reads the agent’s own configuration covers the tool types and decision context the gateway structurally cannot. The mistake is assuming one substitutes for the other.
Common questions
Is an MCP gateway the same as an API gateway?
The pattern is the same and the object differs. An API gateway manages traffic to APIs: routing, authentication, rate limiting. An MCP gateway does that for MCP specifically, adding awareness of MCP concepts like tools, resources, and prompts, so it can apply policy at the level of an individual tool rather than just an endpoint. Some organizations run MCP traffic through an existing API gateway and get part of the benefit without the protocol-level granularity.
Does an MCP gateway stop prompt injection?
Partially, and not structurally. A gateway can inspect tool definitions for known-malicious patterns and screen request content, which catches some attempts. What it can't do is see the injected instruction in the agent's context that caused the request, because that never crosses the gateway. An agent successfully manipulated into making a request it's permitted to make produces traffic the gateway has no reason to block. Published research across several platforms converges on the finding that interception and approval mechanisms can themselves be circumvented by a sufficiently crafted injection, which is an argument for layering rather than for relying on any single control.
Do MCP gateways add latency?
Yes, necessarily – you've inserted a network hop into the agent's execution path. For most workloads it's tolerable. It becomes material at high agent volumes, for latency-sensitive workflows, and during gateway degradation, which is when the fail-open or fail-close decision stops being hypothetical. Worth load-testing against your actual agent concurrency rather than a vendor benchmark.
If we have an MCP gateway, do we still need agent discovery?
Yes, and the relationship is worth getting the right way round. A gateway tells you about the agents that use it. Discovery tells you which agents exist. If those two numbers match exactly, discovery confirms it, which is a useful thing to know. In practice they rarely match on the first pass, and the gap is the interesting part.
