The best MCP gateways in 2026, compared on security and control

TL;DR

• An MCP gateway sits between MCP clients and MCP servers, aggregating tools behind one endpoint and enforcing authentication, per-consumer tool access and logging on every tool call.
• The MCP specification makes authorization optional, forbids token passthrough and says tools “represent arbitrary code execution”; the useful test for a gateway is how much of that it enforces for you.
• Bifrost ranks first here because one process governs both model calls and tool calls with the same virtual keys, supports inbound OAuth 2.1 and six outbound auth types, and denies MCP tools by default to keys that have not been granted them.
• Docker MCP Gateway, IBM ContextForge, Microsoft MCP Gateway, Kong, Cloudflare, agentgateway, LiteLLM and Amazon Bedrock AgentCore Gateway each fit a narrower deployment: developer laptops, API estates, Kubernetes, a Zero Trust network or a managed AWS stack.
• The current MCP revision (2026-07-28) removes protocol-level sessions, which changes how much session-affinity routing a gateway needs.

An MCP gateway is a proxy that sits between the applications that call tools over the Model Context Protocol and the MCP servers that provide those tools, so that authentication, tool permissions and logging are enforced in one place instead of in every client. Choosing the best MCP gateway comes down to how much of the protocol’s security guidance a product enforces, and whether it also governs the model traffic that decides which tools get called. This comparison covers nine options, from Bifrost, an open-source AI gateway written in Go by Maxim AI that handles LLM and MCP traffic in one process, to container-based, Kubernetes-native and managed alternatives. Every capability below comes from each vendor’s own documentation or repository as of September 2026; none of the products were run under load for this piece.

What an MCP gateway does

An MCP gateway terminates MCP connections from clients, holds connections to many upstream MCP servers, and presents their tools as one catalog. On the way through, it decides which caller may see and call which tool, attaches the right upstream credential, and records the call.

The MCP specification describes three roles: hosts (LLM applications such as an IDE), clients (connectors inside the host) and servers (services that provide tools, resources and prompts). Without a gateway, every host keeps its own list of servers, its own copies of API keys and its own idea of which tools are safe, and nobody holds a shared record of what ran.

A gateway changes that arrangement in four ways:

• Aggregation: clients point at one endpoint and discover tools from every upstream server behind it.
• Identity and access: the gateway authenticates the caller and filters the tool list to what that caller is allowed to use.
• Credential custody: upstream API keys and OAuth tokens live in the gateway, not in each client’s configuration file.
• Visibility: every tools/call passes one point where it can be logged, rate-limited or blocked.

What the MCP specification asks for

The specification’s security guidance is the most useful yardstick for an MCP gateway, because it says plainly which controls are optional and which are forbidden. Authorization is optional, tool safety is left to implementers, and passing a client’s token straight through to a downstream API is prohibited.

The authorization chapter opens with “Authorization is OPTIONAL for MCP implementations.” When an HTTP-based server implements it, the server acts as an OAuth 2.1 resource server, publishes Protected Resource Metadata (RFC 9728) and validates that tokens were issued for it as the audience; clients send a resource parameter (RFC 8707) and use PKCE. The chapter also states: “MCP servers MUST NOT accept or transit any other tokens.”

The Security Best Practices document names the attacks that matter for anything in the middle:

The specification’s overview adds the principle that underlies all of it: “Tools represent arbitrary code execution and must be treated with appropriate caution,” and “Hosts must obtain explicit user consent before invoking any tool.” It also concedes that MCP “cannot enforce these security principles at the protocol level,” which is the gap MCP gateways fill.

One recent change affects gateway design directly. The 2026-07-28 revision, which the versioning page lists as current, removes protocol-level sessions and the initialize handshake. Session-affinity routing matters less for servers on the new revision, though many deployed servers will speak older revisions for some time.

How an MCP gateway relates to an AI gateway

An LLM gateway governs traffic to model providers; an MCP gateway governs traffic to tools. The two meet inside the agent loop, where a model proposes a tool call, the tool runs, and the result returns to the model. Running both in one process lets one key carry model and tool permissions together.

The LLM side of that loop is covered in the Frontier Wire explainer on running an AI gateway in front of every model call, and in the distinction between an LLM gateway and an API gateway. For the model-routing products themselves, Maxim’s ranking of production AI gateways scores five of them on overhead, failover, governance and MCP support.

The practical question is whether tool and model permissions live in the same place. When they are separate, a key limited to a cheap model can still drive an agent that calls a database tool with no budget attached. When they are combined, one key can say “this team may use these models, spend this much, and call these twelve tools.” Bifrost, agentgateway, LiteLLM and Amazon Bedrock AgentCore Gateway offer versions of the combined model. Teams that want to run the model half on their own infrastructure can compare open-source LLM proxies and gateways that are built for self-hosting.

MCP gateway evaluation criteria

The criteria below follow the specification’s security guidance and the operational questions that come after it. They are published before the ranking so readers can weight them differently.

The last criterion is easy to underrate: every visible tool definition is sent to the model on each turn, the same cost dynamic described in the piece on reasoning-model inference costs. Readers weighing the model-side criteria can use an AI gateway scorecard built around overhead and failover alongside this table.

MCP gateways compared at a glance

The table ranks nine MCP gateways on the criteria above. Bifrost is first because it covers every row, including the combined LLM and MCP policy; the others are ordered by how broadly they cover the criteria for a general team.

Bifrost

Bifrost acts as both an MCP client, connecting to upstream servers over STDIO, HTTP or SSE, and an MCP server that exposes the aggregated tools at a single /mcp endpoint. The same process routes model requests to 20+ providers, so one virtual key governs models, budgets and tools.

The design choice that stands out in the MCP documentation is that Bifrost does not execute tool calls automatically by default. On the LLM path, a model’s tool calls come back as suggestions; the application reviews them and calls a separate execute endpoint. That default matches the specification’s consent principle more closely than gateways that run whatever the model asks for.

Authentication in both directions

Inbound, a client can present a virtual key in a header, or connect through a browser flow in which Bifrost acts as an OAuth 2.1 authorization server for /mcp. That flow implements Protected Resource Metadata (RFC 9728), Dynamic Client Registration (RFC 7591), PKCE with S256, and resource indicators (RFC 8707) that bind the token’s audience to /mcp, which lines up with the specification’s authorization chapter. A setting chooses whether /mcp accepts headers, OAuth tokens or both, and a request carrying both is rejected.

Outbound, Bifrost supports six auth types for upstream servers: none, static headers, admin OAuth with automatic refresh, per-user OAuth, per-user headers, and token exchange. Per-user types store a credential against the caller’s identity and send a consent link the first time a tool needs it. Token exchange, an enterprise feature, swaps the caller’s identity-provider token for a short-lived token scoped to the upstream server on each call, so “the caller’s original token never is” sent upstream. That is the specification’s no-passthrough rule implemented as a feature.

Tool filtering per virtual key

MCP tool filtering is deny-by-default: a virtual key with no MCP configuration sees no MCP tools, except from servers an administrator marks “Allow by Default.” A request header can narrow the allowed tools but never widen them, the allow-list is checked again at execution time, and inactive or expired keys get a 403. Virtual MCPs go one step further: an administrator bundles selected tools from several servers into an endpoint at /mcp/<slug>, reachable only through the keys attached to it. Virtual MCPs are part of the open-source gateway; enterprise adds access profiles, data access control and cluster propagation.

Agent mode and code mode

Agent mode lets Bifrost run the tool loop itself, but only for tools listed in tools_to_auto_execute, which must be a subset of the tools the client may use. Everything else is returned for approval, and the loop stops at a configurable maximum depth. Agent mode does not work with streaming responses.

Code mode addresses tool-catalog bloat. Instead of sending every tool definition to the model, it exposes four meta-tools; the model reads tool stubs on demand and writes a short Python (Starlark) script that Bifrost runs in a sandbox, so intermediate results stay out of the context window. In Bifrost’s own benchmark, input tokens fell 58.2 percent with 96 tools across six servers and 92.8 percent with 508 tools across 16 servers, with pass rates at or above the classic mode’s. Those are vendor-reported figures from a vendor-designed query set. The MCP gateway resource page summarizes the same results.

Logging, audit and performance

Bifrost keeps LLM and MCP log entries and can attach request headers to them as metadata. Signed audit logs of administrative changes, SSO, RBAC, clustering and guardrails are enterprise features. The gateway’s published benchmark reports 11 µs of added overhead per request at 5,000 requests per second on a t3.xlarge against a mocked OpenAI upstream; that measures the LLM path, not MCP tool calls.

Best for: organizations that want one control point for the whole agent loop, with tools, models, budgets and credentials governed by the same keys, open-source code they can self-host, and an OAuth implementation that follows the MCP authorization model. For teams running their own LLM gateway on-premises already, it removes the need for a second proxy for tools.

Open-source MCP gateways

Four other open-source projects cover much of the same ground as Bifrost, each built around a different deployment assumption: containers on a developer machine, federation of existing APIs, Kubernetes networking, or a Python LLM proxy.

agentgateway

agentgateway is a Rust proxy under Apache 2.0 and a Linux Foundation project. It combines an LLM gateway, an MCP gateway with tool federation across stdio, HTTP, SSE and Streamable HTTP, OpenAPI-to-MCP conversion, and agent-to-agent (A2A) routing. Security features include JWT, API key and OAuth authentication, fine-grained RBAC through a CEL policy engine, rate limiting and OpenTelemetry. It runs standalone from YAML or on Kubernetes through its Gateway API controller.

Best for: platform teams already on Kubernetes who want MCP, A2A and model traffic handled by infrastructure-style policy.

IBM ContextForge

ContextForge, from IBM, is a Python registry and proxy under Apache 2.0 that federates MCP servers, A2A agents and REST or gRPC APIs behind one endpoint. Its distinguishing feature is virtualization: it wraps REST and gRPC services as MCP tools, and it lets administrators bundle chosen tools into “virtual servers.” The README lists auth, retries and rate limiting with user-scoped OAuth tokens, RBAC, an admin UI with air-gapped support, OpenTelemetry, and Redis-backed multi-cluster federation.

Best for: enterprises with large estates of internal APIs to expose as tools without writing new MCP servers.

Docker MCP Gateway

Docker MCP Gateway is an MIT-licensed Go plugin for the Docker CLI and the engine behind Docker Desktop’s MCP Toolkit. It runs each MCP server in its own container, which Docker’s documentation describes as having “restricted privileges, network access, and resource usage.” Secrets stay in Docker Desktop’s secret store, servers are grouped into profiles that can be shared through OCI registries, tools can be allowlisted per profile, and calls are logged and traced.

Best for: developer workstations, where the specification’s warning about local server compromise is most relevant and container isolation is the main control.

LiteLLM

LiteLLM, the Python LLM proxy, includes an MCP gateway supporting Streamable HTTP, SSE and stdio. Permissions to MCP servers can be managed by key, team or user, upstream OAuth supports both authorization-code and client-credentials flows, and MCP usage feeds its cost tracking. SSO, audit logs and guardrails sit in its enterprise tier.

Best for: teams already standardized on LiteLLM that want basic MCP permissions under the same keys. The trade-offs of that proxy are covered in the review of LiteLLM alternatives. A broader set of open-source gateways for LLM traffic is worth reading alongside it.

Managed and platform MCP gateways

Four products add MCP gateway features to a platform a team may already run: an API gateway, a Zero Trust network, a Kubernetes cluster on Azure, or AWS. Their MCP features are strongest when that platform is already in place.

Kong AI Gateway

Kong added MCP through two plugins in Kong Gateway 3.12, both limited to its AI Gateway Enterprise offering. The AI MCP Proxy plugin either proxies existing MCP servers or converts REST API paths into MCP tools, and it supports per-tool ACLs that allow or deny consumers and consumer groups, with every access attempt written to an audit log. The companion AI MCP OAuth2 plugin makes Kong the OAuth resource server for MCP traffic and rejects invalid tokens with a 401.

Best for: organizations that already manage their APIs in Kong and want existing endpoints exposed as governed tools. Enterprise-grade LLM gateways include Kong on the model side as well.

Cloudflare MCP server portals

Cloudflare’s MCP server portals put multiple MCP servers behind one HTTP endpoint protected by Cloudflare Access. Administrators curate which tools and prompts each portal exposes, tools are namespaced by server ID, and a code mode collapses upstream tools into search and code-execution tools running in an isolated Worker. Requests are logged through Access, and routing through Cloudflare Gateway adds HTTP logging and DLP scanning. The documentation lists limits: up to 80 servers per portal, and independent MFA and purpose justification are not enforced for servers authorized through a portal. Portals use the stateless 2026-07-28 protocol where upstream servers support it.

Best for: companies already on Cloudflare One that want MCP access tied to their existing identity policies.

Microsoft MCP Gateway

Microsoft MCP Gateway is an MIT-licensed C# reverse proxy for MCP servers running in Kubernetes. It routes all requests with a given session ID to the same server instance using StatefulSets, exposes control-plane APIs to deploy servers and register tools, authenticates with Entra ID, and applies role-based permissions. Its agents and sessions subsystem is marked preview and single-replica only. Because the current specification revision drops protocol-level sessions, its session-affinity design matters most for servers that stay on earlier revisions.

Best for: Azure-centric teams that host their own MCP servers on AKS.

Amazon Bedrock AgentCore Gateway

AgentCore Gateway is a fully managed AWS service that turns OpenAPI, Smithy and Lambda targets into MCP tools, fronts other agents, and routes model requests across providers. It handles inbound authentication and outbound credential injection, offers semantic tool search so agents can find tools without loading every definition, and includes observability and auditing.

Best for: teams building agents on AWS that prefer a managed service to operating a proxy.

MCP servers on employee machines

A server-side MCP gateway only governs clients configured to use it. Developers also add MCP servers directly to Claude Desktop, Cursor or a coding agent on their own laptops, and those connections never reach the gateway. The specification’s section on local server compromise describes exactly this risk.

Bifrost addresses it with Bifrost Edge, an endpoint agent currently in alpha that extends the gateway’s controls to company machines. The gateway remains the control plane where virtual keys, budgets, guardrails and audit logs are defined; Edge routes AI traffic from desktop apps, browser AI and coding agents on each device through it. For MCP specifically, Edge MCP governance reads the MCP configuration inside supported apps (Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex and Cursor), builds a fleet-wide inventory, sends newly found servers to an approval queue, and enforces allow or deny decisions on the device, so a denied server cannot be used even by an app that was configured with it earlier.

The same routing means endpoint guardrails such as secrets detection apply to prompts leaving the laptop. None of the other gateways here documents an endpoint component; the closest is Docker’s container isolation for servers launched through its toolkit. The Bifrost governance page summarizes the policy model. As an alpha, Edge is something to pilot, not yet a compliance control.

Choosing an MCP gateway by deployment

Most teams can narrow the field by where tool traffic is allowed to go and which platform they already run. The table maps common starting points to the first product to evaluate.

For a regulated team, the questions to ask any vendor are the specification’s own: does the gateway validate token audience, does it refuse to pass client tokens upstream, does it deny unknown tools by default, and can it prove who called what. Where the same team also routes model traffic, a list of top-rated LLM routing gateways covers that half. Teams with data-residency requirements can compare AI gateways deployable in a private VPC that keep tool arguments and results inside their own network.

Verdict

Bifrost is the strongest general-purpose MCP gateway in this comparison because it is the only open-source option that pairs a standards-based OAuth 2.1 flow for MCP clients, delegated and per-user credentials for upstream servers, deny-by-default tool access per virtual key and a full LLM gateway in the same process. Code mode addresses the token cost of large tool catalogs, and the Bifrost Edge alpha extends the same governance to MCP servers on laptops.

The alternatives are credible within their niches. agentgateway is the closest open-source peer for Kubernetes teams, ContextForge for API-heavy enterprises, Docker for developer machines, and Kong, Cloudflare, Microsoft and AWS for teams committed to those platforms.

The limits of this comparison are worth stating. Capabilities come from vendor documentation and repositories read in September 2026; no gateway was deployed, load-tested or penetration-tested, and no vendor benchmark was reproduced. License tiers and supported specification revisions shift between releases, and tool filtering does not solve prompt injection, since a permitted tool can still return text that redirects the model. Pricing was not compared.

Teams evaluating an MCP gateway can request a Bifrost demo or read the Bifrost MCP gateway overview, which links to the code-mode benchmark data.