An MCP gateway is an inline proxy sitting between AI agents, acting as MCP clients, and the MCP servers they reach. It brokers every tool call and tool list response so an enterprise can apply policy and runtime protection at the protocol level. A gateway can run locally on developer endpoints, centrally in the network, or both.
- An inline proxy brokering every tool call and tool list response
- Creates the chokepoint MCP traffic otherwise has nowhere to be inspected at
- Deployable locally on endpoints, centrally in the network, or both together
- Turns ungoverned agent tool use into inventory, policy, and an audit trail
Why is an MCP gateway important?
A gateway matters because without one an enterprise has no chokepoint at which to inspect MCP traffic at all. Agents talk to MCP servers directly, tool lists are consumed at runtime, and the security team sees neither the request nor the response. The traffic is not hidden through any evasion – nothing was ever positioned to observe it.
With a gateway the same traffic becomes governable in four ways. Inventory accrues by server, since everything passing through is recorded. Sanctioning becomes enforceable by policy rather than advisory. Runtime inspection applies per tool call. And an audit trail exists per session, which is what turns agent tool use into something an auditor can examine.
The reason this is more urgent than it sounds is the direction of the traffic. Tool list responses flow inbound into the agent's reasoning, so a gateway is not only watching what agents do – it is the only place to catch what servers tell them before they act.
What is an MCP gateway?
An MCP gateway is a proxy implementing the Model Context Protocol on both sides. Agents connect to it as though it were a server; it connects onward to the real servers as a client. Because it sits in the path, it observes and can alter every exchange.
Four functions follow from that position. It discovers, because every server an agent reaches becomes known. It sanctions, because a request to a disallowed server can simply not be forwarded. It inspects, evaluating tool calls before execution and tool list responses before the model reads them. And it records, producing a per-session trail of what was requested and what policy decided.
Deployment placement determines coverage. A local gateway on developer endpoints catches stdio-based servers running on the same machine, which a network gateway never sees. A central gateway catches remote servers and gives one policy point for the organization. Environments with both developer tooling and platform agents generally need both.
An MCP gateway is not an LLM gateway. One brokers tool calls, the other brokers model calls.
Types of MCP gateways
Gateways differ by deployment placement and by what they enforce.
Local gateways run on the endpoint alongside the agent, which is the only way to reach servers communicating over stdio on the same machine. They cover developer tooling and coding agents, and they require endpoint distribution.
Central gateways run in the enterprise network and broker remote MCP traffic. They are simpler to operate and give a single policy and audit point, and they cannot see local stdio traffic.
Hybrid deployments run both, with local gateways forwarding to central policy so coverage is complete and the policy set stays singular.
By enforcement depth, pass-through gateways record traffic without evaluating it, which produces visibility and no control. Policy-enforcing gateways evaluate each call against rules and can refuse it. Inspecting gateways additionally analyze content, including tool descriptions and returned data, which is what catches poisoning and data exfiltration rather than only unauthorized targets.
MCP gateway & Onyx
Onyx ships an MCP gateway with sanctioning, runtime guards, and authentication controls, integrated with the rest of the platform so policy and reporting are unified rather than gateway-specific.
That integration is the point. A standalone gateway produces its own inventory and its own logs, leaving someone to reconcile them against the AI asset inventory the security team maintains elsewhere. Because the Onyx gateway shares a data model with discovery and posture scoring, an MCP server found by the MCP Scanner is the same object the gateway enforces against and the same object that appears in a compliance view. Policy written once applies at the protocol boundary, and every decision is attributable to the agent identity that triggered it.
