MCP Gateway Vendor Landscape for Enterprise Environments

An MCP gateway gives you one governed entry point, so AI agents can connect to internal tools, APIs, and data systems through the Model Context Protocol, instead of each agent and each tool negotiating its own one-off integration. It solves two problems at once: it gets tools in front of agents, and it decides, on every single call, who that agent is and what it's allowed to touch. That second job is what moved the gateway out of the developer's toolkit and onto a procurement officer's desk. MCP itself has no built-in authentication, rate limiting, audit logging, or access control. Every one of those gaps gets filled at the gateway layer. Whoever picks the gateway is deciding, by default, how the whole organization will answer to auditors, regulators, and its own security team.

MCP shipped as an Anthropic open-source release in November 2024. By December 2025, it had moved to Linux Foundation governance, donated to the Agentic AI Foundation, a directed fund co-founded by Anthropic, Block, and OpenAI. That transfer matters because it cemented MCP as a vendor-neutral standard that no single company controls, and vendor-neutrality is what got every major AI vendor to support the protocol. An enterprise can swap LLM providers today without rewriting its tool integrations, a flexibility that was never available when every vendor shipped a proprietary plugin format.

That speed created a governance problem nobody priced in up front. The naive way to wire agents to tools, every agent talking directly to every tool it needs, produces what practitioners call the N×M problem: N agents each maintaining their own connections to M tools, with no shared point of control. A gateway collapses that sprawl into one perimeter. The category started with teams shipping MCP servers as a feature of their own product. The growth in 2026 is in governing how employees use MCP across an entire company, and a thousand employees running personal MCP configs is functionally the same governance problem as a thousand employees running personal SaaS accounts, except these connections read and write production systems directly. Vendor reputation or feature count isn't what you should buy a gateway on. Which gateway fits the organization's federation reach, identity surface, compliance posture, and observability requirements is the decision that matters, and that's the frame the rest of this piece uses.

The five procurement criteria that differentiate gateway vendors

Every serious MCP gateway evaluation converges on the same five questions, regardless of which vendor is in the room. The order in which a buyer weighs them shifts depending on whether the organization is a three-cloud enterprise or a single-team startup, but the questions themselves hold steady across profiles.

Federation reach asks whether the gateway can govern MCP traffic across AWS AgentCore, Azure AI Foundry, Cloudflare, and self-hosted servers, or whether it stops at the edge of one provider's cloud. If you run a single-cloud shop, you can legitimately choose a single-cloud gateway. It becomes a liability only when the buyer doesn't know where that boundary sits before signing.

Auth conformance asks whether the vendor has actually implemented the current protocol specification: OAuth 2.1 with PKCE (PKCE is defined in RFC 7636; OAuth 2.1 itself remains an active IETF draft, not yet a ratified RFC), resource indicators under RFC 8707, and Protected Resource Metadata under RFC 9728. The MCP authorization specification requires that MCP servers implement RFC 9728 and that MCP clients implement RFC 8707. A vendor sitting a full revision behind on auth will fail security review no matter how polished the rest of the product looks.

Identity propagation asks whether on-behalf-of identity survives nested tool calls, and whether the gateway consumes IdP groups directly through SAML, OIDC, or SCIM rather than maintaining a parallel role system that drifts out of sync with the directory within a quarter.

Audit granularity asks whether the gateway logs tool-level records at the level of the resolved tool, the resolved arguments, the resolved result, and the policy snapshot that authorized the call.

Revocation timing asks how fast access changes actually take effect: whether a revoked credential or a deprecated agent version is locked out on the very next call, or only after some sync interval elapses. This is the criterion that separates a real-time policy engine from one that's merely eventually consistent, and it's often the one buyers discover too late, during an incident rather than a demo.

Federation reach: how far a gateway's policy surface extends

Federation reach is the first criterion to evaluate because it constrains every decision that follows it. If you pick a gateway whose policy surface stops at one cloud boundary, then identity propagation, audit granularity, and revocation timing all inherit that same boundary. The market has settled into three deployment shapes: hyperscaler-native gateways built into AWS and Azure, edge-native gateways built by Cloudflare, and platform-native gateways designed to federate across all of them.

On the hyperscaler-native side, AWS AgentCore Gateway converts OpenAPI, Smithy, and Lambda endpoints into MCP-compatible tools. It handles both inbound and outbound OAuth with per-target credential injection, and it accepts JWTs from any OIDC provider for inbound authentication. Microsoft's answer is Foundry Agent Service, which gives each agent a Microsoft Entra identity, dedicated per agent for Hosted agents, shared at the project level for unpublished prompt agents, supports OAuth on-behalf-of passthrough, and republishes a curated tool set through a single MCP-compatible Toolbox endpoint. Both are capable products within their own walls. Neither sees past them: if a developer plugs an open MCP tool straight into Cursor outside the cloud boundary, neither AWS nor Microsoft's gateway has any visibility into that connection.

Cloudflare's MCP Server Portals take the edge-native route, which suits distributed teams with tight latency requirements and MCP servers already running close to the edge. Cross-cloud federation runs through Cloudflare's own network, but whether it bridges cleanly to an enterprise identity provider depends on how you deploy it.

You need platform-native gateways for multi-cloud and hybrid environments, where a single policy surface has to span several providers at once, and that architecture holds up even after you add a third cloud provider to the mix. Speakeasy operates in this shape as an AI control plane: a single governed layer connecting AI to internal and external systems regardless of which cloud or LLM provider the agent runs on, enforcing policy across the full footprint, including outside any one provider's perimeter.

The open-source and DIY shape rounds out the landscape. Kong's AI MCP Proxy plugin turns existing REST APIs into MCP tools without writing separate MCP server code, and it carries over Kong's existing OpenID Connect, auth, rate-limiting, and logging plugins to MCP endpoints exactly as they apply to ordinary APIs, a sensible first move for teams already standardized on Kong. Bifrost takes a different approach: it keeps MCP servers as long-lived subprocesses that talk over stdio instead of HTTP, so there's no connection overhead, and that fits workloads where latency matters most and servers already share a machine or cluster with the agents calling them. DIY shapes work well if your team has strong platform engineering and a narrow, well-understood scope. They tend to buckle under the audit demands of a compliance review, which is a different kind of pressure than uptime or latency.

Sorting vendors by federation reach before comparing a single feature saves a later migration headache. If you have a single-cloud deployment, picking a single-cloud gateway is a defensible decision. But if nobody confirms where that same gateway's boundary sits, it turns into an expensive rebuild the day a second cloud provider shows up.

Auth conformance and identity propagation: why IdP-tied identity is the security floor

If you think an existing API gateway already handles authentication, you're missing what's different about MCP traffic. An API gateway authenticates a request. An MCP gateway has to resolve identity at the level of the individual tool call, including the calls an agent makes to other tools on its own initiative, and that identity has to survive however many layers of nested delegation the agent chain introduces. Request-level auth answers "who sent this HTTP call." Tool-level identity propagation answers "who is this agent acting on behalf of, three tool calls deep into a chain it initiated itself," and that's a materially harder problem.

A gateway-local identity, a key, a Consumer record, a virtual key that only exists inside the gateway's own database, works fine for a proof of concept and turns into a liability the moment someone leaves the company. Revoking a person from the corporate directory does nothing to the key that person's agent was issued, because the key was never tied to the directory.

The design that avoids that failure is broker mode. The user authenticates once to the gateway through the IdP, and for each upstream system the gateway brokers credentials on the user's behalf: per-user OAuth where the upstream supports it, a shared service account where it doesn't, or an encrypted vault entry for upstreams that issue per-user API keys. The credential stays encrypted server-side, keyed to the user's gateway identity, and is never handed back to the MCP client. Pass-through token forwarding, taking the user's OAuth token straight from the MCP client and forwarding it to the upstream, looks like the fast path on day one. By month three, it means every upstream MCP vendor is sitting on credentials minted by the enterprise's own identity provider, with no gateway standing between them and the directory.

Current vendors resolve identity in noticeably different ways. Willow places SSO and SCIM upstream of its own gateway, mints its own tokens, and matches each call back to a Willow user record. Kong resolves identity to Kong Consumers. LiteLLM resolves to virtual keys. Bifrost resolves to virtual keys as well, with OIDC and SCIM support arriving in its Enterprise tier. AWS AgentCore Gateway accepts JWTs from any OIDC provider for inbound auth. Each of those designs handles offboarding differently, and only the approaches that bind directly to the enterprise directory can revoke access cleanly the moment the directory says to.

The MCP protocol's own roadmap names agent identity as a priority for a reason: cloud-based autonomous agents acting as callers expose the limits of MCP's current model, where servers still lean on pasted API keys and long-lived tokens rather than any standardized pattern for agent identity and delegation. The protocol maintainers answered part of that gap in mid-2026, when they promoted Enterprise-Managed Authorization (EMA) to stable status. EMA gives organizations a centralized way to control access through their own IdP, using an Identity Assertion JWT Authorization Grant (ID-JAG) exchanged for an access token. Anthropic adopted it across Claude, Claude Code, and Cowork; Microsoft adopted it in Visual Studio Code; Okta became the first identity provider to support it. EMA governs access to servers. It is not runtime authorization for individual actions, so organizations still need their own controls for what an agent does once it's already inside a system.

Speakeasy's approach to this problem is to enforce RBAC and identity through the providers organizations already run, Okta, Entra ID, SAML, and OIDC, rather than standing up a second, parallel role system that has to be kept in sync by hand. At enterprise scale, you can't match access policy to the directory that's actually authoritative any other way. Session length is the dimension buyers tend to skip and shouldn't: a gateway needs a maximum session duration and a way to force re-authentication, because a gateway that allows indefinitely long sessions against a short-lived directory credential has created the functional equivalent of an API key that never expires.

Capability-level access control: why per-server RBAC is too coarse for production

Identity answers who the gateway recognizes. Access control answers what that identity can do, and a yes/no switch at the server level can't express the distinctions regulated workflows need. The Stripe MCP server exposes create_charge, refund_create, retrieve_balance, and roughly a hundred other tools. If a finance analyst needs read-only access, they should see retrieve_balance and nothing else. An engineer with no finance responsibilities shouldn't see Stripe. Per-server access control has exactly one lever to pull for both of those people, and it's the same lever.

Give teams nothing finer than that switch, and they build their own workaround: shadow MCP servers, hand-rolled and maintained outside any central gateway, each exposing a narrower slice of tools to a narrower audience. A gateway was supposed to eliminate that sprawl, and here it gets rebuilt quietly beside it.

Several vendors have built tooling specifically to close that gap. Zuplo's capability filter lets an administrator specify exactly which tools, prompts, resources, and resource templates a given route exposes. Anything left off that list is blocked, and a hidden tool returns MethodNotFound, a clear signal rather than an ambiguous failure that leaves a user guessing whether the tool exists. Lunar MCPX runs policy at three separate levels: global, across every server; per-service, scoped to one server; and per-tool, scoped to an individual function. That structure supports rules with real operational texture, such as letting every agent list files, restricting delete permissions to admin agents only, and walling off the production database server from any agent whatsoever.

The virtual server pattern solves the same underlying problem from the opposite direction, curating what gets distributed, and a virtual MCP server is a scoped view of one upstream system, exposing only a selected set of tools, prompts, and resources, served behind its own dedicated gateway URL with its own authentication. An engineering team ends up with a purpose-built virtual server for each upstream it touches, with all of them governed from the same gateway. TrueFoundry's "Finance Agent Virtual Server" combines a BigQuery query tool, a Stripe exchange-rate lookup, and a Slack alert tool into one endpoint. Swap the implementation behind any one of those tools later; the agent code calling the virtual server never has to change.

Audit granularity and revocation timing are what separate a gateway that merely claims real-time enforcement from one that delivers it. Per-call records naming the resolved tool, the resolved arguments, the resolved result, and the policy snapshot that authorized the call are what let a security team confirm, after the fact, that governance happened on every single transaction rather than existing only as a line item in a sales deck. Platforms built around that standard, Speakeasy among them, exist precisely because "we have an access control policy" and "we can prove which policy authorized this specific call, three weeks later, to an auditor" are two very different claims, and only a gateway logging at the tool level can back up the second one.