What is an MCP gateway?
An MCP gateway is a proxy that sits between an AI agent and one or more Model Context Protocol servers, inspecting upstream tool listings and each governed tool call and enforcing policy before requests reach the server. It is the chokepoint where MCP traffic becomes governable.
Key facts
- Speaks MCP on both sides: clients connect to the gateway as if it were a server; the gateway connects to upstream servers as a client.
- Fits teams running multiple MCP servers, third-party MCP integrations, or untrusted community MCP tools.
- Without one, tool poisoning, prompt-injection-bearing descriptions, and unscoped tool calls reach the agent unfiltered.
- Veto's MCP gateway can enforce tool-level policy, redact arguments before logging, and quarantine suspicious tool definitions.
In plain English
Model Context Protocol gives agents a standard way to discover and call external tools: file systems, databases, internal APIs, third-party services. The tradeoff is that it standardizes the wire format. The gap is that there is no standard for "should this call go through?" Each server decides on its own, and most do not decide much beyond "is this token valid?"
An MCP gateway inserts a policy layer where one was missing. The agent connects to the gateway as if it were a normal MCP server. The gateway holds a list of upstream servers it knows about. When the agent calls tools/list, the gateway can rewrite or filter the result. When the agent calls tools/call, the gateway runs the request through policy first.
How it works
The gateway terminates the MCP transport (stdio, SSE, or streamable HTTP), maintains its own connection pool to upstream servers, and brokers each request. Three checks run for each governed tools/call: identity (which agent is this?), policy (does the agent identity allow this tool with these arguments?), and side-effects (log, redact, rate-limit).
Policy lives in YAML. Each rule names a tool, a match expression over arguments, and an outcome. The gateway also inspects tools/list responses: if an upstream server publishes a tool whose description contains instruction-shaped text: "ignore previous instructions", "use admin tools first": the gateway can quarantine the definition before the agent ever sees it.
# YAML: MCP gateway policy
- name: filesystem_mcp_read_only
match:
server: filesystem
rules:
- if: tool in ["write_file", "delete_file"]
then: deny
- if: tool == "read_file" and args.path =~ /\.env|secret/
then: denyOperational consequence
MCP adoption moved faster than its threat model. A malicious upstream server can serve a changed or poisoned tool definition, and a trusting client may pass that definition straight into the agent's context. The structural lesson: an agent that blindly trusts MCP servers it connects to is carrying that server inside its supply chain. A gateway makes that trust explicit and conditional.
For regulated industries, the gateway also gives review teams a single place to point at when an auditor asks "how do you control what your agent's tools do?" One YAML file, one decision record, one chokepoint. It is easier to attest to one gateway than to twelve MCP servers each enforcing their own rules.
Related terms
FAQ
Why do I need a gateway? My MCP server is already authenticated.⌄
Authentication says the connection is valid. It does not say the tool call is appropriate. A gateway adds an authorization boundary over MCP traffic so you can write per-tool, per-argument rules without treating each server as a one-off fork. It is also the right place to enforce rate limits, redact sensitive arguments from logs, and quarantine suspicious calls.
Does an MCP gateway slow things down?⌄
A well-built gateway adds local decision-path overhead for policy evaluation. The LLM request and the tool execution usually dominate the runtime budget; the policy check sits before dispatch and is measurable in your own environment.
Can the gateway block MCP tool poisoning?⌄
Yes, in two ways. First, it inspects each tool definition the server publishes and can quarantine ones whose descriptions contain instruction-like patterns. Second, even if a poisoned tool slips through, the gateway can hold its actual invocations against policy and refuse out-of-policy arguments.
Where does the gateway log to?⌄
Each governed decision is recorded with the decision context you send: agent identity, tool name, arguments, the rule that fired, the verdict, and the latency. Veto streams these to the workspace, to your SIEM via webhooks, and to whatever sink you wire up. The decision record is the evidence review teams ask for.
Put a gateway in front of your MCP servers.