What are the best MCP gateways for enterprise in 2026?

Last updated: September 2026

A Model Context Protocol (MCP) gateway does two jobs. It gets tools into the hands of agents, and it governs what those agents do with them. The first job is enablement: handling authentication to every tool once instead of per person per client, providing a catalog of connectors and a path for internal APIs, making the gateway easy for any agent to reach, and reaching systems on the private network. The second job is governance: who is acting on each tool call, which clients may connect, which tools a role may call, and what the audit log records afterward.

This roundup covers eleven products that offer MCP gateway solutions: Speakeasy, which ships its gateway as one part of an AI Control Plane, three dedicated governance gateways (Runlayer, MintMCP, and Willow), four gateways bundled with API or model routing (Kong, TrueFoundry, LiteLLM, and Bifrost), and three infrastructure options from cloud platforms and open source (AWS AgentCore Gateway, Microsoft MCP Gateway, and Docker MCP Gateway). If your company has already standardized on Kong or on AWS, the gateway bundled with that platform is the right first answer, and we say so below. If you are running a single-team proof of concept against one validated server, Docker MCP Gateway or the Microsoft gateway is enough, and a governance product would be ahead of the problem.

Isn't the API gateway we already run an MCP gateway?

A company that already fronts every API with Kong or builds on Amazon Bedrock can use the bundled gateway first. Kong's AI MCP Proxy plugin converts current REST APIs into MCP tools using no server code, while the OpenID Connect, auth, limiting, and logging plugins the infrastructure group already manages work for MCP endpoints just as they work for APIs. AWS AgentCore Gateway makes MCP tools from OpenAPI, Smithy, and Lambda endpoints and handles inbound and outbound OAuth in hosted software. Both avoid bringing in a vendor, another security audit, or fresh procurement, and that is decisive when MCP use means just a few APIs hit by a few agents.

An API gateway can't help when an audit wants to know who ran a function. On Kong, the identity is a Kong Consumer that a Kong auth plugin checks, and Consumers and Consumer Groups (since gateway 3.13) carry per-tool ACLs that control what that Consumer can reach. No public doc defines an agent identity that resolves in Entra or Okta, while Kong's scope-of-support says AI Guardrails does not cover MCP through the plugin. Konnect Labs hosts the MCP Registry, which would let the system track tools, as a Tech Preview. On AWS, inbound auth reads JWTs from an OIDC source, so the requester can be a directory principal, yet the gateway governs only what flows through it and only within the AWS boundary. Each one is a gateway and only gets the requests it receives. If a dev plugs an open MCP tool into Cursor on Tuesday, it doesn't go through those gateways.

That space, between what the gateway receives and what's actually out there, is where those vendors fight for business.

How we evaluated enterprise MCP gateways

The criteria split along the two jobs. The first four measure how a gateway gets tools to agents. The remaining five measure how it governs what agents do with them. They are the questions we've seen in evaluations and the questionnaires that come after. They don't flatter any single vendor, and we flag where a vendor's documentation falls silent.

Enablement:

• Session management. Every MCP server has its own authentication, and without a gateway each person completes it separately in each client, then again when the token expires. A gateway takes that over: it signs the person in once, acts as the OAuth client to each upstream service on their behalf, stores and refreshes the upstream tokens, and holds a shared API key where a service has no per-user OAuth. Check whether the gateway does this for third-party servers it did not build, and whether it can present modern OAuth to clients when the upstream server has none.
• Connectors. Two kinds. Catalog connectors are the SaaS tools employees want on day one, either hosted by the vendor or offered as a marketplace of third-party servers, and a large catalog matters less than whether the systems your teams use are in it. Internal connectors are your own APIs, and gateways differ on how those become MCP tools: some convert an existing API contract into tools with no server code, some generate and host a server from it, some package a server you wrote as a container, and some require a running MCP server with credentials before setup begins. That difference decides whether the platform team is a bottleneck for every new integration.
• Distribution. How does an agent get connected to the gateway? The floor is a URL an employee pastes into a config file. Above it sit plugins or bundles that install a set of servers into Claude Code, Cursor, or Codex through their marketplaces, role-based assignment so a person gets the right set without asking, and a device agent or managed settings that push the configuration out. Distribution is what decides adoption, because a governed path nobody can find loses to an ungoverned one that is a copy-paste away.
• Private network. Most of the systems worth connecting are behind a firewall. The options are a tunnel or private link from the gateway to servers you run, a self-hosted data plane, or running the whole gateway yourself. Self-hosted and air-gapped deployment is a hard requirement for some buyers and irrelevant to most, so we note it without weighting it.

Governance:

• Identity tied to the IdP. Does every tool call resolve to a principal in Okta, Entra, or Google Workspace, or to a key, Consumer, or user record that lives only inside the gateway? A gateway-local principal is fine for a proof of concept and a liability at offboarding, because revoking the person in the directory does not revoke the key. Session length matters here too: buyers want to set how long a single sign-in stays valid for an MCP client, and most gateways either fix it or leave it to the upstream provider.
• Client admission. Which MCP clients may appear at the authorization endpoint? MCP adopted OAuth with Dynamic Client Registration (DCR), where any client posts a name and redirect URI and receives a client_id. Nothing in that POST is verified, and every install registers separately, so 500 engineers on three tools produce more than 1,500 client records with nothing an administrator can write a rule against. Client ID Metadata Documents (CIMD) replace the registration call with a URL on the vendor's domain, which is something an allowlist can name. CIMD is still an IETF Internet-Draft and the MCP specification's 2026-07-28 release deprecates DCR while keeping it for compatibility, so in practice a gateway has to support both. The full trade-off is in CIMD vs DCR for MCP OAuth.
• Tool-call authorization. Server allowlists are the floor. An enterprise rollout needs role-based grants that narrow to individual tools, to tool annotations (read-only by default), and to argument-level conditions, and it needs curation and enforcement as separate controls: which tools a team is offered is a different decision from which calls are permitted at runtime. Buyers we have talked to draw that line explicitly, because the team that curates the catalog is rarely the team that owns the deny rule.
• Shadow MCP and inventory. Does the product know about MCP servers that were never registered with it? That requires a presence beyond the gateway: hooks inside the coding agent, a device agent, MDM integration, or a browser extension. A gateway without one governs the sanctioned path and is blind to the rest. See what is shadow MCP.
• Audit and export. Every product logs tool calls. The questions are whether the log names the directory user and the client, whether it captures the whole path from prompt to API response or only the gateway hop, and whether it exports to the SIEM you run, over a standard like OTLP, without a support ticket.

We didn't cover latency or cost. Vendor latency data comes from vendor-run benchmarks; rates for every tool here but open-source ones are negotiated. Cost attribution, on the other hand, is in scope, because more than one buyer has told us that the finance question ("which department is spending what on agents") arrives in the same quarter as the security one.

Enterprise MCP gateways at a glance

The table groups vendors by architecture, which is where the enablement path shows up (a governance product with a catalog, an API gateway converting routes, an LLM proxy registering servers), and by the two governance questions that separate them most: who acts on each tool call, and how far enforcement reaches past the gateway. Profiles follow in the same order and cover the enablement side in detail.

Where Speakeasy fits

Speakeasy is the option when the evaluation scores both jobs at once: supplying the tools agents need and governing every AI surface they use. It ships its gateway as one part of an AI Control Plane, so the same identity and policy data drive both sides.

On session management, a person signs in to the gateway once through the organization's IdP, and the control plane handles authentication to the tools behind it. For services such as Linear, GitHub, or Slack it acts as the OAuth client on the person's behalf and holds a token per end user, encrypted at rest and refreshed silently, so a Linear tool call runs as that person in Linear. Where a service has no per-user OAuth, one shared credential is held once and used for every caller. When a third-party remote server is registered, the control plane registers itself with that server's authorization server automatically if it supports DCR. And because the control plane runs OAuth 2.1 with PKCE toward clients, agents that expect modern auth work against upstream servers that have not implemented it.

On connectors, the catalog covers common SaaS tools, any third-party or in-house MCP server can be registered, and internal APIs become servers Speakeasy generates from the existing API so a platform team doesn't write server code for each system. On distribution, agents reach every server through one URL, and plugins bundle servers and skills, assign them to roles, and publish to the Claude Code, Cursor, and Codex marketplaces, with install instructions for OpenCode and OpenClaw and delivery through the device agent for role-gated sets. A default plugin picks up newly created servers, so a new internal server is installable the day it ships. On private network, servers behind your firewall connect over outbound-only tunnels, and a self-hosted data plane is available on enterprise plans.

On identity, people sync from Okta or Entra through directory sync over SCIM, sign-in is federated to the organization's IdP with its MFA and conditional access policies, and each tool call resolves to that directory user. Directory attributes such as department, division, and cost center carry into the Costs view and into budgets that flag or block spend per department, which is how the finance question gets answered from the same identity data as the security one. Agents can be held as first-class principals with their own credentials, owners, and allow-only policies, so an agent never does more than the person accountable for it; this is in early access and rolling out per organization.

On client admission, the control plane runs an OAuth 2.1 authorization server for each MCP server and supports CIMD alongside DCR. CIMD support is enabled per organization. Each issuer carries an admission policy, open or presets, and in presets mode a client URL has to match a Speakeasy-maintained catalog of vendor documents or a custom URL you add before the control plane fetches anything, so "only Claude Code and VS Code may request access to this server" becomes a rule you can write. DCR remains supported for clients that have not shipped CIMD, with no deprecation date. Session Duration is configurable per server and governs the refresh window; access tokens are fixed at one hour.

On authorization and reach, every MCP server has an Access page where a grant to a person or role can be narrowed to specific tools or to an annotation such as read-only, which keeps curation (what a team is offered) and enforcement (what a call is allowed to do) as separate controls. Enforcement then follows the agent past the gateway: agent hooks in Claude Code, Cursor, Codex, and OpenCode see prompts and tool calls at the agent, a device agent on macOS, Windows, and Linux scans for AI tools on a list the organization edits, and hook-observed calls to unregistered servers surface as shadow MCP. Risk policies run prompt-injection, PII, secret, and financial-data detection inline on prompts, tool calls, and responses, and both telemetry and risk findings export over OTLP to your own SIEM or observability stack from the dashboard. Speakeasy holds SOC 2 Type 2 and ISO 27001.

The limits are also plain. Speakeasy does not route model traffic, so a team that needs provider failover keeps LiteLLM, Bifrost, or TrueFoundry on the model path and puts Speakeasy on the agent-to-tool path. Cost figures are reported by the AI clients, so Claude Code, Codex (through OpenAI compliance logs), and Cursor spend is attributed and clients that report no cost contribute token counts only. The control plane is hosted on Speakeasy-managed infrastructure; air-gapped deployment is not what it is built for, and Willow, TrueFoundry, LiteLLM, or Bifrost are the better fit if that is the requirement. And CIMD only helps with the clients that have shipped it; several widely used clients and bridges still register through DCR, which is why we keep it on.

Dedicated MCP governance gateways: Runlayer, MintMCP, and Willow

These three started as governance products and each has since added an enablement layer: hosted connectors, a self-serve store, or a marketplace. They answer the identity and inventory questions better than the bundled gateways, and they differ from each other on how tools get in (containers you package, connectors the vendor hosts, or a marketplace), where agents' identities live, and how much of the operational burden they take on.

Runlayer: the security-first MCP gateway

Runlayer is the strongest option on this list for a shortlist the security team owns, and if that is your situation you should evaluate it seriously before reading the rest of this page. Every MCP request passes through a single-tenant AWS gateway that authenticates, authorizes, scans, and logs it. ToolGuard scans tool definitions at registration and tool outputs at runtime, blocking by default with findings mapped to MITRE ATLAS, and AgentGuard analyzes whole sessions for reasoning pivots that a per-call scanner misses. Its Shadow AI feature reaches off-network laptops through MDM tools such as Jamf, Intune, and Kandji, which is a real answer to the inventory question for organizations that already run an MDM fleet. Runlayer lists SOC 2 Type II and HIPAA.

The trade-offs are the ones a security-first design makes. Agents authenticate as Runlayer-native Agent Accounts rather than as principals in your identity provider, custom servers are packaged as containers and deployed to Runlayer-managed infrastructure with no path from an API contract to a generated server, and deployment is single-tenant AWS only. Runlayer scopes itself to the MCP tool layer, so it does not see model calls or the APIs underneath a tool. See Speakeasy vs Runlayer and Runlayer alternatives for the detail.

MintMCP: the managed MCP gateway

MintMCP is an enterprise MCP gateway delivered as a managed service. Its documentation describes it as a gateway that "sits between your AI clients and MCP servers," and its strength is the operational work it removes: hosted connectors MintMCP operates, a self-serve MCP store employees reach after SSO, role-based virtual servers that expose only the tools a team needs, and an endpoint product called Agent Monitor that hooks coding agents on laptops, including GitHub Copilot CLI. Its trust center lists SOC 2 Type 2, HIPAA, and CASA Tier 2. For a buyer whose first requirement is "no new infrastructure to run," MintMCP is the shortest path to a governed rollout.

Two things to check in an enterprise evaluation. Agent identities are native to MintMCP with no matching record in Okta or Entra, so the offboarding question has to be answered inside MintMCP rather than in the directory. And the most expressive policy layer is customer-authored JavaScript middleware, which is flexible and also means the deny rule is code your team maintains. Custom servers are configured by hand as STDIO, Docker image, or CLI deployments. Self-hosting is listed on its pricing page; the product is primarily managed cloud. See Speakeasy vs MintMCP and MintMCP alternatives.

Willow: the governance gateway with an enablement layer

Willow, which rebranded from Webrix in 2026, wraps a governance gateway in a self-serve enablement layer. Every call routed through it passes four checks: identity, group-based access to the target server, runtime guards on request content, and response guards that mask PII on the way back. Around the gateway sit a marketplace with a claimed 1,000+ pre-built connectors, API-to-MCP conversion, endpoint sensors that surface unapproved tools and shadow MCP servers, and a Chrome extension as a browser policy layer. Willow deploys as SaaS, self-hosted on AWS, GCP, or Azure, or on-prem and air-gapped, which makes it the only dedicated governance gateway here with an air-gapped answer. Willow reports SOC 2 Type II.

The identity model is the thing to weigh. The Willow gateway mints and validates its own tokens; SSO providers such as Okta and Entra ID sit upstream, SCIM removes access at offboarding, and access on each call follows Willow group assignments matched to a Willow user record rather than a directory principal evaluated at call time. SCIM and guardrails are gated to custom enterprise plans, per its pricing page. We assessed Willow from its documentation rather than hands-on, and the line-by-line comparison is in Speakeasy vs Willow.

MCP gateways bundled with API and LLM routing: Kong, TrueFoundry, LiteLLM, and Bifrost

These four arrived at MCP from an adjacent job. Kong extends API management, TrueFoundry attaches governance to a model-routing gateway, and LiteLLM and Bifrost add MCP to open-source LLM proxies. The shared property is that the principal is whatever the underlying gateway already used: a Consumer, a gateway user, or a virtual key.

Kong: MCP as a plugin on the AI gateway

Kong is covered in the steelman above, and the summary holds. Its MCP support ships as the AI MCP Proxy plugin in the AI Gateway Enterprise offering on gateway 3.12 or higher, generates tool configuration from an OpenAPI 3.x document through openapi2mcp, and applies the Kong plugin catalog to MCP endpoints. Per-tool ACLs on Consumers and Consumer Groups arrived in 3.13 with an audit log of allowed and denied attempts. For an enterprise already operating Kong well, that is a working MCP gateway with no new vendor. The gaps are the ones named earlier: Consumer-based identity, AI Guardrails excluded from MCP traffic, a registry still in Tech Preview, and no presence beyond the gateway. See Kong MCP gateway alternatives.

TrueFoundry: governance attached to a model-routing gateway

TrueFoundry is a gateway company whose flagship AI gateway routes application traffic across more than 250 LLMs with load balancing, failover, semantic caching, and cost controls, and its MCP gateway extends the same infrastructure to tool traffic. Governance is deep on the access side, with RBAC, ABAC, and Cedar and OPA policy support, and its guardrails framework orchestrates providers such as AWS Bedrock, Azure PII Detection, Enkrypt AI, and Palo Alto Prisma AIRS. It deploys as SaaS or self-hosted on Kubernetes, including air-gapped, and is SOC 2 certified across tiers. For an ML platform team whose primary problem is moving model traffic, TrueFoundry is the one vendor here that solves that and MCP governance on one pipe.

The costs follow from that shape. Detection runs through orchestrated third-party guardrails rather than native enforcement, audit logs are gated to the Enterprise tier per its pricing page, and it has no presence on the device or in the client, so AI usage that does not route through its gateway is invisible to it. Setup also requires a running MCP server with credentials before you start, which suits established infrastructure and slows a proof of concept. See Speakeasy vs TrueFoundry.

LiteLLM: the open-source LLM proxy with an MCP gateway

LiteLLM is the incumbent open-source proxy: an OpenAI-compatible API across more than 100 providers with retries, fallbacks, virtual keys, and per-key and per-team budgets. Its MCP gateway extends the proxy to tool traffic, with servers added in the UI or config.yaml, OAuth 2.0 to upstream servers, access controlled by key, team, and organization, and spend tracked per MCP server. A guardrails framework runs providers such as Presidio, Lakera, Bedrock, and Azure Content Safety, and a Generic Guardrail API accepts an external control plane, which is the hook the Speakeasy LiteLLM integration uses. It self-hosts anywhere, including air-gapped, and its enterprise page lists SOC 2 Type 2 and ISO 27001, with SSO, SCIM, and audit logs in the paid tier.

The enterprise caveat is that every call is tied to a LiteLLM key rather than a directory user, and there is no endpoint or agent-side component. LiteLLM is the right answer for a platform team that wants one self-hosted proxy for models and tools and is willing to build identity mapping around keys. It is not a governance plane on its own.

Bifrost: the performance-first AI gateway with a built-in MCP gateway

Bifrost is the open-source AI gateway from Maxim AI, written in Go under Apache 2.0. It routes model traffic across 20+ providers with automatic failover, load balancing, and semantic caching, and its built-in MCP gateway aggregates tools at a single endpoint with per-virtual-key allowlists and OAuth to upstream servers. Its published benchmarks claim microseconds of added overhead per request; those numbers are Maxim's own. A licensed Enterprise tier adds OIDC SSO, SCIM, RBAC, signed audit logs, and guardrails, and it self-hosts from a single command to air-gapped Kubernetes. Bifrost Edge, in alpha, is the one attempt in this group to reach devices.

The principal on every decision is a virtual key. Enterprise syncs users from Okta or Entra via OIDC and SCIM, but agents themselves authenticate as keys, and every enterprise control sits in the paid tier. Bifrost belongs on a shortlist where a self-hosted binary and stated latency requirements are the constraints. See Speakeasy vs Bifrost and Bifrost alternatives.

Infrastructure MCP gateways: AWS AgentCore Gateway, Microsoft MCP Gateway, and Docker MCP Gateway

These three are routing and lifecycle infrastructure. They belong on an enterprise list because enterprises use them, and because for a scoped proof of concept they are often the correct amount of product.

AWS AgentCore Gateway: managed MCP tools on Bedrock

Amazon Bedrock AgentCore Gateway converts APIs, Lambda functions, and existing services into MCP-compatible tools, accepting OpenAPI, Smithy, and Lambda as tool input types. It handles inbound authentication (verifying the agent's identity with a JWT from Cognito or another OIDC provider) and outbound authentication (OAuth flows, token refresh, and credential storage for third-party services) in one managed service, and it also fronts other agents and routes inference requests across model providers. For an enterprise building agents on Bedrock with tools that are AWS-hosted APIs and Lambda functions, it is the obvious first gateway and requires no new vendor.

Its boundary is the AWS account. It governs traffic that routes through it, has no presence in a coding agent or on a device, and its inventory is the set of targets you registered. An employee's Claude Desktop pointed at a third-party MCP server is outside its view.

Microsoft MCP Gateway: session-aware routing on Kubernetes

Microsoft MCP Gateway is an open-source reverse proxy and management layer for MCP servers in Kubernetes. It provides session-aware routing, so every request carrying a given session ID reaches the same server instance, a control plane for deploying, updating, and deleting servers, and bearer-token authentication with RBAC on both the data and control planes. It deploys locally or with one click to Azure. It is infrastructure in the strict sense: it makes running many MCP servers on AKS tractable and leaves identity mapping, tool-level policy, and threat detection to the layers around it.

Docker MCP Gateway: container orchestration for a scoped POC

Docker MCP Gateway is open source with no platform fees and gives a Docker-native team full infrastructure control through file-based configuration: credentials in .env, services in docker-compose.yml, and a server catalog in YAML. It supports any MCP server available as an npm package or Docker image. There is no authentication layer, so you build one through network isolation and per-server credentials or put a reverse proxy or API gateway in front, and logging is Docker's native logs with no structured audit trail or request tracing. For a single team validating one MCP server before a wider rollout, that is a reasonable place to start, and the cost is DevOps time rather than license fees. We covered setup in detail in which MCP gateway architecture do I need.

Which enterprise MCP gateway should you choose?

The decision rule, by the constraint that dominates your evaluation:

• Identity that resolves to the directory for people and agents, admission policy per server, and enforcement that reaches agents the gateway never sees. Speakeasy, on the agent-to-tool path, with a model gateway kept in the chain if you need failover.
• You already operate Kong or build on Bedrock, and MCP traffic is a few internal APIs. Use the bundled gateway. Kong's AI MCP Proxy or AWS AgentCore Gateway. Revisit when a security review asks for directory-resolved identity or an inventory of servers the gateway never saw.
• A single team is running a scoped proof of concept on one validated server. Docker MCP Gateway or Microsoft MCP Gateway. Spend the budget on the server, not the gateway, and write down which of the nine criteria above the POC did not test.
• The security team owns the shortlist and ML threat detection on tool calls and sessions is the requirement. Runlayer, with the caveat that agent identities are Runlayer-native.
• Minimal operations and a self-serve store for employees is the requirement. MintMCP, with the caveat that agent identities and the deny rule live inside MintMCP.
• On-prem or air-gapped is non-negotiable. Willow for a dedicated governance gateway; TrueFoundry, LiteLLM, or Bifrost if model routing rides the same deployment.
• One self-hosted proxy for model and tool traffic. LiteLLM for maturity and integration surface, Bifrost if stated latency figures matter, TrueFoundry for a commercial vendor with governance attached.

What a scoped MCP proof of concept should test

Enterprise buyers we have spoken with want a POC with one validated server and a handful of users, not production sprawl, and the risk in that shape is that a small POC passes without exercising the controls that fail at rollout. Whatever gateway you pick, put these on the test plan:

• Offboarding. Remove a POC user from the directory and confirm the gateway denies their next tool call without anyone touching the gateway.
• Client admission. Attempt to connect from an MCP client that is not on the approved list and record what the user sees and what the audit log records.
• Least privilege. Grant the POC role read-only access to the server and confirm a write-annotated tool is refused at call time, not merely hidden from the tool list.
• Session length. Set the session duration your security policy requires and confirm the client is forced to re-authenticate on schedule.
• Traffic that skips the gateway. Point a coding agent at a server that is not registered and see whether the product notices.
• Attribution. Pull the POC's tool calls and spend by department from the export, using the same identity the directory uses.

If a gateway passes all six with one server, it will pass with fifty. If it passes five, you know which vendor conversation to have before signing.

If you are working through a shortlist like this one, or running a scoped proof of concept and want to compare notes on what to put in the test plan, we'd like to talk.