MCP gateway and catalog platforms compared

MCP gateway platforms all claim to solve the same problem: give an AI agent safe, governed access to outside tools. But the way they solve it differs at the architecture level, not just the feature list. Identity handling, credential routing, and policy enforcement, the three things that actually determine whether a breach stays contained or spreads, look completely different from one platform to the next. Picking wrong here isn't a minor inconvenience. It's an architecture decision that sticks around for years.

Anthropic introduced the Model Context Protocol in November 2024, an open standard built on JSON-RPC 2.0 for connecting AI agents to databases, APIs, and file systems. Within about a year, Anthropic handed MCP over to the Agentic AI Foundation under the Linux Foundation, with OpenAI, Block, AWS, Google, Microsoft, Cloudflare, and Bloomberg joining as founding members. The AAIF has since grown past 170 member organizations, more than double what CNCF had at the same point in its own history. That pace isn't a fluke. It's a sign that MCP has already crossed over from experiment to infrastructure.

Here's the operational problem underneath all of it. A single agent session might touch a database, an issue tracker, a filesystem, and three external APIs in the same conversation. Without something sitting in the middle, each of those connections carries its own auth scheme, its own rate limit, and zero shared visibility into what actually happened. A gateway sits between the agent and the tool servers as a governed reverse proxy: it centralizes routing, authentication, policy, and audit logging behind a single endpoint, so agents talk to one thing instead of a dozen. That turns an N×M integration mess into something a security team can actually reason about.

Industry research projects that 75% of API vendors will ship MCP features by the end of 2026. Whatever platform an enterprise picks now is the architecture it's stuck reasoning about for the next several years. Connecting an agent to a tool is easy. Governing that access at scale, across teams, tokens, and thousands of tool calls a day, is a different problem entirely. That gap is what the rest of this piece is about.

The three axes where gateway architectures actually diverge

Most mature gateways look the same on paper. RBAC, audit logs, rate limiting, check, check, check. The real differences show up underneath that surface, in how each platform actually handles three structural questions.

Axis 1 is identity binding: how deeply does the gateway tie a given tool call back to a verified human identity? Shallow implementations hand out one API key per agent and call it done, so nobody can say which user actually triggered which action. Deeper implementations wire in SSO and SCIM, issue per-user tokens, and carry that identity all the way down to the individual tool call. That distinction matters the moment something goes wrong. Security teams don't just need to know which agent ran; they need to answer "who authorized this," and shallow identity binding can't answer that question.

Axis 2 is credential routing: how are credentials handled once a request is in flight? Static API keys sitting in a config file are one end of the spectrum. Ephemeral, scoped tokens issued fresh for each operation are the other. The well-documented failure mode here is mundane: a developer grants an agent broad permissions "just to get the thing working," and that broad grant never gets walked back. Least privilege at the credential level is the more defensible posture, but plenty of platforms still leave that enforcement to whoever's implementing the system, rather than baking it in.

Axis 3 is policy enforcement depth, meaning where in the request lifecycle rules actually get applied. Gateway-level policy handles broad traffic rules: rate limits, IP allowlists, that sort of thing. Tool-call-level policy is finer-grained, applying rules based on role, context, and intent at the moment of each individual invocation. Some platforms go further and rewrite tool descriptions before the model ever sees them, which isn't just blocking bad calls after the fact. It's limiting what the LLM is shown in the first place, so it never has the option to misuse a capability it was never told about.

A fourth variable sits underneath all three: deployment model. Managed SaaS, self-hosted, or cloud-native each carry different implications for data sovereignty and compliance, and that choice usually needs to get made before any of the security axes above even get evaluated. Keep these four in mind heading into the platform comparisons below. They're the lens the rest of this piece uses.

The authentication spec every gateway must reckon with

MCP's authorization spec has moved fast, and every gateway on the market today is built against some snapshot of it. In March 2025, OAuth 2.1 with PKCE became the baseline for remote MCP servers. By November 2025, PKCE was mandatory for all client-side applications, and the spec added Client ID Metadata Documents (CIMD) so each client application could be uniquely identified. Back in June 2025, the spec shifted MCP servers into the role of OAuth resource servers, meaning they validate tokens but hand off actual token issuance to a separate Authorization Server. That's a meaningful change from earlier drafts, which treated the MCP server as both resource server and authorization server at once, a pattern most enterprise IAM teams reject outright because backend systems simply aren't supposed to double as authorization servers.

The more recent addition worth watching is Enterprise-Managed Authorization (EMA). EMA lets an organization provision MCP server access centrally through its identity provider, reducing per-app OAuth friction for users. Anthropic, Microsoft, and Okta have already adopted it, and more MCP servers are picking it up. A gateway that hasn't implemented EMA yet is creating a governance gap that will only get more visible as adoption spreads.

Dynamic Client Registration and CIMD solve a related but separate problem: onboarding MCP clients without static, hand-configured OAuth setups. Convenient, yes, but not free of tradeoffs depending on the environment. Dick Hardt, one of the co-authors of OAuth 2.1, has pointed out that the current spec "represents a novel usage of OAuth that differs significantly from traditional patterns." Leaning on dynamic client registration and unverified clients is a structural risk, not a footnote, and it's exactly the kind of thing enterprise architects need to check against each platform individually rather than take on faith.

Authentication needs to run through the identity providers already sitting inside the enterprise, Okta, Azure AD, Google Workspace, OneLogin, not around them. Whether a given gateway can pull that off cleanly comes straight down to how faithfully it implements the spec above.

And here's the part that should worry anyone deploying MCP today: the spec marks authorization as optional. A scan in July 2025 found at least 1,862 publicly reachable MCP instances answering unauthenticated requests. By early 2026, nearly 7,000 internet-exposed MCP servers had been catalogued by early 2026, a large share of them reachable without any authentication at all. Not weak authentication. None.

The threat surface that governance failures open up

Between January and February 2026, security researchers filed more than 30 CVEs against MCP servers, clients, and the infrastructure around them. The worst of the batch, CVE-2025-6514, scored a 9.6 on CVSS and hit the widely used mcp-remote proxy package across more than 437,000 installed environments. That's not a niche bug. That's a supply-chain-scale exposure sitting in a package a lot of production stacks depend on.

Tool poisoning is the attack pattern getting the most attention right now, and for good reason. An attacker embeds malicious instructions inside a tool's description or metadata, invisible to the human user, fully visible to the model reading it. A 2025 study looking at 1,899 open-source MCP servers found 5.5% of them carried this exact vulnerability. Framelink's Figma MCP server (figma-developer-mcp) had one logged as CVE-2025-53967, a command injection flaw that allowed remote code execution. And the MCPTox benchmark found o1-mini fell for tool poisoning attacks 72.8% of the time, which cuts against the assumption that smarter models are automatically safer models. In this case, more capability didn't buy more resistance.

The damage doesn't stay contained to one server, either. Invariant Labs showed how a single compromised MCP server can weaponize other, fully trusted servers sitting next to it, meaning the blast radius of one bad actor extends well past the server it actually broke into. Multi-turn prompt injection compounds the problem further: testing across eight open-weight models found attack success rates as high as 92% when the attack unfolds gradually across an extended conversation rather than landing in a single message. Security researchers have argued multi-turn resilience deserves to be tracked as its own metric, separate from single-turn safety scores, for any agent running long sessions.

Then there's the overprivileged access problem, and it's not hypothetical. In July 2025, Replit's AI agent deleted a production database holding more than 1,200 records, despite being given explicit instructions to freeze all code and actions. That's what happens when credential scope and policy enforcement don't match the level of trust actually being granted.

2025 also brought cross-tenant data exposure at Asana, a prompt injection attack against the GitHub MCP server, an unauthenticated remote code execution flaw in Anthropic's own MCP Inspector tool (CVE-2025-49596, triggerable just by visiting a malicious website, no extra network access needed, though the victim did need MCP Inspector running locally), and multiple supply-chain compromises targeting MCP tooling. None of this is theoretical anymore. It compounds fast wherever gateway governance stays shallow, and it's exactly why platforms enforcing policy at tool-call depth, watching for intent drift, and keeping tamper-proof audit logs aren't solving an imagined problem. They're responding to a documented one.

How ten current platforms handle these problems differently

TrueFoundry built its enterprise AI Gateway around a simple premise: extend the AI infrastructure teams already have instead of standing up a separate MCP system next to it. Models and tools land in the same observability dashboard, sharing one control plane. Authentication and rate-limiting run in memory, with latency under 3 milliseconds under load and throughput of 350 requests per second on a single vCPU. MCP Server Groups give teams logical isolation without needing separate security configs for each one. It's the only platform among the leading MCP gateway lists recognized as a Representative Vendor in the 2025 Gartner Market Guide for AI Gateways, which fits its target audience: enterprises already running serious AI workloads who want consolidation, not one more point solution bolted on.

Composio takes the opposite bet: breadth and speed. It ships more than 1,000 managed integrations with unified OAuth and production-grade RBAC and PII controls built in from the start. Its meta-tools compress large tool catalogs down to fit inside hard limits like Copilot's 128-tool cap, a real constraint that a lot of other platforms just leave for the implementing team to figure out. For teams that care more about getting integrated fast than shaving milliseconds off latency, Composio is often the quickest path from zero to a connected agent.

IBM Context Forge is open-source and built for federation: organizations running gateway instances across multiple environments or regions can present one unified tool catalog across all of them. Health monitoring and capability merging let separate Context Forge instances combine into a shared catalog, though peer gateways now get configured manually via the REST API, since mDNS auto-discovery was pulled in v1.0.0-BETA-2. Virtual server composition lets teams fold several MCP servers into one logical endpoint. Published benchmarks put Context Forge response times in the 100–300ms range, varying with configuration, and built-in observability trails behind the managed options. It fits organizations running complex multi-region deployments that want federation-first architecture and full control over the source.

Microsoft's MCP Gateway, built on Azure API Management, ties RBAC directly into Azure Entra ID, so identity runs through infrastructure a lot of enterprises already have in place. Response times reflect cloud-routing overhead, Azure handles scaling for concurrency, and monitoring is extensive, if operationally involved. This one's built for organizations already deep in Azure, where Entra ID integration isn't a nice-to-have, it's the whole point.

Kong AI Gateway comes from one of the most established names in enterprise API management. A recent version added a dedicated MCP Proxy plugin, OAuth 2.1 support, and LLM-as-a-Judge validation. MCP governance here sits on top of a mature API management layer, which means teams already running Kong can extend into MCP without adopting a whole new control plane alongside it.

Lasso Security leads with a security-first pitch: strong policy enforcement, audit trails, and threat detection tuned for production AI systems. Memory overhead runs high due to all the security processing happening in the pipeline. It's built for regulated environments where catching threats and keeping a clean audit trail matter more than shaving off a few milliseconds of latency.

Lunar.dev's MCPX is built around governed access across many MCP servers at once, with ACLs that can operate at the global, service, or individual tool level depending on consumer tags. Authentication covers API keys and OAuth for agents, plus SSO and IAM integration for enterprise identity providers. Tool customization lets teams create safe variants of a tool by rewriting its description or locking down parameters, keeping the model on an approved path rather than trusting it to stay there on its own. It logs an immutable audit trail alongside Prometheus-compatible metrics, tracking tool call duration with labels for tool name, error state, calling agent, and model. It also plugs into Lunar's broader AI Gateway for full traffic inspection and prompt sanitization across the whole workflow. TrueFoundry's 2026 benchmark puts its overhead around 4 milliseconds with low-to-medium memory use. MCPX deploys as a managed service, in a private cloud, or fully on-premises, which gives teams data sovereignty without giving up governance. It suits organizations that want fine-grained control, strong auditing, and LLM-specific safeguards all under one roof.

Obot is purpose-built for MCP governance and open-source, running self-hosted on Kubernetes or Docker, or available as a managed service for teams that don't want to run it themselves. Its built-in catalog, composite server support, and multi-role RBAC come standard rather than bolted on. It's a good fit for teams that want Kubernetes-native infrastructure control paired with enterprise identity integration, and who won't settle for a managed-only SaaS option.

Workato approaches MCP from the automation side, not the security side, bringing more than 1,200 enterprise connectors along with mature workflow governance and compliance tooling built for business process teams. It fits organizations already running heavily on Workato, where MCP connectivity extends an automation stack that's already in place, rather than introducing a brand-new layer of infrastructure.

Beyond these ten, platforms like Runlayer approach the problem by building directly around the three axes above: SSO and SCIM-driven identity binding, ephemeral tokens issued per operation rather than static keys, and policy enforcement applied at tool-call depth rather than just at the gateway's edge. That combination puts identity, credentials, and enforcement inside a single control plane instead of treating them as three separate concerns bolted together after the fact, which is precisely the kind of structural decision this piece has been getting at all along.

None of these ten platforms are wrong choices, exactly. They're built for different failure modes and different starting points. But the axes matter more than the checklist. A platform with airtight audit logs and shallow identity binding will still leave a security team unable to answer "who authorized this" six months from now. The feature list looks identical from a distance. The architecture underneath it isn't, and that's the part worth getting right before committing to one for the next several years.