MCP Gateway: What It Is and Why Agent Fleets Need One A developer proposes an MCP gateway as a missing control layer for AI agent fleets, addressing the Model Context Protocol's lack of permission models. The gateway sits between AI clients and MCP servers, enforcing tool filtering, per-call policy, credential brokering, and audit trails. It provides deterministic enforcement that system prompts cannot guarantee. 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 https://policylayer.com/blog/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 https://policylayer.com/blog/system-prompts-vs-transport-firewalls . Prompt guardrails fail https://policylayer.com/blog/why-prompt-guardrails-fail-agent-safety 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 https://policylayer.com/blog/what-is-mcp-policy-enforcement , and the reason the control belongs at the transport layer https://policylayer.com/blog/runtime-governance-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/