An MCP gateway sits between your AI agent and the MCP servers it talks to. It centralizes routing, access control, and (depending on the gateway) content inspection. Some gateways only handle routing and auth. Others also scan tool calls and responses for security threats. The term covers a range of products with different depth.
Without one, your agent talks directly to MCP servers with no inspection. Tool descriptions could contain hidden instructions. Tool arguments could carry your API keys. Responses could inject new prompts into your agent’s context. No log, no scan, no enforcement point.
What an MCP gateway actually does
MCP servers expose tools, resources, and prompts to AI agents. The agent calls tools/list to discover what’s available, then invokes tools by name with JSON arguments. The server responds with results.
A gateway intercepts this entire conversation:
Outbound (agent to server):
- Scans tool call arguments for leaked secrets (API keys, tokens, credentials)
- Blocks calls to unauthorized tools
- Enforces rate limits and budget controls
- Logs every tool invocation for audit
Inbound (server to agent):
- Scans tool descriptions for poisoning attacks (hidden instructions embedded in descriptions, parameter names, or enum values)
- Detects rug-pulls (descriptions that change mid-session)
- Scans tool responses for prompt injection
- Blocks responses containing credential patterns
Discovery (tools/list):
- Inspects every field in the tool definition (name, description, parameters, defaults, examples)
- Flags descriptions that contain instruction-like content
- Tracks tool definition changes across the session lifetime
MCP gateway vs MCP proxy
These terms overlap. The industry hasn’t settled on standard definitions yet. Here’s how they tend to differ in practice:
| MCP Gateway | MCP Proxy | |
|---|---|---|
| Primary job | Routing, access control, policy | Content inspection, DLP, injection scanning |
| Multi-server | Routes to multiple backends | Usually wraps a single server |
| Examples | Docker MCP Gateway, agentgateway, Runlayer | Pipelock MCP proxy, Promptfoo MCP proxy |
Pipelock does both. It routes MCP traffic through a scanning proxy that handles tool description inspection, argument DLP, response injection scanning, and access control in one binary. The distinction between “gateway” and “proxy” matters less than what the tool actually scans.
What to look for
Not all MCP gateways inspect the same things. Some only do access control (allow/deny tool calls). Some only do routing. Here’s what actually matters for security:
Tool description scanning: Does it check tools/list responses for embedded instructions? This is the tool poisoning attack surface. Hidden instructions in tool descriptions, parameter names, default values, and enum options can hijack agent behavior before any tool is called.
Bidirectional content inspection: Does it scan both directions? Outbound (arguments) for secrets, inbound (responses) for injection. Many gateways only inspect one direction.
Encoding evasion: Does it handle base64, hex, URL encoding, Unicode tricks? Attackers encode payloads to bypass pattern matching. A gateway that only scans plaintext misses encoded secrets.
Session awareness: Does it track changes across a session? A rug-pull attack sends clean descriptions initially, then swaps in poisoned versions after the agent trusts the tool. Session-aware gateways detect this.
Protocol coverage: Does it only handle MCP, or does it also cover HTTP and WebSocket? Agents don’t just use MCP. They make HTTP requests, fetch web pages, call REST APIs. An MCP-only gateway leaves HTTP traffic unscanned.
How Pipelock handles MCP
Pipelock wraps MCP servers with a scanning proxy. One command:
pipelock mcp proxy --config pipelock.yaml -- npx @modelcontextprotocol/server-filesystem /tmp
This starts the MCP server and routes all stdio traffic through Pipelock’s scanner. The scanner checks:
- Tool descriptions for 25 injection patterns plus 9 tool-specific poisoning checks, with 6-pass normalization
- Tool arguments for 48 credential patterns (API keys, tokens, private keys)
- Tool responses for prompt injection and credential leaks
- Session-level tool definition changes (rug-pull detection)
For HTTP-based MCP servers (SSE/Streamable HTTP):
pipelock mcp proxy --config pipelock.yaml --upstream http://localhost:3000/mcp
Same scanning, different transport. The config file controls domain allowlists, DLP sensitivity, and block/warn behavior.
MCP gateways in the market
The space is moving fast. As of April 2026:
- Pipelock scans HTTP + MCP + WebSocket in one binary. Open source, self-hosted, Go.
- Docker MCP Gateway runs MCP servers in isolated containers with network restrictions, call tracing, and a
--block-secretscontrol. Container isolation with some content-level controls. - agentgateway (Linux Foundation, contributed by Solo.io) is a Rust-based gateway with MCP/A2A support, JWT auth, tool-level RBAC, and OpenTelemetry. Infrastructure-focused.
- Runlayer is a cloud MCP gateway with threat detection and fine-grained permissions. SaaS, not self-hosted.
For a detailed comparison of scanning depth vs container isolation, see Pipelock vs Docker MCP Gateway.
Further reading
- MCP Proxy: how Pipelock’s MCP proxy scans bidirectionally
- MCP Tool Poisoning: the attack that hides in tool descriptions
- MCP Security: the full MCP threat model
- MCP Vulnerabilities: every MCP attack vector mapped
- How to Secure MCP: the practitioner tutorial
- Pipelock vs Docker MCP Gateway
- Pipelock on GitHub