MCP Gateway

What an MCP gateway is

An MCP gateway is a proxy that sits between your AI clients and the MCP servers they call. Every tools/call leaves the client, reaches the gateway first, and is evaluated against policy before it is forwarded upstream. The gateway allows the call, denies it, or hides the tool from the agent entirely, and can attach argument-level conditions and quota limits to whatever it does forward.

It is the same architectural idea as an API gateway, applied to agent tool calls: a single control point in front of many backends. The difference is what it inspects and who is calling. Not REST routes, but MCP method calls and their arguments, made by a non-deterministic caller that can be steered by the content it reads. The protocol is the transport. The gateway is the control plane the transport never shipped with.

Why MCP needs a gateway

MCP has no permission model. Connect an agent to a server and it gets every tool that server exposes, with no scoping, no limits, and no per-person identity. Three gaps follow directly.

• Unrestricted tool access. A server publishes its full toolset to any connected client. There is no native way to expose get_issue while hiding delete_repository. It is all or nothing.
• Scattered, shared credentials. Each server authenticates on its own terms, and those secrets end up copied into client configs on every machine. Nobody can say which person made which call, and revoking access means rotating a key everyone shares.
• Instructions are not a control. Telling the agent what not to do in a system prompt is not enforcement. A model can be talked out of a prompt through injection, or simply ignore it. The thing you are trying to constrain is the thing doing the reasoning.

You cannot enforce policy inside servers you do not control. You enforce it at the boundary every call has to cross.

What a production-grade gateway must do

Plenty of things will route MCP traffic and call themselves a gateway. The bar for one you can actually rely on is higher. A production-grade MCP gateway has to:

• Filter tools at the tool level, not the server level. Expose a subset of a server's tools and hide the rest. The unit of control is a single tool, with the ability to block one destructive action while leaving the rest of the server available.
• Evaluate every call before it runs. Enforcement is real-time and pre-execution, on the path. A gateway that logs what happened after the fact is better than nothing, but it is a recorder, not a control.
• Decide deterministically. An identical call yields an identical verdict, every time, with no model in the decision path. A control the model can reason about is a control the model can reason around. This is the property that makes the decision provable to an auditor and immune to being talked out of.
• Read the arguments, not just the tool name. The question is not "can this agent reach Stripe" but "can this call refund this amount". Conditions apply to any argument on the call.
• Issue per-person scoped tokens. Each person and each agent connects with its own revocable grant, never a shared key. Access is scoped per identity and offboarding is a single revocation that leaves everyone else untouched.
• Broker upstream credentials. The real API keys and OAuth tokens live in the gateway, encrypted at rest, injected only on an authorised call. They never land in a client config on a laptop.
• Make every decision provable, not just logged. Full attribution on every call — person, agent, tool, server, arguments, verdict, and the rule that fired — recorded so a decision can be verified independently, not taken on trust. Exporting a log you have to believe is a weaker claim than a decision you can check.
• Hold across every client and every server. One enforcement layer and one policy across Claude Code, Cursor, Codex, and the third-party servers you did not write and cannot modify. The same user gets the same rules whichever client they opened this morning.
• Detect upstream changes. When a hosted server adds or alters a tool, the gateway flags it and holds the new or changed tool denied by default until it is reviewed. Your last assessment should not silently expire the moment a vendor ships a release.

How to tell a real gateway from a logging proxy

Most of the difference shows up in a few direct questions. Run them in a demo, against the actual product, not a description of it:

• Default-deny or default-allow? With no policy written, does a tool call get blocked or waved through? The answer reveals the security philosophy.
• Before the call, or after it? Does enforcement happen on the path, before the call reaches the server — or is it a log written once the action already ran?
• Deterministic, or does a model decide? A probabilistic router that "intelligently selects" tools is making a judgement call. Enterprise enforcement needs an identical verdict for an identical request.
• One tool, or the whole server? Can you block a single action and one argument, or only toggle an entire server on and off?
• Provable, or just stored? Can you verify a past decision independently, or only read a log and trust it?
• One policy, or one per client? Does the same rule hold across every AI client, or does each app keep its own settings and its own gaps?

Because evaluation happens before the call is forwarded, a real gateway's decision is fixed. The model can reason around a prompt. It cannot reason around an action that physically never reaches the server. That is the whole point of the boundary, and it is the same architecture AWS validated with Cedar and the NSA described from the defensive side.

When you need one

A gateway earns its place the moment any of these is true:

• You run agents against more than one MCP server.
• More than one person uses those agents and you need to know who did what.
• Agents touch anything that costs money, deletes data, or sends messages.
• You answer to a compliance regime that expects an audit trail.

A single developer poking at one read-only server does not need a gateway. A team running production agents against Stripe, GitHub, Postgres, and a stack of third-party servers does, and the need is not optional. It is the difference between hoping the agent behaves and knowing what it is allowed to do. PolicyLayer is a hosted MCP gateway: you point your client at a URL, attach a per-person token, and every tool call is evaluated against policy before it runs.

Frequently asked questions