MCP Gateway Evaluation Criteria for Enterprise Buyers

Evaluating an MCP gateway for enterprise use means judging five things at once: authentication, deployment model, governance, threat protection, and observability. Skip one, and the whole control layer buckles, not just the piece you skipped. I've sat through enough of these procurement conversations to know that's not a theory, because it's the thing that actually breaks deals, six months in, when someone finally asks the question nobody asked at kickoff.

Anthropic put out MCP in November 2024, and within about a year and a half, it had over 10,000 active public servers and 97 million monthly SDK downloads across Python and TypeScript. That's a fast climb, and Gartner expects 40% of enterprise apps to carry AI agents by the end of 2026, up from under 5% not long ago. When adoption moves that fast, the plumbing problem shows up before anyone's ready for it.

Here's what that plumbing problem looks like on a whiteboard. Five agents, ten tools each, no gateway in between, and you're now writing and maintaining fifty separate integration paths by hand. That's the N×M problem, and it's the whole reason a gateway matters. It's the line between "agents that work" and "agents that work and quietly leak your database to a tool nobody vetted."

A gateway enforces authentication, authorization, and policy at the JSON-RPC layer, on every tool call, in a way a plain traffic proxy just doesn't. What actually separates the two:

• Centralized identity with multi-role RBAC
• A curated, IT-approved server catalog
• Per-user OAuth passthrough instead of shared service accounts
• Policy-as-code, plus real handling for MCP-specific threats

Skip that layer and you get ungoverned agent access. The exposure starts the moment a server goes live without oversight, well before anything visibly breaks. By the time you notice, you're writing an incident report instead of a design doc.

How the five criteria interlock and why no single one stands alone

Authentication and identity, deployment model and data residency, governance architecture, MCP-specific threat protection, and observability and auditability might look like five separate line items on a checklist, but treating them that way means missing how badly they lean on each other.

RBAC without identity doesn't work, because you can't hand a role to an agent you can't name. Observability without RBAC gives you logs full of anonymous, service-account noise, nothing you can trace back to an actual human. Threat protection without a server catalog is half a defense at best; you can't validate what you don't know exists. And audit trails without immutability and real-time alerting are just postmortems, useful for the coroner, not the patient.

None of it matters anyway if the deployment model breaks data residency and the gateway never clears compliance review in the first place. So the practical move for procurement teams is to judge these as one connected system, not a ranked wish list where you pick your favorite two and skip the rest. Each section below takes one criterion, what it demands, where vendors actually diverge, and how a crack in it spreads to the others.

Authentication and identity — the criterion that blocks everything else if it fails

MCP shipped without a full authentication framework at launch, and OAuth support only made it into the official spec in June 2025, which tells you something about how young this whole layer still is.

The gap between spec and reality is wide, too. As of early 2026, only 8.5% of servers actually implement the mandatory OAuth 2.1 requirement. That gap between what the standard says and what's actually deployed is the attack surface buyers inherit whether they know it or not.

The floor here isn't up for debate:

• OAuth 2.1, mandated as of the June 2025 update
• SAML 2.0 for SSO
• OpenID Connect for attribute mapping
• PKCE for clients like IDE plugins, which stops authorization codes from getting intercepted mid-redirect

What separates a real governance gateway from a glorified identity-aware proxy is On-Behalf-Of token propagation. A gateway with OBO passes the end user's actual identity downstream to the MCP server. Skip OBO and agents run on shared credentials, audit logs show no user-level attribution, and when someone leaves the company, cutting off their access cleanly is nearly impossible.

Ask vendors directly: does the gateway wrap servers with enterprise SSO automatically, or does someone hand-configure OAuth for every single server? Does it support shared service accounts and per-user auth side by side, depending on the use case? Stacklok's 2026 software report names security as the top blocker to MCP adoption, and authentication gaps sit right at the center of that.

Deployment model and data residency — the criterion that determines whether the gateway clears compliance review

Gateways run four ways: managed SaaS, VPC-hosted, Kubernetes-native, or air-gapped. A gateway that only does one of these is a gateway that eventually gets bounced out of a compliance review, usually later than anyone would like.

Three things decide which model you actually need:

• How fast the team needs to move from prototype to production
• Compliance posture: SOC 2 Type II, HIPAA, FedRAMP, ISO 27001, or something specific to the industry
• Data sovereignty: whether agent traffic, including internal API responses and database query results, has to stay inside a given VPC, region, or on-prem box

Managed-only gateways mean trusting the vendor with every tool call payload that flows through, and for regulated industries, that usually rules them out on its own. Financial services and healthcare shops need per-tool access control, RBAC enforcement, and audit logging, and the deployment model has to support all three without shipping sensitive payloads off to somebody else's infrastructure.

Before you shortlist anyone, find out where the traffic actually goes. Can it run fully self-hosted with zero vendor telemetry, and are the compliance certifications scoped to the deployment model you need, or only to the vendor's SaaS tier? That last question trips up more buyers than it should, mostly because nobody thinks to ask it until the audit is already underway.

Governance architecture — RBAC, policy enforcement, and the server catalog

Tool-level RBAC works by intercepting the tools/list response and filtering it based on the requesting agent's role, so sensitive tools simply don't show up in that agent's context, and you can't invoke what you can't see.

Virtual server scoping restricts which tools a given team or agent can touch. Good gateways validate incoming identity and carry it downstream, so an agent acting on behalf of a user never exceeds what that user could already do on their own. The rule, in plain terms: if a user can't delete a repo, the agent working for them can't either. That gets enforced at the protocol layer, not left to a prompt instruction and a hope that the model listens.

Now the catalog problem. Skip a curated internal registry, and MCP adoption splinters into dozens of servers that individual teams spun up on their own, none of them vetted by anyone. Smithery is the biggest public MCP registry out there, with something like 2,500 community-submitted servers. Fine for poking around and prototyping, but it functions as a discovery directory, not a control plane, and no enterprise should be treating it as a source of truth.

A production gateway's job on the catalog side is simple to state and hard to do: keep agents off unvetted public endpoints, and keep an IT-approved inventory of every server actually in use. Every server added outside that registry is an identity nobody can account for, and unaccounted identities are exactly the ones that get exploited first.

Policy-as-code matters more than it sounds like it should. Multiple independent evaluators flag it as a real differentiator between gateways, not a nice-to-have. Ask whether configuration and access policies can be version-controlled and shipped through the same CI/CD pipeline the engineering team already uses. Teams with policies written down and reviewable, instead of tribal knowledge sitting in one person's head, ship agentic AI faster, because the guardrails are already there when a new server comes up for approval. Governance speeds this up rather than taxing it.

SCIM provisioning rounds this out. It automates the agent and user lifecycle, so access gets pulled the moment someone offboards, with no manual cleanup ticket and no forgotten account sitting around for eight months.

MCP-specific threat protection — the criterion most conventional API gateways cannot satisfy

Traditional WAFs weren't built for any of this. The threats below live at the protocol and semantic layer, not the HTTP layer, so a firewall built to catch SQL injection isn't even looking in the right place.

The attack classes documented through 2025 are now catalogued in the OWASP MCP Top 10, currently in Phase 3 beta:

• Tool poisoning: instructions hidden in tool metadata, invisible to the human reading the interface but fully processed by the model. Invariant Labs showed the first public proof-of-concept in April 2025, a single poisoned tool description pulling private repository contents out with zero user interaction. Lab testing across more than 45 real-world MCP servers found attack success rates north of 60%.
• Rug pulls: a tool quietly changes its behavior or description after you've already granted it permission. Most clients never flag the change.
• Cross-server shadowing: a malicious server registers a tool under the same name as a legitimate one elsewhere, then intercepts calls meant for the real thing.
• Shadow MCP servers, OWASP MCP09:2025: unapproved instances running outside any formal governance, often sitting on default credentials with permissive settings nobody bothered to lock down.

Between January and April 2026, researchers disclosed more than 40 CVEs against MCP implementations, spanning Python, TypeScript, Java, and Rust SDKs. A separate advisory in April 2026 turned up more high and critical CVEs, with an estimated count in the hundreds of thousands of vulnerable servers exposed worldwide. One worth remembering by name: CVE-2025-6514, in mcp-remote, an OS command injection bug with a CVSS score of 9.6, hitting versions through 0.1.15.

So what do you actually check gateways for? Strict schema validation with allowlisting catches tool poisoning before injected instructions ever reach the model's context window, while integrity checks on server definitions catch silent rug-pull redefinitions. Catalog enforcement that blocks any connection to a server outside the approved registry kills shadow servers before they matter. And pre-production sandboxing gives you the ability to test a server for data exposure before it's approved, and build hardened variants by rewriting descriptions and narrowing what actions it can take. That sandboxing piece is rare enough that finding a vendor who does it well is a real signal on its own.

An attack surface discovered after go-live points to a governance failure, not a security surprise. The hole was there the day the server went ungoverned; nobody just happened to notice it sooner.

Observability and auditability — what "enterprise-grade" actually means in practice

Too many buyers grade gateways on latency benchmarks and integration counts, which is optimizing for the wrong slice of the decision. What actually determines whether a deployment is enterprise-grade is whether the gateway can prove, in a form an auditor will accept, who did what and when.

Compliance frameworks have caught up to this. SOC 2, ISO 42001, DORA, and the EU AI Act now expect traceable agent activity as a baseline, not an extra. The EU AI Act's high-risk obligations became enforceable on August 2, 2026, layering in logging, access-control, and human-oversight requirements for any agent touching a high-risk domain.

An audit-grade log entry for a single tool call needs to carry the tool name and which server it came from, the arguments sent in and the result that came back, the latency, the authenticated user's real identity (not a service account, which is exactly why identity propagation from the first criterion has to be sitting in place before any of this works), and the policy context under which the call was authorized.

There's a real difference between reading a log after something's gone wrong and catching it as it happens. A log you only check post-incident functions as a postmortem and nothing more. Real-time alerting on odd tool-invocation patterns, and behavioral monitoring that flags an agent's action sequence when it drifts from its baseline, is what actually turns observability into a safety net instead of a filing cabinet.

Immutability isn't optional either. Regulators want tamper-evident logs, so ask whether the gateway writes to an append-only store and whether it can prove log integrity to someone outside the company. For reference, IBM's approach wires OpenTelemetry into distributed tracing tools like Jaeger and Zipkin, and Microsoft leans on session-aware routing with built-in telemetry. Worth checking whether a gateway plugs into the SIEM or monitoring stack you already run, rather than forcing you to stand up a second, parallel tooling investment just for agents.

The real danger in agentic AI isn't the model doing the wrong thing, but the company never finding out, because most teams have no record at all of what their agents actually touched.

How current gateway options map to these criteria

The market's grown fast, maybe too fast. Gartner projects 75% of API-gateway vendors and roughly half of iPaaS vendors will carry some MCP feature by the end of 2026. A lot of that is an existing API gateway with MCP bolted on the side, not something built from scratch as a control plane for this specific problem.

The question worth putting to every vendor in the room: does it enforce policy at the MCP/JSON-RPC layer, meaning real per-tool RBAC, tool description validation, rug-pull detection, or does it just apply the same old HTTP-layer controls and slap an MCP label on the box?

A few names worth knowing, and roughly where each one sits.

Kong is an established API gateway now adding MCP features, and its strength is plugging into enterprise API infrastructure you probably already run. Worth checking whether the MCP-specific threat controls, tool poisoning and rug-pull detection especially, are native or added on after the fact.

Tyk shows up repeatedly in independent evaluations for per-tool access control and RBAC, and it's a common pick in regulated-industry comparisons alongside Amazon Bedrock AgentCore.

Amazon Bedrock AgentCore Gateway makes sense if you're already deep in AWS, and its adoption picked up in November 2025, which tracks with AWS treating MCP infrastructure as a real priority instead of an afterthought.

Obot handles analytics and logging through its admin console. Worth digging into how deep the audit trail immutability and real-time alerting actually go, measured against the EU AI Act baseline rather than a marketing page.

Open-source options give you deployment flexibility and let you audit the gateway's own code, which some compliance teams genuinely want to do. The tradeoff: check whether enterprise identity features, SSO, SCIM, OBO token propagation, are actually production-ready, or whether you're signing up to build a good chunk of that yourself over the next two quarters.

MCP Manager, built by Usercentrics, was designed from the ground up as an enterprise control layer for agentic AI, rather than an API gateway with MCP tacked on afterward. It's built around this exact five-criteria framework: centralized identity with per-role access control, a governed server catalog, and audit logging meant to satisfy the kind of scrutiny SOC 2 and the EU AI Act now demand.

Whichever direction a buyer leans, the test stays the same: don't grade any of these vendors on one strength, but grade the whole system, because that's the only way any of it holds up once real agents start running against real production data.