What is an MCP gateway?

By Sagar Batchu, Co-founder & CEO

·Published May 11, 2026·Updated October 6, 2026

An MCP gateway does two jobs on the same traffic. For platform and AI enablement teams, it is how agents reach third-party and internal data without every person wiring up every server in every client. For security and IT teams, it is where that access becomes tied to identity, inspectable, and auditable. A gateway is most useful when one layer does both jobs, so the sanctioned path to tools is the easiest one for employees and the one security can watch. A gateway built only for enablement gives agents a faster route to data that goes uninspected, and a gateway built only for security gets routed around.

Not every organization needs one. A single team using one client against a handful of servers is well served by the client’s own connectors and OAuth support. The case for a gateway starts as the numbers grow. Take 300 engineers, each using two clients (say Claude Code and Cursor) against eight remote MCP servers. That is 4,800 OAuth flows, each repeated when a token expires or a client is reinstalled, and 4,800 connections that central teams typically can’t see. A gateway turns that into 600 sign-ins through the company identity provider (IdP) and one audit log. At enterprise size, with thousands of people and hundreds of servers, the requirements change again, as the enterprise MCP gateway reference explains.

The MCP gateway is the tool-call component of the AI Control Plane, the governing layer between every AI agent in an organization and every system those agents are allowed to reach.

How does an MCP gateway work?

An MCP gateway presents itself to the agent as a standard MCP server. The agent connects to the gateway’s endpoint instead of to each upstream server, and the gateway holds the connection to every server behind it.

The lifecycle of a tool call through an MCP gateway:

1. The agent (Claude Code, Cursor, Copilot, or a custom agent) connects to the gateway’s MCP endpoint and decides to make a tool call.
2. The gateway resolves the session to a person or agent identity in the IdP, such as Okta, Microsoft Entra ID, or Google Workspace.
3. It evaluates the call against policy: is this identity, on this client, allowed to call this tool with these arguments?
4. If the call is allowed, the gateway inspects the arguments and forwards the call upstream with a credential it holds on the person’s behalf. If not, it returns a denial with a reason.
5. The response comes back through the gateway, which inspects it for sensitive data and instruction-shaped content before the model reads it.
6. The gateway writes one audit record: the person, client, server, tool, outcome, and, where policy allows, the arguments and response.

The MCP doesn’t change from the agent’s side, which is why a gateway can sit in front of servers the organization didn’t build. A bare pass-through is sometimes called an MCP proxy, and the gateway is what you get when identity, policy, inspection, and audit are added to it.

A basic MCP proxy is quick to build. The effort goes into everything around it:

• Acting as the OAuth client to each upstream service and refreshing per-user tokens.
• Syncing roles from the directory.
• Building detectors that catch real leaks without blocking legitimate work.
• Running an audit pipeline to the SIEM.
• Keeping pace with the MCP specification, whose 2026-07-28 release deprecates Dynamic Client Registration (DCR) in favor of Client ID Metadata Documents (CIMD) while keeping DCR for compatibility.

What does an MCP gateway do for enablement?

Enablement is usually the first reason a company puts a gateway in the path. The work is a loop with four steps, covered in order below, and each step feeds the next. An inventory nobody acts on goes stale, and a registry people can’t reach from their client gets routed around.

Discover the MCP servers already in use

Most organizations run more MCP than they know about. Employees connect servers to Claude, Cursor, or ChatGPT long before anyone asks for approval, and the configuration lives in a dotfile on a laptop rather than in an installed application that asset inventory would catch. Shadow MCP is that unsanctioned slice, listed as MCP09 in the OWASP MCP Top 10. Discovery produces an MCP inventory: which servers are in use, by whom, from which client, and exposing which tools.

Few gateways do discovery, because a gateway only sees the servers registered with it. Finding the rest takes a presence outside the gateway, such as hooks inside the coding agent, a device agent, or MDM-delivered configuration. Speakeasy, Runlayer, Mintive (formerly MintMCP), Willow, and Bifrost Edge (in alpha) take versions of this approach. Routing-only gateways govern the traffic sent to them and see nothing else. Discovery methods also have a blind spot, since a client that isn’t instrumented produces no signal.

Promote approved servers into a registry

An inventory is a list of risks until someone decides what to keep. Promotion moves a discovered server into the official MCP registry, filtered to the tools the organization approves, with authentication, policy, and logging attached from the first call. Servers the company builds for its own APIs take the same path.

Curation makes the platform team a gatekeeper. If getting a server into the registry takes two weeks of review, people go back to pasting URLs into config files, and the registry describes a smaller world than the one employees work in. Promotion has to be faster than the workaround, or the loop stops at discovery.

Distribute access by role

Distribution decides who gets which servers, and the IdP is where that decision belongs. Assign a server to a group in Okta or Entra, and every member of the group gets it in their client. Move someone out of the group and their access through the gateway ends at the next sync. Sales sees Salesforce and Gong, engineering sees GitHub, Linear, and Sentry, and a new hire has their tools on day one without filing a ticket. Agent access management and enterprise MCP auth cover the identity model in depth.

Distribution is also where a gateway controls context cost. Clients differ in how they load tool definitions, and some load every tool from every connected server on every request. A gateway can present a small set of meta-tools, such as search_tools and execute_tool, and let the model discover real tools as it needs them, so a large server costs the same context in every client. Dynamic tools add at least one round trip before the first real call, which makes them a better fit for a 300-tool CRM than for a five-tool internal service.

Govern every call at one control point

The fourth step of the loop puts every call from every client through the same control point: sign-in through the IdP, access scoped down to the individual tool, inspection in flight, and one audit record per call. Discovery keeps finding new servers, promotion adds them, and distribution hands them out. The control point is where those decisions are enforced. What the control point checks is the governance job, covered in the next section.

MCP gateways for enablement works through authentication, the role-based catalog, and context cost with benchmark numbers.

What does an MCP gateway do for governance?

Governance is where security teams come in, and it comes down to four controls on the tool call. In an agent workflow, the facts a security control needs are in the tool call: the person behind it, the tool it invokes, the arguments it carries, and what comes back. Email DLP, web proxies, and EDR were built for a person clicking through an application, and they typically don’t read a JSON-RPC message between an agent and an MCP server. The gateway reads all four facts on every call it routes.

Simon Willison’s lethal trifecta names the risk: an agent with access to private data, exposure to untrusted content, and a way to communicate externally. MCP makes that combination easy to assemble, because each new server can add a data source, a source of untrusted text, or an outbound channel.

Role-based access on every call

A server allowlist is the floor. It doesn’t separate the support agent that reads tickets from the one that can also issue refunds. A gateway enforces RBAC at a finer grain: directory groups map to roles, roles are granted per server, and grants narrow to individual tools or to a read-only annotation. The check runs on each call rather than at login, so removing someone from the directory denies their next tool call once the directory change syncs, without anyone touching the gateway.

Ask any vendor what the principal is on each call. A gateway that authenticates callers with its own API keys still enforces permissions, but the principal is a record inside the gateway, and the directory’s access review may never see it.

Data loss prevention on tool traffic

Agent DLP on a gateway reads tool traffic in both directions. Outbound arguments are where exfiltration shows up, such as a secret pasted into a ticket comment or a customer list sent to a third-party enrichment API. Inbound responses are where regulated data enters a context window that may then go to a model provider outside the company’s tenancy. Pattern detectors for secrets, personal data, and financial identifiers are cheap to run on both. Contextual checks need a model-based judge, which costs a model call per evaluated message.

False positives are how DLP fails. A detector that blocks legitimate work in the first hour pushes people back to unsanctioned servers, so rollouts start in log-only mode and tighten once the findings look real.

Inspection at the tool boundary

Tool output is untrusted content. A support ticket, a fetched web page, or a README in a cloned repo can carry instructions, and the model can’t reliably tell data from instructions. Prompt injection through tool results and tool poisoning, where the instructions sit in a tool’s own description, both reach the model through the MCP layer.

A gateway reads every tool description at registration and every result before the model does. It can pin descriptions by hash so a changed description goes back through review, scan results with a deterministic detector for obvious patterns and an LLM judge for the rest, and log the call, deny it, or quarantine the session on a finding. Detection is probabilistic, and a judge misses some injections. Per-tool roles bound what a missed injection can do, which is why inspection and RBAC are designed together.

An audit log tied to a person

Every gateway logs something. A useful audit record names the directory user, the client, the server and tool, the outcome and the policy behind any denial, and, where policy allows, the arguments and response. It streams to the SIEM over OpenTelemetry. That record answers “which agents read customer records last Tuesday, and on whose behalf?” with one query instead of a search across every client and server log.

Capturing arguments and responses has a cost. The log now holds copies of the customer records, source code, and tickets agents touched, so it needs its own retention period and access controls.

MCP gateways for security covers these controls in depth, and MCP gateways for governance covers the audit evidence compliance teams ask for. MCP security maps the full control set against the OWASP MCP Top 10, and MCP governance covers the lifecycle of the servers themselves, from approval to retirement.

What can’t an MCP gateway do?

A gateway controls the traffic that passes through it, and it is the wrong place to look for several things:

• Traffic that never reaches it. A developer who points a client at an unregistered server, an agent calling an API directly with a key from an environment variable, and local MCP servers over stdio all bypass the gateway.
• The agent’s loop. A gateway can refuse further calls from a session and revoke the credentials it brokered. The agent reads the error and tries another route. Ending a session takes a component inside the agent, covered in agent session management.
• Model calls. Prompts and completions that don’t involve a tool belong to an LLM gateway or to agent hooks.
• Compliance. Frameworks such as ISO 42001 and the EU AI Act assess a management process. A gateway supplies runtime evidence for that process and doesn’t make an organization compliant.

A gateway also concentrates risk. It holds upstream credentials for every system behind it, so it has to be run as tier-zero infrastructure. That means:

• Encrypted token storage.
• Short-lived access tokens.
• Tight admin access.
• Its own audit trail in the SIEM.

How is an MCP gateway different from an LLM gateway?

An LLM gateway sits between the application and the language model. It handles routing across providers, API key management, rate limits, cost tracking, and inspection of prompts and completions. Portkey (now part of Palo Alto Networks’ Prisma AIRS) and LiteLLM are examples, and the AI gateway resource covers the category.

An MCP gateway sits between the agent and the tools it calls, after the model has decided to make a tool call. It sees which MCP server, which tool, which arguments, and what came back, rather than which model was chosen.

Most enterprises end up running both, because few LLM gateways were built for MCP semantics. They often lack tool-level RBAC, per-user upstream credentials, and stateful tool sessions, and they don’t treat tool descriptions as an attack surface. AI gateway vs MCP gateway vs AI Control Plane explains where each layer stops and when a team needs all three.

Which MCP gateway architecture fits?

Vendors use “MCP gateway” for three architectures. Routing infrastructure is a proxy the platform team runs, often open source on Kubernetes, with identity mapping and tool-level policy left to the layers around it. A governance plane is a managed service that owns identity, policy, inspection, and audit for the traffic it fronts. A hybrid adds hosting or generation of MCP servers on top of either.

A fourth question cuts across all three: whether the gateway is reachable from the public internet or served only on a private network.

Which MCP gateway architecture do I need is the buyer map for the first three. The private MCP gateway resource covers serving a gateway on a private network, including servers that never touch the public internet.

What are examples of MCP gateways, including open-source options?

This section is an orientation to the market, covering open-source MCP gateways and commercial products. The best MCP gateways for enterprise in 2026 scores 11 products on both enablement and governance.

The table compares the gateways most often evaluated on the two questions that separate them most: how each one finds MCP servers it doesn’t route, and who the gateway treats as the caller on each tool call. It draws on each vendor’s public documentation as of September 2026.

Speakeasy. We build the Speakeasy MCP gateway, so this entry is not neutral. It ships as one component of the Speakeasy AI Control Plane and covers the enablement loop described above. Shadow MCP detection uses agent hooks in Claude Code, Cursor, Codex, and OpenCode plus a device agent. Approved servers are promoted into a registry with tool-level allowlists, roles sync from Okta or Entra over SCIM, and guardrails scan tool requests and responses for secrets, personal data, and prompt injection. It has three limits. Discovery only covers clients that are instrumented, and judge-based detectors need tuning in log-only mode before they block. It also doesn’t route model traffic, so a team that needs model failover runs an LLM gateway alongside it.

Microsoft MCP Gateway. Microsoft MCP Gateway is an open-source reverse proxy and management layer for MCP servers on Kubernetes, with stateless per-request routing, a control plane for deploying and updating servers, and bearer-token RBAC. It is routing infrastructure and leaves DLP and tool-boundary inspection to other layers. Azure API Center is a separate product that can act as an MCP registry. A team on Azure that wants both a curated list and a single path pairs the two.

IBM ContextForge. ContextForge is an open-source registry and proxy that federates MCP servers, A2A agents, and REST or gRPC services behind one endpoint, with a plugin framework for guardrails and OpenTelemetry tracing. It suits a platform team that wants to self-host and bring existing non-MCP services into the same catalog. Beyond federated SSO, directory integration and retention policy are the team’s to build.

Other commercial options include Mintive, Runlayer, Kong (AI MCP Proxy), Bifrost, TrueFoundry, Willow (formerly Webrix), Docker MCP Gateway, and AWS AgentCore Gateway.

Where can you learn more about MCP gateways?

Each of these pages goes deeper on one part of this reference:

• Enablement: MCP gateways for enablement covers authentication, the role-based catalog, and context cost.
• Security: MCP gateways for security covers RBAC, DLP on tool calls, and tool-boundary inspection, and MCP security maps the wider threat model.
• Governance and compliance: MCP gateways for governance covers audit evidence, and MCP governance covers the server lifecycle.
• Discovery: Shadow MCP defines the problem, and MCP inventory covers the record discovery produces.
• Architecture: Which MCP gateway architecture do I need and private MCP gateway.
• Enterprise: What is an enterprise MCP gateway? covers the challenges and features that come with running MCP across an enterprise.
• Vendors: The best MCP gateways for enterprise in 2026 has the scored shortlist.
• Adjacent layers: AI gateway vs MCP gateway vs AI Control Plane.

How to start with an MCP gateway

1. Put the five most-requested servers behind a gateway with sign-in through your IdP, read-only by default, and confirm that removing someone from the directory denies their next call once the sync runs.
2. Run discovery for two weeks and compare the servers people use with the servers in the registry, since the gap is your promotion backlog.
3. Turn on DLP and prompt injection detection in log-only mode across tool requests and responses, and tune until the findings look real before anything blocks.

If you’re working through the first of these and want to see the loop running, the Speakeasy MCP gateway is free to start, and we’d like to talk if you want to compare notes on a rollout.