MCP gateways put agent data access on a path you can secure

Model Context Protocol (MCP) gateways are becoming a useful piece of infrastructure for several different use cases. This post is about using a gateway as a mechanism for applying security policy to Agent workflows. Access to data is a pre-requisite of building an impactful agent but also creates a new surface for security teams to manage. A gateway is an important piece of architecture because it creates a single chokepoint between agents and the data they use. Its a useful mechanism for three security controls: enforcing role-based access, running data loss prevention (DLP) on what the agent sends and receives, and inspecting tool descriptions and results for injected instructions before the model reads them. It is also a layer with clear limits, and the second half of the post is about those. For the definition and the full architecture, see what is an MCP gateway.

Why data access is the riskiest thing an agent does

An agent that can only write text can embarrass you. An agent that can read the customer database and send an HTTP request can leak it. Simon Willison named this combination the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. An agent with all three can be steered by a poisoned web page or a crafted support ticket into reading something sensitive and sending it somewhere it shouldn't go. MCP makes the trifecta easy to assemble, because the whole point of the protocol is to hand an agent more tools, and each new server can add a data source, a source of untrusted text, or an outbound channel.

The security tools most companies already run were built for a person clicking through an application, and an agent workflow breaks their assumptions in three places. Authorization is the first. IdP's could control access to applications, but many MCP servers, especially those wrapping internal data, don't have robust support for OAuth or so they lean on a bearer token pasted into a config file. The OWASP MCP Top 10 names the resulting failures as MCP02 (privilege escalation through scope creep) and MCP07 (insufficient authentication and authorization).

Data loss prevention is the second. It watches email, web uploads, and endpoint actions, but an agent moving a customer record from one tool to another doesn't use any of the traditional channels. Network controls also don't work, because from the proxy's point of view, an agent session is an approved application talking HTTPS to an approved domain, whatever the model was steered into doing.

Each of those tools is looking at the wrong layer. In an agent workflow, the facts a security control needs live in the tool call: which person is behind it, which tool it invokes, which arguments it carries, and what comes back. A gateway is the component that sees all four, on every call, which is why it is where the controls in this post run.

Role-based access has to hold on every call

Most MCP rollouts begin with a server allowlist: these servers are approved, those aren't. That is the floor. It doesn't distinguish the support agent who should read tickets from the one who should also issue refunds, and it treats a production database server the same way as the internal wiki.

A gateway can enforce role-based access at a finer grain because it knows who the caller is and what the call does. Directory groups from Okta or Entra ID map to roles. Roles are granted per server, then narrowed to individual tools or to a tool annotation such as read-only. With that in place, "everyone in the company can query the CRM, nobody can write to it without an explicit grant" is a rule the gateway applies on every call, rather than a policy in a wiki that the MCP server has no way to check. The same mechanism handles offboarding. When the directory removes a person, the gateway denies their next call without an administrator touching the gateway, which is the test most worth running in a proof of concept.

Enforcement at the call is also where curation and authorization separate. Which tools a team is offered is a catalog decision, often made by a platform or AI enablement team. Which calls are permitted at runtime is a security decision, usually owned by someone else. Buyers we talk to draw that line explicitly, and a gateway that only hides tools from a list, rather than refusing the call when it arrives, has collapsed the two. For the identity side of this, including how SSO and client admission work for MCP, see enterprise MCP auth and agent access management.

DLP has to read the tool call

Classic DLP inspects the channels it proxies: email, web uploads, file transfers, and endpoint actions such as copying to a USB drive. A tool call crosses none of them. It is a JSON-RPC message between an agent and an MCP server, and the model call that follows is an HTTPS request from an approved application to an approved domain. An agent that reads a customer record through one tool and posts it through another never triggers an email, web, or endpoint rule. Agent DLP covers the category in detail; the point here is where the inspection runs.

A gateway reads tool traffic in both directions. On the way out, it sees the arguments an agent is about to send, which is where exfiltration shows up: a secret pasted into a ticket comment, a customer list sent to a third-party enrichment API, a card number in a search query. On the way back, it sees tool responses before they reach the model, which is where regulated data enters a context window that may be sent to a model provider outside your tenancy. Pattern detectors for secrets, personal data, financial data, and government identifiers are cheap to run on both surfaces. Contextual risks, such as "this curl call is sending data to a domain we don't recognize", need a model-based judge, which costs a model call per evaluated message and should be scoped narrowly.

DLP on tool calls has the same problem DLP has everywhere, which is false positives. A detector that flags every string shaped like an email address will block legitimate work within the first hour, and blocked work is what pushes people toward unsanctioned servers. The rollout that works is observation first: log findings for a broad audience, tune scope and exclusions until the findings look real, then move to warn-and-confirm or deny for a small group before widening it.

Tool output is untrusted content, and the gateway reads it first

The third leg of the trifecta is untrusted content, and in an agent workflow most of it arrives through tool results. A support ticket, a web page a tool fetched, a row in a shared spreadsheet, a README in a cloned repo: the model reads each as text, and it cannot reliably tell data from instructions. OWASP LLM01:2026 names tool output as an injection channel, MCP06 covers prompt injection through contextual payloads, and MCP03 covers tool poisoning, where the instructions sit in the tool's own description or schema and reach the model before any call is made.

Legacy tools never see this content either. The web proxy sees a JSON-RPC response to an approved application, and the model provider sees a prompt it was asked to complete. The gateway is the one component that reads every tool description when a server is registered and every tool result before the model does, so it is where inspection at the tool boundary runs. In practice that means three things. Tool descriptions are pinned by hash, so a changed description is a new object that goes back through review. Tool results are scanned for instruction-shaped content, with a deterministic detector for the obvious patterns and an LLM judge for the rest. A finding gets the same actions DLP gets: log it, deny the call, or quarantine the session.

Inspection narrows the risk without removing it. A judge misses some injections and flags some legitimate text, so teams start in log-only mode and tune the threshold before anything blocks. The stronger control is scope. An injected instruction can only do what the role behind the call already allows, which is why tool-boundary inspection and per-tool roles are designed together: the first catches what it can, and the second bounds what the rest can do.

Where a gateway's security stops

A gateway is the strongest point of control on the network path, and for traffic routed through it the control is real. It is also the wrong place to look for several things.

A gateway can refuse every subsequent tool call from a session and revoke the credentials it brokered. It can't stop the agent's loop. A refused agent reads the error, reasons about it, and tries another route: a local script, a direct API call with a key from an environment variable, or a tool the gateway doesn't front. Ending a session needs a component inside the agent itself, which is covered in agent session management. A gateway on the tool path also doesn't see model calls that don't pass through it, shell commands and file edits the agent makes locally, or local MCP servers over stdio.

The concentration objection from the start of this post also doesn't go away. A gateway that holds upstream credentials for every system needs to be treated as tier-zero infrastructure: encrypted token storage, short-lived access tokens, tight admin access, and its own audit trail exported to the SIEM. The MCP security resource maps the full set of controls against the OWASP MCP Top 10 and the NSA guidance, and a gateway covers some of them, not all.

Which MCP gateways cover the security jobs?

The vendor landscape is broad, so this is a short orientation rather than a comparison. The full shortlist with scoring is in the best MCP gateways for enterprise in 2026, and which MCP gateway architecture do I need covers the architectural choice.

Speakeasy. Speakeasy ships its MCP gateway as one part of an AI Control Plane. Roles sync from Okta or Entra over SCIM and are scoped per server and per tool, by name or by tag, so a read-only default holds for new tools as they're added. Guardrails scan prompts, tool requests, and tool responses for secrets, personal data, financial data, government identifiers, and healthcare data, with actions that range from logging to denying the call to quarantining the session. A prompt injection guardrail, evaluated by an LLM judge, reads tool responses for indirect injection and hidden instructions and returns a verdict with a confidence score and rationale, with the same actions available. The limit is the one every judge-based detector has: the threshold for blocking is a tuning decision, and the tuning happens in log-only mode first.

Microsoft. Microsoft MCP Gateway is an open-source reverse proxy and management layer for MCP servers on Kubernetes, with session-aware routing, lifecycle management, and bearer-token authentication with RBAC. It leaves DLP and tool-boundary inspection to other layers. Azure API Center is a separate product that can act as an MCP registry, an inventory of the servers an organization has approved, which is useful as the reference point for shadow detection but is not itself on the request path.

IBM ContextForge. ContextForge is IBM's open-source gateway, registry, and proxy that federates MCP, A2A, and REST or gRPC services behind one endpoint, with a plugin framework for guardrails. It suits a team that wants to self-host and assemble its own security policy from plugins.

Other commercial options. MintMCP, Runlayer, Kong (through its AI MCP Proxy plugin on the AI Gateway), Bifrost, TrueFoundry, Willow (formerly Webrix), Docker MCP Gateway, and AWS AgentCore Gateway all sit somewhere on this map. They differ most on whether the principal on each call is a directory identity or a gateway-local key, and on whether they have any presence outside the gateway at all.

Where to start

If you're adding a gateway for security reasons, three steps cover most of the value in the order that causes the least friction:

1. Put the sanctioned servers behind the gateway with directory-backed roles, read-only by default, and confirm that removing someone from the directory denies their next call.
2. Turn on DLP detectors in log-only mode across tool requests and responses, and tune scope and exclusions until the findings look real before anything blocks.
3. Turn on tool-boundary inspection in the same log-only mode, review what the injection detector flags in tool results, and move to deny or quarantine once the false positive rate is one the team will live with.

This is the security angle on MCP gateways. Enablement and governance are separate jobs for the same layer, and we'll cover each on its own. If you're working through the security case for a gateway and want to compare notes, we'd like to talk.