What is an MCP gateway?

A gateway is a proxy layer that sits in front of a resource, routing traffic through a central point where logic can be applied. An MCP gateway applies that pattern to the tool-calling layer of AI agents: it sits between the agent and the MCP servers that expose tools, data, and APIs, so that every tool call flows through a single controlled path.

Two purposes define the category. The first is enablement: connecting agents to tools through a single integration point rather than managing authentication and routing separately for every server. The second is governance: making that access visible, enforceable, and auditable. Some organizations adopt MCP gateways because they want to move faster. Others adopt them because they can’t afford a blind spot in the part of the stack where AI agents are calling tools against production systems. Both are valid starting points, and a well-designed gateway handles both.

This matters particularly because MCP tool calls are the point at which AI agents reach external data. An agent calling get_customer_records or delete_repository is taking an action with real consequences against real systems. The MCP gateway is the enforcement point that makes those actions governable. It is a core component of the AI control plane, the governing layer between every AI agent in the organization and every system they’re allowed to reach.

Solving the MCP security problem

Without an MCP gateway, each AI agent in the organization manages its own connections to MCP servers: its own authentication, its own credentials, and its own access scope. IT has no central record of what tools are being called, by whom, or with what data.

This is shadow AI. An employee running Cursor with a privately configured GitHub MCP server. A developer who pasted production API keys into a config file. An internal agent making tool calls against a database with no audit trail and no revocation path. Most enterprises have far more of this than they realize, and the surface is nearly invisible to traditional asset inventory tools because MCP server configurations live in dotfiles rather than installed applications.

The problem compounds at scale. Three agents accessing ten MCP servers means 30 separate authentication flows to manage and no unified view of what’s being called across any of them. Security teams can’t inspect traffic they can’t see. Compliance teams can’t audit actions they don’t know are occurring.

The governance gap has three specific shapes.

Identity. Most MCP servers were built for individual developer use. Scoping access by employee, team, or role, and tying tool calls to real enterprise identity rather than a personal API key, requires a layer the MCP server itself doesn’t provide.

Visibility. Without a gateway, tool call records are scattered across individual MCP servers with no unified view. Which agent called which tool, with which arguments, producing which result: none of this is observable unless each server emits logs in a format existing tooling already ingests.

Enforcement. Policy on paper isn’t policy at runtime. Rules about which teams can access which tools need to be enforced at the point of use, not relied on to be remembered by developers who are moving fast.

How MCP gateways work

An MCP gateway sits between the AI agent and the MCP servers it wants to call. The agent doesn’t talk to MCP servers directly — every tool call routes through the gateway first.

The lifecycle of a tool call through an MCP gateway:

1. The AI agent (Claude Code, Cursor, Copilot, or a custom agent) decides to make a tool call. It connects to the gateway’s MCP endpoint rather than the MCP server directly.
2. The gateway authenticates the agent and maps its identity to the enterprise identity provider — Okta, Entra ID, or Google Workspace.
3. The gateway evaluates the tool call against access policy: is this agent, acting as this user, allowed to call this tool with these arguments?
4. If permitted, the gateway forwards the call to the upstream MCP server. If blocked, it returns a rejection with a reason.
5. The response flows back through the gateway. In transit, it can be inspected for PII, anomalous content, tool poisoning instructions, or data exfiltration signals.
6. Every step is logged with structured metadata: agent identity, tool name, arguments, response status, and latency.

The gateway doesn’t change the MCP protocol from the agent’s perspective. It presents itself as a standard MCP server to the calling agent. What changes is what happens in between.

Building a basic MCP proxy is straightforward. What takes months is everything around it: the policy engine, identity provider integration, argument-level inspection, audit log infrastructure, and keeping pace with MCP protocol changes. Most engineering teams that start down this path find the authentication layer alone consumes a sprint — before addressing revocation, role-scoping, or structured logging.

Why every company needs an MCP gateway

Three forces are converging to make MCP gateways a visible category rather than an optional nicety.

MCP won the standards battle. The Model Context Protocol has become the default way AI agents connect to tools and data. Claude Code, Cursor, Copilot, and most agentic frameworks now implement it natively. Standardization meant the category of tools that sit in front of MCP servers became both possible and necessary at the same time.

AI agents are proliferating. A given enterprise today may have dozens of AI tools in use, some purchased, some built, and most neither approved nor governed. Each one can make tool calls. Each one represents a surface that doesn’t yet have consistent access controls on it.

The mandate arrived before the foundation. Boards have told CEOs to deliver AI transformation. That mandate has been pushed down to CTOs, CIOs, and CISOs who are expected to move fast and govern carefully at the same time. The organizations discovering the governance gap most acutely are the ones that moved fast first — which is most of them.

Enablement vs. governance

The two purposes of an MCP gateway are distinct use cases, and organizations tend to arrive at the category through one or the other.

Enablement. Engineering teams building AI agents face an N × M integration problem. Four agents and twelve MCP servers means 48 separate authentication flows to build and maintain, 48 credential stores to secure, and 48 places where something can go wrong. A gateway centralizes that work: one authentication integration, one credential store, one place to update when a server changes. Teams often describe this as buying back weeks of engineering time that was going into auth plumbing rather than product.

Governance. Security and IT teams arrive at MCP gateways from the other direction. They’ve run an AI audit, found agents making tool calls against production systems they couldn’t see, and realized the policy they thought was in place wasn’t being enforced at runtime. The gateway is the enforcement point: policies become executable rules applied to every tool call rather than documents in a wiki.

Some gateways emphasize security, others enablement. Ultimately, these aren’t two separate products. The same gateway that simplifies authentication for developers is the one that enforces policy for security teams. Enablement and governance should be treated as properties of the same layer, approaching them as separate initiatives produces either a governance program that blocks adoption or an adoption program that bypasses governance.

MCP gateway vs. 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 model-level inspection of prompts and completions. Portkey and LiteLLM are examples.

An MCP gateway sits between the AI agent and the tools it calls, which happens after the model has decided to make a tool call. It doesn’t see the model selection decision. It sees what follows: which MCP server, which function, which arguments.

These layers are complementary, not competitive. An enterprise can and should have both. The distinction that matters practically is that most LLM gateways were not built to handle MCP semantics: tool-level RBAC, argument-level policy enforcement, stateful tool call sessions, or MCP-specific threats like tool poisoning and tool shadowing. An LLM gateway that sees prompts and completions is not a substitute for a gateway purpose-built for the tool-calling layer.

Vendor landscape

The MCP gateway category spans several architectural approaches. The table below covers the vendors most commonly evaluated for enterprise deployments. For enterprise buyers, the dimensions that matter are identity integration depth, policy enforcement granularity, and observability fidelity — not just MCP protocol support. For a detailed comparison, see Choosing an MCP gateway.

A note on Speakeasy

Speakeasy builds the AI control plane. The MCP gateway is the enforcement point for tool calls and third-party data access, and it’s where the Speakeasy platform starts. From there, the platform extends across the four functions that define the full control plane: Connect, Control, Secure, and Observe.

In practice, this means: an agent running Claude Code or Cursor connects to the Speakeasy MCP gateway endpoint instead of individual MCP servers. Authentication flows through the enterprise identity provider. Access policy — which team can call which tools, under what conditions — is set once in the control plane and enforced on every call. Every tool call produces a structured event that flows into the observability layer, where adoption, usage, and anomalies are visible across the entire organization.

New MCP servers are registered once and made available to the teams entitled to use them, so provisioning a new AI capability takes hours instead of weeks, and IT doesn’t lose visibility the moment a developer adds a new tool.

The MCP gateway is the enforcement point where the AI control plane begins — the layer that makes every agent-to-tool interaction authenticated, policy-governed, and auditable at scale. The reference architecture for the full control plane is here.