Top 10 MCP gateways in 2026, compared for enterprise agent teams

An MCP gateway is the single endpoint that AI agents use to reach Model Context Protocol servers, and in 2026 it has become the place where enterprise teams decide which agent may call which tool, under whose identity, with what record. The category has filled up quickly. Cloud providers, API-management vendors, open-source foundations and start-ups all now ship something they call an MCP gateway, and the products differ far more than the label suggests. This ranking is for platform, security and AI engineering leads choosing one for agents that touch production systems.

What the gateway does, step by step, is covered in our explainer on what an MCP gateway is and when agent teams need one; this piece does not repeat it. Here the question is narrower: of the ten gateways worth shortlisting in October 2026, which handle authentication, tool-level policy, guardrails and audit well enough for enterprise use, and what does each one cost you in lock-in, licence or operations? Readers who only want self-hosted projects should also see the companion ranking of open-source MCP gateways, and those choosing the servers behind the gateway can start with the top MCP servers of 2026.

How we ranked them

The ranking weights the controls that matter once agents act for many people against systems that hold real data. We read each product’s own documentation, release notes and repository between 29 September and 5 October 2026. Nothing was load-tested by us; performance figures are vendor-published and labelled as such. Eleven criteria, in rough order of weight:

1. Inbound authentication. Does the gateway validate the caller with OAuth 2.1, OIDC or signed keys, as the MCP authorisation specification expects of HTTP servers?
2. Per-user upstream credentials. Can each user reach an upstream server under their own OAuth token, or does every agent share one admin credential?
3. Tool-level access control. Can policy allow or deny an individual tool for an individual caller or group, and is the default deny?
4. Tool filtering and virtual servers. Can administrators publish curated bundles of tools from several servers behind one endpoint?
5. Audit logging. Are tool calls and policy changes recorded in a form a security team can export?
6. Guardrails on tool calls. Can a rule inspect, redact or block a specific call’s arguments or results, not just the tool name?
7. Observability. OpenTelemetry, Prometheus, cost and latency attribution.
8. LLM gateway integration. Does the same product, and the same identity, govern model calls?
9. Transport support. stdio, SSE and Streamable HTTP, and the newer stateless 2026-07-28 protocol revision.
10. Deployment. Self-hosted, in-VPC, air-gapped or managed only.
11. Licence and performance. Open-source terms, which features sit behind an enterprise tier, and any published overhead figures.

The first six carry most of the weight. A gateway that logs everything but lets every agent call every tool with a shared token is a proxy, not a control point.

The ten contenders at a glance

Two credible projects missed the cut and are covered after the list: Microsoft MCP Gateway and Agent Router, the project formerly called Envoy AI Gateway.

Figure 1: Where a gateway comes from predicts its strengths. Products built as agent gateways treat tools and models as one problem; API platforms treat MCP as another route.

1. Bifrost

Bifrost is an open-source AI gateway written in Go by Maxim AI that routes LLM traffic and acts as an MCP gateway in the same process. The repository shipped release v2.2.5 on 2 October 2026. It connects to upstream MCP servers over stdio, HTTP and SSE and exposes the combined catalogue at one /mcp endpoint.

Strengths. Bifrost covers more of the eleven criteria than any other entry. Its MCP gateway gives each virtual key its own tool allow-list, deny by default, checked at both tools/list and tools/call. Upstream credentials come in six authentication modes, including per-user OAuth, per-user headers and, in the enterprise tier, token exchange, where each caller reaches the upstream server under their own identity and no credential is stored. Virtual MCPs bundle tools from several servers behind /mcp/<slug>, reachable only through the keys they are attached to, and are part of the open-source gateway.

The enterprise tier adds the rarest control in the category: guardrails at the tool boundary. A rule can inspect a call’s arguments and block it before execution, or inspect the result and withhold it from the model, targeting a specific server, tool or argument field, with every guardrail provider that applies to LLM traffic also available to MCP rules. Audit logs record administrative changes, can be HMAC-signed, are retained for 365 days by default and export as JSON, JSON Lines or RFC 5424 Syslog. Because MCP access is just another permission on a virtual key, the same governance controls (budgets, rate limits, RBAC) apply to model calls and tool calls under one identity.

Performance is the best documented in the list. Bifrost’s published benchmarks report 11 µs of internal overhead at 5,000 requests per second on a t3.xlarge and 59 µs on a t3.medium, with a public harness to reproduce them.

Limitations. Audit logs, tool-call guardrails, token exchange, SSO and clustering come with the enterprise tier, so teams that need them from day one should plan for that licence.

Best fit: in our assessment, the strongest choice for enterprise agent teams that want one self-hosted control point for models and tools, particularly in regulated or air-gapped environments.

2. AWS Bedrock AgentCore Gateway

AgentCore Gateway is AWS’s fully managed gateway for agent traffic. It turns OpenAPI specifications, Smithy models and Lambda functions into MCP tools, aggregates existing MCP servers into one virtual MCP server, passes through A2A and HTTP traffic, and routes inference requests across model providers.

Strengths. Authentication is the most complete of the managed options. Inbound, it accepts JWTs from any OIDC identity provider, IAM SigV4, and publishes RFC 9728 protected-resource metadata. Outbound, it handles OAuth client credentials, three-legged authorisation code flows, on-behalf-of token exchange, SigV4 and API keys. Fine-grained access control works at the tool, operation and parameter level through interceptor Lambdas and Cedar policies. Semantic tool search lets agents find the right tool among thousands without loading every definition. It supports MCP protocol versions from 2025-03-26 to the stateless 2026-07-28 revision.

Pricing is metered: $0.005 per 1,000 invocations, $0.025 per 1,000 search calls and $0.02 per 100 tools indexed per month as of October 2026, with Cedar policy authorisation billed per request.

Limitations. It runs only in AWS. Parameter-level control means writing and maintaining interceptor Lambdas. The documentation notes that dynamic tool listing does not work with semantic search or outbound three-legged OAuth, and the default mode needs explicit target synchronisation when upstream tools change. Bedrock Guardrails are billed separately.

Best fit: agent teams already on AWS who want inbound and outbound auth handled for them and can accept AWS as the identity and audit plane.

3. agentgateway

agentgateway is an open-source proxy written in Rust for agent-to-LLM, agent-to-tool and agent-to-agent traffic. Solo.io contributed it to the Linux Foundation in August 2025, and it became an Agentic AI Foundation project in June 2026. Release v1.6.0 shipped on 2 October 2026.

Strengths. It is the closest open-source analogue to Bifrost’s combined scope. One OpenAI-compatible API routes to OpenAI, Anthropic, Gemini, Bedrock, Vertex and self-hosted inference servers, with budgets and failover. On the MCP side it supports stdio, HTTP, SSE and Streamable HTTP, federates tools from several servers and converts OpenAPI services into MCP tools. Its MCP authorisation uses CEL rules, such as mcp.tool.name == "echo", that can reference JWT claims and apply per tool, prompt and resource, and tools a caller may not use are filtered out of list responses. The project advertises MCP guardrails that inspect tool calls and responses in flight, with regex, moderation, Bedrock Guardrails, Model Armor and webhook backends. OpenTelemetry is on by default.

Limitations. There is no documented per-user OAuth credential store for upstream servers comparable to Bifrost’s or AgentCore’s, so per-user identity must come from JWT claims and policy. Tool-call logging is documented, but there is no signed administrative audit trail in the open-source project. The project publishes no numeric MCP overhead figures. Release v1.6.0 also changed how Anthropic requests are translated, a reminder that the LLM side is still moving.

Best fit: Kubernetes platform teams that want an open-source, foundation-governed data plane and are comfortable expressing policy as CEL.

4. Cloudflare MCP server portals

MCP server portals put many remote MCP servers behind one URL protected by Cloudflare Access, as part of the Cloudflare One zero-trust platform. They launched in open beta in August 2025 for all plans.

Strengths. Identity is handled by the Access policies an organisation already has: users sign in with the corporate identity provider, and upstream servers can require per-user OAuth (the default when user auth is required) or use a stored admin credential. Administrators can disable individual tools or prompts, run in allow-list mode, alias tools and rewrite their descriptions, which is a direct mitigation for poisoned tool descriptions. A portal-level Code Mode replaces upstream tool definitions with two tools, search and execute, and can be opt-in, on by default or enforced. When Gateway routing is on, tool calls pass through Cloudflare Gateway’s DLP inspection. The portal supports the stateless 2026-07-28 protocol towards clients.

Limitations. Portals are SaaS only and support HTTP servers only; stdio servers must be wrapped and hosted first. Each portal holds up to 80 servers. The documentation warns that some Access controls, such as independent MFA and purpose justification, are not enforced for servers authorised through a portal, and that admin OAuth tokens can expire silently. Exporting logs to a SIEM through Logpush needs an Enterprise plan. There is no LLM routing in the portal itself.

Best fit: organisations already on Cloudflare Access who want governed remote MCP for employees with no infrastructure to run.

5. Kong AI Gateway

Kong added MCP to its AI Gateway through the AI MCP Proxy plugin, first shipped in Kong Gateway 3.12 in October 2025. It runs in four modes: proxying an existing MCP server, converting REST routes into MCP tools, generating tool specifications only, or aggregating tools from several conversion plugins into one endpoint.

Strengths. Kong’s strength is that MCP becomes another route in an API estate that may already handle authentication, rate limiting and analytics for thousands of services. Since 3.13 the plugin supports default and per-tool ACLs by consumer and consumer group, and 3.14 (April 2026) added ACLs based on OAuth claims. The AI MCP OAuth2 plugin implements the MCP authorisation requirements based on OAuth 2.1, validates tokens by introspection or JWKS and, by default, does not forward the client’s access token upstream, which matches the specification’s ban on token passthrough. MCP logs record session IDs, JSON-RPC methods, payloads, latencies and errors, and metrics flow to Konnect.

Limitations. Both MCP plugins are available only with AI Gateway Enterprise. The plugin page lists AI Guardrails integration among unsupported features, so Kong’s prompt guards do not apply to tool calls. It does not support WebSocket or gRPC upstreams. Its MCP Registry is a tech preview in Konnect Labs. There is no per-user upstream OAuth credential store documented on the plugin pages.

Best fit: organisations that already run Kong Enterprise or Konnect and want MCP governed with the same consumers, plugins and analytics as the rest of their APIs. Our comparison of LLM gateways covers Kong’s model-routing side.

6. IBM ContextForge

ContextForge is IBM’s open-source registry and proxy that federates MCP, A2A, REST and gRPC services behind one governed endpoint. Release v1.0.11 shipped on 28 September 2026.

Strengths. Federation is the point. ContextForge wraps REST and gRPC services as MCP tools, links multiple gateway instances together, and publishes virtual servers that bundle chosen tools. It supports HTTP, WebSocket, SSE and Streamable HTTP, and SSO through GitHub, Google, Entra ID, Keycloak, Okta and IBM Verify, with user-scoped OAuth tokens. RBAC works at global, team and personal scope. Its plugin framework has tool_pre_invoke and tool_post_invoke hooks, built-in PII filtering and deny lists, and external plugins over MCP, Unix sockets or gRPC. Observability is broad: OpenTelemetry to most backends, Prometheus metrics and an admin UI.

Limitations. The RBAC documentation states that permissions are per resource action, “not per-tool”, so fine-grained control comes from virtual-server composition and plugins rather than per-tool grants. The README says arm64 is not supported in production and that insecure defaults must be changed before deployment. It needs PostgreSQL and Redis. Support for the 2026-07-28 protocol revision is off by default. LLM routing is limited to a chat client and A2A agents, not a general model gateway.

Best fit: enterprises with many internal REST or gRPC services that want them exposed as MCP tools under one registry, especially on OpenShift.

7. Azure API Management

Azure API Management can expose any managed REST API as an MCP server, with operations becoming tools, or proxy an existing remote MCP server. It is available across classic and v2 tiers and through the self-hosted gateway.

Strengths. For Azure organisations it reuses everything already configured: Entra ID token validation, products and subscriptions, rate limits, quotas, IP filtering and caching. Microsoft documents OAuth 2.1 with Entra ID for inbound access and the credential manager for outbound tokens. Monitoring runs through Azure Monitor and Application Insights, and Azure API Center serves as a private MCP registry. Servers can be managed as code through ARM, Bicep, the Azure CLI and Terraform.

Limitations. Policies currently apply to all operations exposed as tools on a server, so per-tool policy means splitting servers. REST-derived servers support tools only; proxied servers support tools and resources but not prompts. MCP features are not supported in workspaces. Response-body logging must be off for MCP servers to stream correctly, which limits audit depth. There is no guardrail that inspects tool arguments natively, and Microsoft documents no explicit general-availability date.

Best fit: Azure-centred enterprises that want existing REST APIs available to agents with minimum new infrastructure.

8. Obot

Obot is an MIT-licensed, self-hosted platform that combines an MCP gateway, MCP and skills registries and an LLM gateway. Release v0.26.2 shipped on 2 October 2026 and replaced composite servers with virtual MCP servers.

Strengths. Obot is built around the catalogue: Git-backed registries, the standard MCP Registry API, and access scoped by user or identity-provider group. It manages OAuth and credentials for MCP servers, issues scoped API keys and records MCP requests and responses filterable by user, server, tool or session. Filters, implemented as MCP filter servers or HTTP webhooks, can accept, reject or modify messages and target specific tool calls, with a sample PII filter published. Activity is linked across MCP servers, LLM providers and devices, with token counts and estimated cost.

Limitations. The free editions are capped at 100 users and 100 devices, and Entra, Okta and similar logins require the free Community registration; larger deployments need the Enterprise edition. There is no hosted option. Version 0.26 brought migration work, including removal of legacy APIs and a single-replica requirement during Kubernetes upgrades. Transport support is not spelled out on the pages we read.

Best fit: mid-sized organisations that want a self-hosted internal MCP catalogue with IdP-group access and a simple LLM gateway alongside.

9. MintMCP

MintMCP is a commercial MCP gateway paired with Agent Monitor, which watches coding-agent tool calls in Claude Code, Cursor, Copilot and Codex. It runs as a managed cloud service or self-hosted.

Strengths. It packages the enterprise basics quickly: clients connect through OAuth, stdio servers are hosted in containers behind OAuth, and upstream credentials can be shared or per-user API keys, auto-refreshed OAuth tokens or AWS SSO tokens converted to STS credentials, all encrypted at rest. Each server has its own tool customisation and access policy, and Virtual MCPs bundle connectors per role. Rules can match tool names by regex with argument conditions and then flag, stop or alert on a call. SSO, SAML, OIDC and SCIM are available on enterprise tiers, and the vendor states SOC 2 Type II.

Limitations. It is closed source with no public prices. Its “LLM proxy” is a monitoring and blocking layer for coding agents, which its own documentation says is not a model router. Catalogue sizes differ across its own pages. OpenTelemetry export is not documented on the pages we read.

Best fit: security teams that need to put coding agents and their MCP servers under policy quickly and prefer a vendor-run service.

10. Docker MCP Gateway

Docker MCP Gateway is an MIT-licensed Docker CLI plugin that runs each MCP server in its own container behind one endpoint. It powers the MCP Toolkit in Docker Desktop; v0.44.1 was tagged as a pre-release on 23 September 2026.

Strengths. It is the best answer in the list to the risk of running untrusted servers locally. The security model runs containers with no-new-privileges and resource limits, verifies signatures on official images, blocks network access per server on request, and scans tool arguments and responses for secrets by default. Profiles group servers and enable individual tools. Catalogues and profiles are distributed as OCI artifacts. It supports stdio, SSE and streaming HTTP, requires a bearer token on HTTP transports by default and exports OpenTelemetry.

Limitations. It is built for one machine or one team, not an organisation: there is no RBAC, no per-user identity and no LLM routing. Call logs record tool names and argument shape but not values, so they are not an audit trail. Docker’s documentation describes the governance offering built on it as invite-only.

Best fit: developers and small teams who want MCP servers isolated on laptops, ideally paired with a central gateway for production traffic.

Two that missed the cut

Microsoft MCP Gateway is an MIT-licensed reverse proxy for running MCP servers on Kubernetes, with Entra ID app roles governing who can read or write each adapter. It has no tagged releases, now accepts only 2026-07-28 clients with no downgrade path, and documents no guardrails or audit log beyond pod logs, which puts it behind Azure API Management for most Microsoft shops.

Agent Router, formerly Envoy AI Gateway and now an Agentic AI Foundation project, added an MCPRoute resource in v0.4 in November 2025. It aggregates servers over Streamable HTTP, filters tools by name or regex, validates OAuth tokens with JWKS and emits OpenTelemetry and Prometheus data alongside LLM traffic. It is a strong option for teams already on Envoy Gateway, but the documentation we read describes no audit log or tool-call guardrails.

What actually differs between MCP gateways

Feature lists across these ten products overlap heavily. Five dimensions separate them in practice.

Whose identity reaches the upstream server

This is the single biggest difference. A gateway that holds one admin token per upstream server gives every agent the union of everyone’s access. Bifrost, AgentCore, Cloudflare and MintMCP document per-user upstream credentials; Bifrost and AgentCore also document token exchange, where the caller’s identity-provider token is exchanged per call and nothing is stored. Kong takes the opposite, also defensible, position of validating inbound OAuth 2.1 tokens strictly and refusing to pass them through. Azure API Management and ContextForge sit in between.

Whether policy can see arguments

Every gateway here can hide a tool. Far fewer can say “allow github.create_issue but block it when the body contains a secret”, which is what stops the injection patterns that arrive through tool arguments and results. Bifrost’s guardrails, AgentCore’s interceptors and Cedar policies, agentgateway’s guardrails, ContextForge and Obot plugins, MintMCP rules and Docker’s secret scanning all reach into the payload to some degree. Kong and Azure API Management, as documented, do not.

One identity for models and tools, or two

Bifrost, agentgateway, AgentCore and Obot route model calls as well as tool calls. That matters more than it first appears: the AI guardrails that redact PII from prompts should be the same ones that inspect tool results, and the budget that caps an agent’s model spend should belong to the same key that limits its tools. A separate MCP gateway means two policy stores and two audit trails to reconcile.

Where the record lives and who can read it

Audit has two layers: tool-call logs and administrative change logs. Bifrost’s enterprise audit log is the most explicit about integrity and export, with HMAC signing and Syslog output; AgentCore relies on CloudTrail; Cloudflare’s logs show server, tool and duration, with SIEM export on Enterprise plans. For observability beyond audit, Bifrost’s gateway-level observability puts MCP tool calls, with duration, failure rate and server attribution, beside LLM token spend under the same virtual key, and exports OpenTelemetry traces and Prometheus metrics.

What a gateway cannot see

A central gateway only governs traffic configured to reach it. MCP servers added to Claude Code or Cursor on a laptop run as local subprocesses and never pass through any gateway in this list. Docker isolates them locally, but does not report them centrally. Bifrost addresses the gap with Bifrost Edge, an endpoint agent that runs on macOS, Windows and Linux, deploys through MDM tools such as Jamf, Intune and Kandji, and routes desktop, browser, coding-agent and MCP traffic through the gateway. Its MCP governance builds a fleet-wide inventory of configured MCP servers and enforces allow or deny decisions on the device, so the same governance and security controls set at the gateway (virtual keys, guardrails, audit) extend to employee machines. Our piece on shadow AI governance covers the wider problem.

Capability matrix

Recommendations keyed to constraints

Figure 2: One constraint usually narrows the field to two or three gateways before features matter.

• Your agents act on customer data and nothing may leave your network. Self-host. Bifrost is the strongest fit, because its per-user auth, deny-by-default tool lists, tool-call guardrails and signed audit logs cover the controls a regulator will ask about, and it routes the agents’ model traffic too. agentgateway is the open-source alternative if your platform team prefers CEL policy on Kubernetes; ContextForge if federation of internal APIs is the main job.
• You are committed to AWS. AgentCore Gateway, budgeting engineering time for interceptor Lambdas if you need parameter-level policy.
• You run Cloudflare One. MCP server portals give employees governed access to remote servers in an afternoon. Plan for the 80-server limit and the Access controls that do not apply to portals.
• You already pay for Kong Enterprise. Use Kong, and add a separate guardrail layer for tool calls, since the MCP proxy does not integrate AI guardrails.
• You are an Azure shop exposing REST APIs to agents. Azure API Management, splitting servers where tools need different policies.
• You need a self-hosted MCP catalogue for a few hundred users. Obot, after checking the edition limits.
• Your immediate problem is coding agents on laptops. MintMCP for a managed route, or Docker MCP Gateway to isolate servers locally, combined with an endpoint agent so the servers are visible centrally.

The judgement

We think the MCP gateway market has split along a single line: whether the gateway treats tools and models as one governed path or as separate problems. The cloud and API-platform entries are good at the part of the problem their parent products already solved, identity in AWS, Access in Cloudflare, routes in Kong, and weaker at the MCP-specific part: per-user upstream identity and inspection of individual tool calls. Bifrost ranks first because it does both halves in one place, under one key, on infrastructure you control, and publishes the numbers to check its overhead.

Teams shortlisting gateways can read the Bifrost MCP gateway documentation, request a Bifrost demo, or browse the wider product at getmaxim.ai. Whatever you choose, test it against the one question that matters: when an agent calls a tool it should not, which layer stops it, and what record does that leave?

Feature claims are drawn from public documentation and vendor announcements as of October 2026; check current docs before deciding.