What is an MCP gateway?

An MCP gateway is an enforcement point that sits on the HTTP path between an agent (or the model driving it) and the remote MCP servers it calls. It resolves the caller's identity, checks whether that identity may invoke the requested tool, inspects the tool arguments, and returns a permit or deny decision before the call reaches the server. It also records each call. The gateway is distinct from the MCP server itself: the server exposes tools and executes them, while the gateway decides whether a given caller may reach a given tool with given arguments. This separation is what lets you apply a consistent authorization policy across many MCP servers instead of trusting each server to enforce its own.

Does an MCP gateway secure local STDIO servers?

No. Local MCP servers communicate over STDIO as processes on the same host as the client, and they never emit a network request. An HTTP gateway inspects HTTP traffic, so it has nothing to evaluate for a STDIO server. Securing local servers is a host-level concern: process sandboxing, file-system scoping, and controlling which servers a client is allowed to spawn. The gateway's boundary is remote MCP traffic over Streamable HTTP. Being precise about this line matters, because a security control that claims to cover a transport it cannot see gives a false sense of coverage. For local execution, treat the host controls as the enforcement layer and the gateway as the layer for remote calls.

How does an MCP gateway stop a confused-deputy attack?

By moving the authorization decision off the agent's ambient credential and onto an enforcement point that checks the acting user's permission on every tool call. In a confused-deputy attack, an agent with broad credentials is manipulated into calling a tool on behalf of a user who lacks that permission, and the server executes because the token is valid. The gateway holds a policy keyed to the acting identity, not just the agent, and evaluates each call against it before the server acts. A call that the acting user is not authorized to make is denied at the gateway, so the agent's over-broad credential is no longer the only thing standing between the request and execution.

What does an MCP gateway record for each tool call?

The verified identity behind the call, the agent that issued it, the target server and tool, the classification of the arguments, the policy version applied, the outcome, and a timestamp. The record commits before the call reaches the server and is signed and tamper-evident. This gives security operations a reconstruction of which agent called which tool on whose behalf, and it gives compliance teams the per-action evidence that frameworks like the EU AI Act expect for high-risk systems. Because the record is written on the gateway's own path rather than by the agent or the server, it is independent of the components under audit, which is the property that makes it usable as evidence rather than a self-reported log.

MCP Gateway Security: Enforcing Policy on Remote Tool Traffic

The Model Context Protocol gives an agent a standard way to call external tools. When the MCP server runs remotely, every tool call becomes an HTTP request from the agent to the server endpoint, carrying the tool name, the arguments, and whatever identity the client attached. That HTTP request is the surface an MCP gateway governs. MCP gateway security is the practice of placing an enforcement point on that traffic so a tool call is evaluated against identity and policy before it reaches the server, and recorded when it does.

I want to walk through what the gateway inspects, why remote transport is the line that matters, and where this boundary stops.

Remote MCP traffic is HTTP, and that is the enforcement surface

The MCP specification defines two transports. Local servers communicate over STDIO, as processes on the same host as the client. Remote servers communicate over Streamable HTTP, where each tool call is an HTTP POST to a server URL. The two transports have different security surfaces, and conflating them is the most common mistake in MCP threat models.

A gateway inspects HTTP. It reads the request line, the headers, and the JSON-RPC body of a Streamable HTTP tool call. It can resolve the caller identity, check whether that identity may invoke the requested tool, inspect the arguments for regulated data, and return a decision. None of that applies to a STDIO server, which never emits a network request. An HTTP MCP gateway secures remote MCP traffic. Local STDIO execution belongs to host-level controls, and an article claiming otherwise is describing the wrong layer.

What an MCP gateway evaluates on a tool call

The evaluation mirrors an LLM gateway but operates on tool semantics rather than prompts. Identity resolves first. A remote MCP server should require authorization, and the gateway confirms the caller presents a verified identity rather than an anonymous or shared token, consistent with MCP server authentication practice.

Authorization runs next, at the granularity of the individual tool. A role permitted to call a read-only search tool is not automatically permitted to call a delete_record or send_email tool exposed by the same server. The gateway checks the requested tool against a per-role policy and denies calls outside the role's scope. Argument inspection runs third, reading the tool arguments for PII, secrets, or out-of-policy targets. The decision fails closed, so a tool call that cannot be evaluated is denied rather than forwarded.

The confused-deputy problem is a gateway decision

MCP's most cited authorization failure is the confused deputy. An agent holds broad credentials. A tool description or an upstream instruction persuades the agent to call a tool it should not call on behalf of a user who lacks that permission. The server sees a valid token and executes. I covered the pattern in the MCP confused-deputy breakdown.

The structural fix is to move the permission check off the agent and onto an enforcement point that evaluates every tool call against the acting user's authorization, not the agent's ambient credential. That is a gateway function. The gateway holds the policy that says this user, through this agent, may not reach this tool with these arguments, and it applies that policy on the request before the server acts. The agent's credential stops being the sole authority.

Tool poisoning changes what the model sees, and the gateway logs it

A related risk is tool poisoning, where a malicious or compromised server publishes a tool description crafted to manipulate the calling model. I covered detection patterns in tool poisoning prevention. The description travels over the same HTTP channel as the calls, so a gateway sees the tool metadata a server advertises and the calls that result.

A gateway cannot rewrite a third-party server's intent. What it does is record which server advertised which tools to which agent, and enforce policy on the calls those tools produce. When a server's tool set changes or a new tool appears mid-session, that event lands in the audit record with identity and timestamp. The OWASP GenAI project catalogs these agentic risks, and the gateway is where the enforceable subset of them is actually caught.

The record every tool call leaves behind

Each evaluated tool call should produce a per-decision audit record: the verified identity, the acting agent, the target server and tool, the argument classification, the policy version, the outcome, and a timestamp. The record commits before the call reaches the server, so a tool invocation cannot execute without leaving evidence.

This matters beyond security operations. Regulated deployments running agents against remote MCP servers inherit the same recording obligations as any other high-risk AI system. Under EU AI Act Article 12, the events that need automatic recording include the actions an AI system takes, and a tool call is an action. A gateway that logs every call on the write path it owns produces that evidence structurally.

DeepInspect

This is what DeepInspect does for MCP traffic. DeepInspect is a stateless proxy on the HTTP path between your agents and the remote MCP servers and LLM endpoints they call. It resolves the acting identity, evaluates per-tool and per-role policy, inspects arguments for regulated data, and returns a permit or deny decision before the call reaches the server. Because it is model-agnostic and transport-aware, one policy set covers the remote MCP servers and the LLM APIs in the same deployment.

Every decision produces a signed, per-decision audit record committed ahead of the call. Local STDIO servers sit outside this HTTP boundary by design, and DeepInspect is honest about that line rather than claiming to secure execution it never sees.

If your agents are calling remote MCP servers without an enforcement point on that traffic, book a demo today.

They share mechanics and differ in semantics. A traditional API gateway authenticates callers and rate-limits endpoints. An MCP gateway does that and also understands MCP's tool model: it evaluates individual tool invocations, inspects JSON-RPC arguments, tracks the tool descriptions a server advertises to an agent, and reasons about the acting user behind an agent rather than only the calling service. The risks are also different. API gateways rarely worry about a description field manipulating the caller, but tool poisoning and confused-deputy patterns are specific to the agent-and-tool model. So MCP gateway security is API gateway security plus an authorization model that treats each tool call as the unit of policy.