Evaluating MCP Gateway Vendors for Enterprise Needs

When you evaluate MCP gateway vendors for enterprise needs, you shouldn't just compare features. It is a governance requirements exercise, and the requirements come from one fact: MCP itself leaves authentication, access control, audit logging, and identity management unresolved at the protocol level. If you want to stop shadow AI without slowing developers down, you close those four gaps first and pick a vendor second. If you reverse that order, you end up comparing dashboards instead of closing gaps, and that's the mistake behind most stalled agentic AI programs.

MCP's governance vacuum

So they built a shared, open protocol, one that let AI agents call tools and reach data sources through a common standard. That design choice solved a real integration problem, but it left four structural gaps that no amount of good intention closes on its own: authentication, access control, audit logging, and identity management. These are the result of a protocol built to standardize connections, not to govern who holds them.

Take authentication first. The MCP specification treats authorization as optional, and even where an HTTP-based server implements it, the spec only recommends OAuth 2.1. As of early 2026, only a small fraction of deployed servers implement that OAuth 2.1 recommendation, so most enterprise environments run against an unguarded attack surface at the protocol layer itself, because the protocol never forced the issue.

The protocol's own stewards know this. The MCP 2026 roadmap names four gaps it has not yet closed: structured audit trails with SIEM and APM integration, enterprise-managed auth with SSO-integrated flows, gateway and proxy patterns covering authorization propagation and session affinity, and configuration portability across clients. In early 2026, security researchers cataloged thousands of internet-exposed MCP servers, and about half had no authentication controls. Between January and February 2026, researchers filed a significant wave of CVEs against MCP servers, clients, and infrastructure, including one finding with a critical CVSS score affecting a very large number of installed environments. None of this traces back to sloppy engineering. It traces back to a protocol that never made these controls mandatory. Every organization deploying MCP at scale inherits the job of building them.

Why enterprise MCP programs stall between pilot and production

The governance gaps described above are the main reason agentic AI pilots don't make it to production. Model capability isn't the holdup, and developer appetite isn't either. The holdup is structural: without a control layer sitting between agents and the tools they call, nobody can answer the questions a production sign-off demands.

Who is acting on a given tool call? What did the agent actually touch? Can access be shut off the moment someone leaves the company? What does the audit log show when a regulator or a security team asks? These aren't bureaucratic hurdles invented to slow teams down. Any compliance review asks these baseline questions before it lets an AI agent near production data, and MCP's native protocol gives you no way to answer them.

Without a central governance layer, you have no inventory of which MCP servers are even in use across the organization. Long-lived tokens sit in plaintext configuration files, unrevokable from any central point. No audit trail exists to show what happened after a tool call fired. No cost attribution ties spend back to the team or agent that generated it. Teams that skip governance to hit a pilot deadline discover these holes during security review, and then they have to rebuild from the ground up, which costs more time than building the controls in from day one would have. That's the trap: move fast now, pay for it twice later.

What a requirements-first evaluation looks like

Before you let any vendor into the room, you need a written answer to four questions, each one tied directly to a gap named above. If you skip this step, the evaluation turns into a features bake-off that measures criteria unrelated to stopping shadow AI.

Authentication is the first question: does every tool call resolve to a real identity drawn from the organization's directory, or does it resolve only to a key that lives inside the gateway? If someone leaves the company, a gateway-local principal becomes a liability, because the gateway keeps its own key in its own store, untouched when you revoke that person's directory account.

Access control is the second: can the gateway enforce which tools a given role, team, or individual agent is allowed to call, and does it enforce that at every tool invocation? Least-privilege enforcement at the level of the individual tool call is what separates a real control plane from a pass-through proxy wearing a dashboard.

Audit logging is the third: does the gateway produce a per-call record showing caller identity, tool name, the arguments passed, and the result returned, and does that record export into the SIEM and APM systems the organization already runs? A log that lives only inside the gateway's own interface, with no path out to existing security infrastructure, falls short of a usable compliance audit trail.

Identity management is the fourth: does the gateway federate identity with the organization's existing identity provider, whether that's Okta, Entra, Google Workspace, SAML, or SCIM, or does it maintain its own separate user store? Per-user OAuth passthrough, where an agent acts downstream using the actual end user's identity rather than a shared bot account, is a harder requirement than basic federation and should be checked for explicitly.

Two more requirements belong in the evaluation even though they tend to appear only after deployment starts. Deployment model, covered in the next section, should act as a hard filter, not just a feature you weigh against others. And MCP-specific threat handling, including rug-pull protection, tool poisoning detection, and cross-server shadowing, addresses attack patterns that standard API gateways were never built to catch. Token-cost management belongs on this list too: large tool catalogs bloat the context window an agent has to work with, and that's now a gateway-layer problem to solve, not something to leave to the model.

When evaluating gateways against these four criteria, the central question is whether identity federation runs through a centralized registry that can be revoked the moment someone leaves, because identity management built on distributed keys or gateway-local principals turns into a compliance liability on day one of an offboarding, and that liability alone should rule out a vendor no matter how the rest of its feature set stacks up.

How deployment model and isolation architecture narrow the field

Deployment model isn't a preference to weigh against other preferences. If your organization operates under data-residency or sovereignty rules, this is a hard constraint, and it removes most vendors from consideration before you compare a single feature.

The deployment spectrum runs from fully managed SaaS, through in-VPC self-hosted, to on-premises and air-gapped. These aren't interchangeable points on a continuum. A fully managed SaaS gateway keeps all configuration and audit history inside the vendor's own infrastructure, so if you leave that vendor, you rebuild the entire tool catalog from scratch, and that cost grows the longer you've used it.

The research gives concrete shape to this range. Willow deploys as SaaS, self-hosted on AWS, GCP, or Azure, or fully on-prem and air-gapped. Bifrost runs in-VPC deployments across AWS, GCP, Azure, Cloudflare, and Vercel, and at its Enterprise tier ships private container images for AWS, GCP, Azure, and on-premise environments. AWS Bedrock AgentCore Gateway reached general availability on October 13, 2025; it is hosted entirely within the AWS boundary, but it connects agents to tools and services both inside and outside that boundary.

Isolation architecture runs alongside deployment model as a second filter, and you need to name it on its own. Container-per-server gateways give you the lowest risk profile, because you get full isolation across filesystem, network, and process. Process-per-server gateways sit in the middle, isolating processes but sharing a filesystem. Shared-process gateways carry the highest risk of the three. Managed gateways hand isolation off entirely to the vendor. None of these is automatically the right choice. Each carries a different risk profile, and picking one should mean an explicit sign-off from the people who own that risk, not a default setting nobody questioned.

Get the deployment model wrong and the governance program recreates the exact problem it was meant to solve. If the sanctioned, governed path is slow, restrictive, or simply unavailable for the infrastructure a team actually runs on, developers go around it. That's shadow MCP, and it's worse than having no gateway at all, because at least an ungoverned environment with no gateway is visible as a gap. Shadow MCP hides that same gap, but makes it look like a solution. Some tools are designed as control layers organizations can deploy while keeping their existing data-residency and sovereignty posture intact, treating deployment flexibility as a governance requirement.

The three vendor categories

Enterprise MCP gateways split into three structurally different categories, and which category a vendor belongs to predicts which governance problems it can actually close. Feature marketing aside, if you buy from the wrong category, specific gaps stay open no matter how the product is positioned.

Dedicated governance gateways are purpose-built MCP control planes, built from the ground up to handle MCP-specific protocol concerns that a general-purpose API gateway was never designed to encounter. Runlayer takes a security-first, single-tenant approach on a major cloud provider, with device-management-based detection built in to catch shadow AI usage. Willow focuses on self-serve enablement, with on-prem and air-gapped deployment offered as a first-class option. Dedicated MCP governance platforms belong in this same category: they're purpose-built as the control layer for enterprise MCP governance, with guardrails, access controls, and real-time observability built in as core infrastructure.

Gateways bundled with API or model routing make up a second category, where vendors add MCP governance onto a platform that already has mature capabilities outside the MCP world. Kong's enterprise MCP gateway fits here: it's a paid extension of Kong AI Gateway, available through Kong Gateway Enterprise for fully self-hosted deployments and through Kong Konnect for hybrid and cloud deployments. Kong's AI Guardrails plugin currently leaves MCP traffic uncovered, and under Kong's older 3.x plugin model, agent identities resolved to Kong Consumers. Kong AI Gateway 2.0 and later versions added Kong Identity Principals as an additive layer, so policies can key on an authenticated directory principal instead of a gateway-local Consumer, but this only narrows that earlier gap, it doesn't close it.

Infrastructure-native options make up the third category: governance inherited from a cloud provider's existing infrastructure, practical only inside that provider's boundary. AWS Bedrock AgentCore Gateway, generally available since October 13, 2025, inherits IAM and CloudTrail directly and offers optional OAuth integration through Cognito or another identity provider. It makes sense for organizations already fully committed to AWS and willing to accept an AWS-only deployment. Microsoft's MCP Gateway is open source, tightly coupled to Entra ID, and optimized for AKS, though it can run on any Kubernetes cluster at a higher adaptation cost outside Azure.

Research projects that by the end of 2026, API gateway vendors broadly will add MCP support, but only as a checkbox feature. Adding MCP support to an API gateway does not make it a control plane for MCP-specific threats. Rug-pull protection, tool poisoning detection, and cross-server shadowing are problems an API gateway was never designed to catch, regardless of how many MCP endpoints it can route. An independent open-source foundation took over governance of the MCP protocol in December 2025, which removed the main objection to MCP as a protocol controlled by a single founding vendor. Lock-in concerns now belong at the gateway layer, where deployment model and architecture decide portability, not at the protocol layer.

The five capability gaps that separate real governance from proxy behavior

Across all three categories, five capability gaps consistently separate gateways that close MCP's structural governance problems from gateways that just route traffic and call it governance.

The first gap is identity resolution at the point of the tool call itself, not just at the point of initial connection. A gateway that authenticates once at login and then treats every subsequent tool call as implicitly trusted has only moved the weak point one step back.

The second gap is per-tool, per-call access enforcement. Many gateways enforce policy only at the server level, permitting or denying an entire MCP server as a single unit. Least-privilege enforcement requires granularity down to the specific tool, scoped to the specific role or agent calling it.

The third gap is this: audit data has to export into existing security infrastructure. If a gateway logs calls into its own proprietary interface, with no path into the SIEM or APM tools security teams already rely on, it produces records nobody outside the gateway can actually use during an investigation or a compliance audit.

The fourth gap is identity federation that ties back to a real, revocable source of truth. A gateway that maintains its own separate user directory, disconnected from Okta, Entra, Google Workspace, or whatever identity provider the organization already runs, creates a second place where access has to be managed and a second place where access can be forgotten when someone leaves.

The fifth gap is MCP-specific threat detection: rug-pull protection against tools that change behavior after approval, tool poisoning detection, and cross-server shadowing where one server impersonates or interferes with another. These threats are unique to the MCP protocol's architecture, and a gateway built around general API traffic patterns has no reason to have ever built defenses against them.

A vendor that closes all five of these gaps, across whichever of the three categories it belongs to, gives an organization a real governance layer. A vendor that closes two or three leaves the rest as an open door, one that appears eventually, in an audit, in an incident, or in the quiet moment a security team realizes nobody can say who touched what.