It must be the only door
Restrict your MCP servers so they can be reached only through the gateway. If an agent has any other route to a tool — a direct network path, its own credentials — then every control the gateway provides is optional, and the agent that most needs stopping is the one that will route around it.
Why it matters. A gateway you can bypass is not a control; it is a suggestion. Scanning, allow/deny, rate limits, and audit only hold if there is no other way to call the tool. The threat model is exactly the case where the agent is no longer cooperative — hijacked by prompt injection, or misaligned — so you cannot rely on the agent choosing to use the gateway. You have to make the direct call impossible, not discouraged. That is a network-and-credential property, not a code one.
How to make it non-bypassable
Three properties, each of which has to be true. None is optional.
- Network isolation on the agent side. The agent's runtime can open connections to the gateway and nothing else. Its egress policy blocks every other route — no direct path to tool servers, no arbitrary internet. (This is the same per-agent egress allowlist from Build-time, pointed at the tool plane.)
- Private, gateway-only servers. MCP servers bind to a private network segment with no public route, and they accept connections only from the gateway — enforced with mutual TLS, not just an IP allowlist. A server that answers anyone is a back door.
- The agent holds no tool credentials — and the ones the gateway injects are short-lived. The gateway owns each tool's credential and mints a short-lived, capability-scoped token per call, scoped to what that agent is allowed. An agent with no key cannot authenticate to a server even if it found a route; and a token that does leak expires in minutes and grants only that one capability, never standing access.
A gateway is only as good as its registry
An allow-control has to allow against something. Behind the gateway sits an MCP inventory: a registry of which servers and tools exist, who approved each, its vetted fingerprint, its trust tier, and which agent roles may use it. The gateway enforces; the registry is what it enforces.
Why it matters. You cannot allowlist, fingerprint-check, or role-scope a tool you have not catalogued. Most "shadow MCP" risk is exactly that: a server someone wired up that no inventory knows about, so no control references it. The registry closes the gap. It is also where rug-pull detection lives — the fingerprint the gateway re-checks on load is the one the registry recorded at approval — and where the role-to-tool map lives, so the gateway can filter the very list of available tools per agent, not just individual calls.
A workable registry entry carries, per tool: a stable identity namespaced to a verified server, the vetted fingerprint (a hash of description and schema), an owner and approval date, a trust tier, the agent roles permitted to call it, and a reference to its credential in the vault. The gateway reads it on every call. Nothing reaches an agent that the registry has not admitted.
What the gateway enforces, in order
Once every call has to pass through it, the gateway is where you apply the ecosystem controls consistently for every agent, instead of re-implementing them per agent. A single tool call runs this lifecycle. Order matters: cheap rejections first, the expensive forward last, and any failure resolves to a denial.
- Authenticate the caller. Identify which agent is calling — its own identity, not a shared service account. An unauthenticated call is denied. (This is the agent identity from the Agent concern; the gateway is where it's checked.)
- Authorize against the agent's role and identity. Check a least-privilege allowlist keyed to this agent's identity and role: may it call this tool with these argument shapes? Default deny — and the set of available tools is itself filtered by role, so an agent can't even discover, let alone call, the tools outside its remit. The allowlist and the role-to-tool map are read from the registry, not hard-coded per agent.
- Pre-flight scan the call and the tool. Verify the tool's fingerprint (a hash of its description and schema) against the vetted value to catch a rug pull; scan the tool metadata for hidden instructions; validate the arguments against the schema and for obvious exfiltration (a
urlfield pointing off-allowlist). - Forward with a short-lived injected credential. Only now does the call leave the gateway, over mTLS, carrying a short-lived, scoped token the gateway mints for that tool. The agent never saw a key, and the token expires fast.
- Post-flight scan the response. Treat the tool's output as untrusted input on the way back: redact secret-shaped strings before they reach the model's context or your logs, and block or sanitize responses carrying injected instructions. Data hygiene runs both ways.
- Meter, then audit. Record the call against the agent's quota and cost budget, then write an audit record — agent identity, tool, argument hash, verdict, latency — to an append-only trail.
- Fail closed. If any step errors — the scanner is down, the fingerprint store is unreachable, the policy engine times out — deny. A check that can't run is a denial, never a silent pass. A scanner that errors open is worse than none, because it sells false confidence.
Meter and control access through the choke point
Because every call passes through one place, that place is also where you meter tool access — and metering is a security control, not just an accounting one. The gateway already knows which agent called which tool, with what arguments, how often. Use it.
Why metering belongs in the gateway. A misaligned or hijacked agent's first visible symptom is often volume: a tight loop calling an API until the bill spikes, or bulk-reading a data source it should sip from. Per-agent, per-tool quotas turn that from an open-ended incident into a capped one. And because the gateway sits inline, the meter is also a throttle and a kill point — it can slow, cap, or cut off a single agent or a single tool without redeploying anything.
- Per-agent, per-tool quotas and rate limits. A cap on calls and on cost per window, scoped to the agent and the tool. Exceeding it throttles or denies, and alerts.
- Cost attribution. Every call is priced and attributed to an agent, a tenant, and an owner — so spend is answerable to "which agent did this?" the same way actions are.
- Anomaly signals. A baseline per agent and tool; flag a sudden change in call rate, argument entropy, or off-pattern tool combinations as a security event, separate from quality monitoring.
- A central cut-off. The gateway is the one place that can revoke an agent's access to one tool, or quarantine a tool across all agents, instantly — the ecosystem half of the kill switch.
A minimal build
You do not need a platform to start. A gateway is a reverse proxy for MCP with a few responsibilities bolted on. The smallest honest version has seven parts:
- A proxy front end speaking MCP to agents and to servers — the single endpoint every agent is configured (and network-restricted) to use.
- A registry / inventory — the source of truth above: approved servers and tools, each with a fingerprint, owner, trust tier, permitted roles, and a credential reference.
- A policy engine evaluating the registry's allowlist, role filter, and quotas on every call, default deny.
- Scanners for the tool fingerprint, tool metadata, request arguments, and response body — each able to block, sanitize, or log.
- A credential broker (a secrets vault) that holds tool credentials and injects the scoped one per call, so agents never hold keys.
- A meter recording calls and cost per agent and tool, enforcing quotas, emitting anomaly signals.
- An append-only audit sink capturing every decision for attribution and forensics.
Wrap all six so that any internal failure returns a denial to the agent. Then enforce the three non-bypass properties around it — isolated agents, private gateway-only servers, no agent-held credentials — and you have a real gateway rather than a hint.
Reference implementation. You don't have to invent the spec. Microsoft's open MCP Security Gateway 1.0 (part of the MIT-licensed Agent Governance Toolkit) is a conformance-tested spec for the interception, scanning, schema-drift detection, and fail-closed semantics described here. BRACE defines what to enforce at the MCP boundary and why it must be the only door; that spec is one concrete way to build the box.
Three ways a gateway quietly fails
Each of these looks like a gateway in an architecture diagram and isn't one in practice.
Gateway go / no-go
A short gate for the MCP boundary. It extends Principle 5 of the Ecosystem guide.
- Agents are network-restricted so the gateway is their only route to any tool server.
- MCP servers are on a private segment and accept connections only from the gateway, over mutual TLS.
- Every MCP server and tool is in an inventory/registry — fingerprint, owner, trust tier, permitted roles — and the gateway admits only what is registered.
- Tool credentials live in the gateway and are injected as short-lived, scoped tokens per call; agents hold none.
- Every call is authenticated to a specific agent identity and authorized against a registry-backed, role-scoped allowlist (default deny); the list of available tools is filtered by the agent's role.
- Calls and responses are scanned, the tool fingerprint is re-checked, and any check failure denies (fail closed).
- Per-agent, per-tool quotas and cost metering are enforced, with anomaly alerts and a central cut-off.
- Every decision is written to an append-only audit trail.
Keep going
Ecosystem — multi-agent & supply chain
The six principles the gateway enforces, in context.
RelatedBuild-time — bound the blast radius
The egress isolation that makes the gateway the only door.
RelatedRun-time — data hygiene both ways
Why the gateway scans responses, not just calls.