What an MCP gateway does
The Model Context Protocol standardised how agents connect to tools. One standard beats fifty bespoke integrations, and MCP won. What it did not standardise is how those connections are secured, and the gap between the two is where the incidents have been.
An MCP gateway closes part of that gap. It is a single endpoint in front of your MCP servers. Instead of every developer’s harness and every agent connecting to every server, they connect to the gateway. From that position it can do useful things:
- keep an inventory of the MCP servers behind it and the tools they expose, so someone can finally list what is running and who owns it
- validate the access token on each request, as the MCP authorization specification requires of any MCP server acting as a resource server: the token must have been issued for that server, and a token issued for something else must be rejected
- refuse to pass a client’s token through to an upstream API, which the specification forbids because it creates a confused-deputy problem
- pin tool versions and let a person review tool descriptions before an agent loads them, which is the cheapest defence against tool poisoning and almost nobody does it
- rate-limit and log
If you run more than a handful of MCP servers, you need something in that position. That part of the answer is not in dispute.
What it does not cover
The harder question is what a gateway in front of MCP servers cannot see, because those are the things a security review will eventually ask about.
The principal
The MCP authorization flow issues a token to the MCP client for use at the MCP server. When the MCP server then calls an upstream API, the specification is explicit that it uses a separate token, issued by the upstream authorization server, and must not forward the client’s token.
So the downstream system sees the MCP server’s credential, not the human’s. Whether this developer, or this agent acting for this customer, was allowed to take this action on this system is a question the gateway was never handed. It knows a valid token arrived. It does not know whose authority the call carries, and it cannot insist that a high-risk action wait for that person to be verified.
The chain across protocols
A gateway governs one protocol at one hop. Real work does not stay in one protocol. An assistant reads a document through MCP, calls a payments service over REST, and hands off to another agent that updates three systems. The MCP gateway saw the first step.
Two consequences follow. Policy written at the gateway is policy for the MCP slice of the chain only. And when something goes wrong, stopping the agent at the gateway leaves everything it already set in motion still running. Containment has to cover the whole chain, and the chain is not an MCP concept.
Evidence
Gateway logs are useful for debugging and useless for proof. They are held by the team that runs the gateway, they can be edited by that team, and an auditor has no way to check they have not been. A log you control is not evidence.
Evidence for an agent action needs to tie the action to the identity that made it and the authority it acted under, record the decision and the outcome, and be tamper-evident in a way a third party can verify without trusting the console that produced it.
A gateway with a policy tab is still a gateway
Many gateways now advertise policy. Read the policy carefully. It is usually allow-or-deny by tool name and by client, applied at the MCP hop. That is worth having and it is not the same as an enforcement point that checks who the agent is, what it may reach across APIs, other agents and MCP servers, what the whole chain is doing, and whether a person needs to approve this particular action before it happens.
Most of what is sold under the MCP-security label observes the MCP boundary. The gap is enforcement at the moment of action, wherever in the chain that action lands.
Where KPATH’s governed MCP endpoint sits
KPATH treats MCP as one of the protocols it governs, alongside REST calls and agent-to-agent calls.
For a development team, KPATH exposes one governed MCP endpoint. A developer’s harness, whether Claude Code, Cursor or Copilot, connects to that endpoint and it fans out to every approved tool: repos, internal systems, the web. Policy is per developer. Tools the developer is not allowed to reach are not listed, and the same enforcement point covers what the harness does outside MCP.
For an enterprise estate, MCP clients are simply another class of non-human caller. Every governed call passes through the same enforcement point before the payload reaches the target. It verifies the agent’s identity and, where the agent acts for a person, the person; applies least-privilege policy, budgets and inline human approval; can stop one agent or the whole in-flight chain; and writes a signed, tamper-evident record to your SIEM that an auditor can verify offline, without trusting KPATH.
KPATH governs the request envelope only: identity, target, action, size, delegation chain. Of the payload, it reads only the values you declare for a rule, such as a payment amount. Tool arguments and results pass through unread; if you run a content guardrail, it runs inline as a policy step inside your boundary.
Do you need one?
You need something in front of your MCP servers. The decision is whether that something is a routing layer you will later have to wrap in an enforcement point, or the enforcement point itself with MCP as one of the protocols it governs.
Start in monitor mode: point the harnesses at the governed endpoint, see which servers and tools are actually used, and enforce no policy until you choose to.