MCP gateway
An MCP gateway is a security proxy that sits in-band between your AI agent and the MCP servers it uses: the agent connects to the gateway instead of the raw server, and the gateway forwards every JSON-RPC message — the initialize handshake, tools/list and each tools/call — while inspecting both the request and the response. Because tool descriptions and outputs flow straight into the model's context, the gateway is the one place you can catch tool poisoning, prompt injection, data exfiltration and silent tool drift at the moment they happen — and, in active mode, strip or block the danger before it ever reaches the agent. You need one because a per-server audit certifies a server only as it was at probe time, whereas a gateway enforces safety on live, real-time traffic.
What an MCP gateway is
The Model Context Protocol (MCP) is an open JSON-RPC 2.0 protocol that lets an AI host connect to external servers. The host runs one MCP client per server, performs a capability handshake, then discovers and calls that server's tools, resources and prompts over a transport — stdio for local servers, Streamable HTTP for remote ones (with legacy HTTP+SSE still seen in the wild).
An MCP gateway is a proxy that speaks MCP on both sides: it is an MCP server to your agent and an MCP client to one or more real backend servers. Your agent's config points at the gateway URL (with a bearer token) instead of the raw backend, so every JSON-RPC message — the initialize handshake, tools/list, and each tools/call — passes through it.
On the way through, the gateway proxies the call to the real backend and inspects what comes back. Tool definitions and tool outputs are exactly the text an MCP client feeds into the model's context, so the gateway sits on the one chokepoint where untrusted server content becomes agent instructions. That position lets it observe, log, redact, or block per call.
A gateway is in-band (it is on the live request path), which distinguishes it from an out-of-band audit that probes a server once and walks away. The trade-off is that an in-band proxy adds a small amount of latency to every tool call — which is why a good MCP gateway keeps its checks cheap (regex patterns, hash comparisons) rather than slow.
Why you need one: the audit-vs-runtime gap
A one-time audit answers "is this server safe right now?" — useful, but it certifies the server only at probe time. Two things break that guarantee in production. First, tool-output prompt injection: a server can pass a clean static audit of its schemas and still return attacker-authored text on a specific query (a fetch/search/read-page tool relaying a poisoned web page, email, or issue comment). Second, the rug pull: MCP clients re-read tools/list every session and trust whatever the server returns, so a server you approved can silently rewrite a description, add a hidden instruction, or widen a tool after the fact — with no further human approval.
Neither of these is visible from a single snapshot. They only appear in live traffic, which is precisely what a gateway sees. The gateway re-checks the tool surface against a pinned baseline on every session (catching drift and rug pulls in-session) and scans each tool response for injection, exfiltration and leaked secrets (catching the runtime payloads a static scan cannot).
This is also where the lethal trifecta becomes concrete. A static check flags a server whose tools combine untrusted-content ingestion, sensitive-data access, and an outbound or destructive path. A gateway can do more than flag it: it withholds the specific poisoned response that would have turned that capability mix into an actual breach.
What a gateway inspects and enforces
On tools/list, the gateway fingerprints the returned tool set (the sorted tool names plus a hash of each schema) and compares it to a pinned baseline. A breaking change — a tool removed, renamed, or mutated without a version bump — is flagged as drift or a rug pull. It can also apply an allowlist so the agent only ever sees approved servers and tools.
On each tools/call response, it runs the same output analysis a behavioral eval uses: multilingual injection patterns ("ignore previous instructions", hidden "do not tell the user" directives), exfiltration vectors (output pushing the agent to send data to an external destination), and credential- or PII-shaped strings in the returned data. A high-severity hit is recorded and, in active mode, the poisoned output is withheld and replaced with a safety notice so the agent never reads it.
A gateway typically runs in one of two postures. Passive mode proxies everything unchanged and only observes, logs and flags — you run this first to see what your servers actually return and to build trust without risk. Active mode enforces: it can block a backend whose score is below a threshold, and strip or block any response carrying a high-severity finding. Passive-then-active is the standard adoption path because no team lets an unproven proxy block production tool calls on day one.
Hosted vs. self-hosted deployment
Because a gateway sees all of an agent's tool traffic, where it runs is a real decision. A hosted, multi-tenant gateway is the simplest to adopt — point your agent at a managed URL — but the operator sees your tool traffic, which is a privacy consideration for sensitive workloads.
A self-hosted gateway runs as a container inside your own infrastructure (your VPC). Your agent connects to it locally, the backend's OAuth token stays in your environment, and tool traffic never leaves your network; only a control plane (policies, scores, threat intel) phones home. This is the enterprise-friendly model when data residency matters.
One operational caveat: an in-band gateway is now on the critical path. If it goes down, the agent loses its tools. Treat a production gateway as infrastructure — health-checked, highly available, and with clear failure behavior — not as a side service.
How CheckMCP handles it
CheckMCP ships an in-band MCP Gateway as the enforcement counterpart to its out-of-band audit. You point your agent at a CheckMCP gateway URL (with an Authorization: Bearer token) instead of the raw MCP server; the gateway proxies every tools/list and tools/call to the backend and inspects what returns. It reuses the same engine the audit uses: the OWASP MCP Top 10 security checks (tool poisoning, hardcoded secrets, command injection, the lethal trifecta) that produce the vendor-neutral MCP Score (0-100, grade A-F) — where a secret found in a tool schema caps the grade at D and a failed MCP handshake caps it at F — the tool-output analysis from the behavioral evals (multilingual injection, exfiltration vectors, secret/PII in output, plus a callback canary that exercises read-only tools to confirm exfiltration), and the tool-pinning fingerprint from the monitoring layer to catch rug pulls and drift in-session. It runs in two postures: passive mode observes, logs and flags every call without blocking (the trust-building default), while active mode enforces — blocking a backend whose MCP Score is below a configured minimum and withholding any tool response that carries a high-severity finding, replacing it with a safety notice so your agent never sees the poisoned content. CheckMCP offers both a hosted gateway (a managed URL you create in the dashboard) and a self-hosted single-backend container you run in your own VPC, where tool traffic never leaves your network and the backend token stays in your environment. The free MCP Score — runnable via `uvx checkmcp <url>` (the open-source, MIT, stdlib-only CLI), the web app at checkmcp.dev, or the GitHub Action `uses: H129hj/checkmcp@v1` to fail a CI build on a score regression or rug-pull — remains the acquisition layer; the gateway, behavioral evals and continuous drift monitoring are the paid protection layer.