An MCP server exposes tools. delete_repository
, create_charge
, execute_query
. The agent calls whatever it decides to call, and the server runs it. Nothing sits in between.
Connect a coding agent to a GitHub MCP server and it can delete a repository as readily as it can read one. Point it at a Stripe server and create_refund
is one tool call away from list_charges
. The Model Context Protocol defines how tools are discovered and invoked. It does not define who is allowed to invoke what. An MCP gateway is the layer that adds that missing decision.
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, and can attach argument-level conditions and quota limits.
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: 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 a transport. The gateway is the control plane that the transport never shipped with.
MCP has no permission model. When you connect an agent to a server, 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: a bearer token here, an API key there, an OAuth flow somewhere else. Those secrets end up copied into client config files on every developer machine. Nobody can say which person made which call, and revoking access means rotating a key everyone shares. We found exactly this pattern when we scanned open-source MCP configs.
Instructions are not a control. The common fallback is to tell the agent what not to do in a system prompt. That is not enforcement. A model can be talked out of a prompt through injection or simply ignore it, and system prompts are not transport firewalls. Prompt guardrails fail precisely because 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.
A gateway turns the protocol boundary into a control point. The capabilities that matter:
| Capability | What it does |
|---|---|
| Tool filtering | Expose a subset of a server's tools; hide the rest entirely |
| Per-call policy | Evaluate each tools/call against deterministic rules on any argument |
| Scoped grant tokens | Issue scoped, revocable access per person or agent, not one shared key |
| Credential brokering | Hold upstream API keys and OAuth at the gateway, never in the client |
| Audit trail | Log every call, decision, and the policy path that fired |
| Multi-client | One enforcement layer across Claude Code, Cursor, Codex, and the rest |
Because evaluation happens before the call is forwarded, the decision is deterministic. The model can reason around a prompt. It cannot reason around an action that physically never reaches the server. That is the core of MCP policy enforcement, and the reason the control belongs at the transport layer.
| Approach | Strength | Limitation |
|---|---|---|
| Per-server config | Native to each server | No server ships scoping; nothing is consistent across servers |
| Client-side rules | Close to the agent | Trivially bypassed; every client reimplements it |
| Prompt guardrails | No infrastructure | Not enforcement; defeated by injection |
| MCP gateway | One deterministic control point across every server | You route traffic through it |
The gateway is the only option that holds regardless of which server you call, which client the agent runs in, or what the agent was prompted to do.
A normal tool call is a JSON-RPC request. The agent asks the server to run a tool with arguments:
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "create_refund",
"arguments": { "charge_id": "ch_105", "amount": 500000 }
}
}
Routed through a gateway, that request is evaluated against policy first. If a rule caps refunds, the call is blocked before it reaches Stripe, and the agent receives a tool result marked isError
— a failed tool call it can reason about and adapt to, not a transport crash:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [
{ "type": "text", "text": "[POLICY DENIED] Refund exceeds the policy limit." }
],
"isError": true
}
}
Pointing a client at the gateway is a config change, not a code change. You swap the upstream server URL for your gateway endpoint and attach a scoped token:
{
"mcpServers": {
"stripe": {
"url": "https://proxy.policylayer.com/mcp/<server-uuid>/",
"headers": { "Authorization": "Bearer <grant-token>" }
}
}
}
The agent still sees an MCP server. It just sees one with a policy in front of it.
A gateway earns its place the moment any of these is true:
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.
Control what your agents can do through MCP.
Get started now →. The product is live.
Browse the policy library →. Pre-classified tools across thousands of MCP servers.
Read the MCP security reference →. What the boundary looks like.