The MCP Gateway Market Just Split in Two — And That Is Good for Open Source

Algis Dumbris • 2026/03/21

The Split Is Here

If you have been watching the MCP gateway space over the past six months, you have noticed something that no one is talking about directly: the market has fractured into two distinct tiers. On one side, enterprise commercial platforms — PointGuard AI, SentinelOne’s Prompt Security, ServiceNow AI Gateway, Airia — are racing to build comprehensive security and governance suites that CISOs can buy with a purchase order. On the other side, open-source tools — MCPProxy, agentgateway, ToolHive, MCP Gateway — are solving the same core problems with composable, self-hosted architectures that developers actually deploy.

This is not a temporary market condition. It is a structural split, and if you have spent any time in infrastructure software, you have seen this exact pattern before. It played out in the API gateway market a decade ago. It played out in container orchestration. It played out in observability. And in every single case, the open-source tier did not just survive — it defined the category.

The Enterprise Tier: Security as a Product

The enterprise commercial gateways share a common thesis: organizations need to buy MCP security, not build it. The reasoning is sound on paper. AI agents calling tools through MCP represent a genuinely new attack surface. Shadow MCP servers proliferate when developers spin up tool integrations without security review. Data loss prevention, intent-based access control, and compliance auditing are real requirements that CISOs cannot ignore.

PointGuard AI

PointGuard positions itself as the first AI security platform with a fully integrated MCP gateway. Their differentiation centers on zero-trust authorization at the individual tool-call level, combined with AI-native DLP that masks or redacts sensitive data in agent responses. They coined the term “shadow MCP” to describe unmonitored agents operating outside centralized governance — a real problem in enterprises where developers spin up MCP servers without security oversight. Their intent-based policies separate read, write, and update operations per agent, offering a granularity that most gateways do not attempt.

SentinelOne / Prompt Security

SentinelOne’s acquisition of Prompt Security in late 2025 signaled that endpoint security vendors see MCP as their next battlefield. The integration brings real-time monitoring of MCP traffic alongside existing EDR capabilities, giving security teams a single pane of glass that covers both traditional endpoints and AI agent communications. Their approach is to treat every MCP tool call as a potential threat vector and apply the same detection-and-response methodology that worked for malware.

ServiceNow AI Gateway

ServiceNow built its AI Gateway as an extension of its existing IT service management platform. The pitch is workflow integration: MCP tool calls get logged, audited, and governed through the same ITSM processes that organizations already use for change management and incident response. For organizations already deep in the ServiceNow ecosystem, this is compelling. For everyone else, it is another proprietary platform to manage.

Airia

Airia takes an orchestration-first approach, positioning its gateway as the control plane for multi-agent workflows. Their emphasis on agent coordination and centralized policy enforcement targets organizations running complex agent topologies where the gateway needs to understand not just individual tool calls but the broader context of which agent is doing what and why. It is the most ambitious vision in the enterprise tier, and also the most tightly coupled to their platform.

The Open-Source Tier: Composability Wins

The open-source gateways start from a fundamentally different premise. Instead of selling a product that solves all MCP governance problems at once, they build composable tools that solve specific problems well and integrate into whatever infrastructure you already run.

MCPProxy

MCPProxy focuses on two problems that every organization with more than a handful of MCP tools faces: discovery and trust. BM25-ranked tool discovery means that when an agent requests a tool, MCPProxy returns the most relevant match from across all connected upstream servers — not just the first one registered. Security quarantine means that newly added tool servers start in a restricted state and must be explicitly approved before agents can call them.

The CLI makes this concrete. You add an upstream server with mcpproxy upstream add, it enters quarantine automatically, and you promote it with mcpproxy upstream approve after review. You run the gateway itself with mcpproxy serve. No cloud account. No dashboard. No license key. Just a binary that sits between your agents and your tools and makes both discovery and trust decisions explicit.

MCPProxy also supports Docker-based isolation, running untrusted MCP servers in containers with restricted network access and resource limits. This is not a feature that enterprise platforms emphasize, because their model assumes you trust the tools they have vetted. The open-source model assumes you trust nothing until you have inspected it yourself.

agentgateway

agentgateway is a Rust-based data plane under the Linux Foundation. It supports both MCP and Google’s Agent-to-Agent (A2A) protocol, making it the only gateway with genuine multi-protocol interoperability. With over 2,100 GitHub stars, 1,400 commits, and 118 contributors, it has meaningful community momentum. The Kubernetes-native design with Gateway API integration makes it a natural fit for platform engineering teams who want MCP routing that behaves like every other piece of their infrastructure.

agentgateway focuses on routing, access control, and protocol bridging. It uses xDS for dynamic configuration, supports RBAC designed specifically for agentic protocols, and handles multi-tenancy with isolated resource management. It does not try to solve discovery ranking or security scanning of tool schemas — it trusts that other tools in the stack handle those concerns.

ToolHive

ToolHive takes the container-first approach to its logical conclusion. Every MCP server runs in its own isolated container with fine-grained permission controls. The gateway manages the lifecycle of these containers, handles health checks, and provides a unified interface for agents to discover and call tools. It is the most operationally opinionated tool in the open-source tier, trading flexibility for safety guarantees.

ToolHive’s strength is that the security model is structural, not policy-based. You do not write rules about what a tool can do — you put it in a container where it physically cannot do anything you have not allowed. For teams that want defense-in-depth at the infrastructure level rather than the policy level, this is the right architecture.

MCP Gateway

MCP Gateway provides a lightweight proxy that focuses on protocol-level concerns: routing, authentication, logging, and basic access control. It is the thinnest option in the open-source tier, designed for teams that want a proxy and nothing more. Its strength is simplicity. Its limitation is that as MCP deployments grow, teams typically need more — discovery, quarantine, observability — and end up layering additional tools on top.

The API Gateway Precedent

This split is not new. It is the same structural pattern that shaped the API gateway market between 2012 and 2020.

In the early API gateway era, enterprise vendors — Apigee, MuleSoft, CA Technologies — built comprehensive platforms that bundled routing, security, analytics, monetization, and developer portals into single commercial products. They targeted CIOs and CTOs with slide decks about “API management platforms.” They sold seven-figure contracts to Fortune 500 companies.

At the same time, open-source tools — Kong, Tyk, and later Envoy — built composable proxies that solved routing and security well, and let teams plug in whatever else they needed. Kong started as an Nginx extension. Envoy started as a sidecar proxy at Lyft. Neither tried to be a platform on day one.

The outcome is instructive. Google acquired Apigee for $625 million. Salesforce acquired MuleSoft for $6.5 billion. Both acquisitions were defensive — large cloud vendors buying API management before it became a commodity. And both products increasingly struggled against the open-source alternatives that platform engineering teams actually wanted to deploy.

Kong crossed 100 million downloads. Envoy became the default data plane for every major service mesh. The open-source tools did not win because they were free. They won because they were composable, because they fit into existing infrastructure rather than replacing it, and because the developer community that adopted them eventually pulled enterprise buyers along.

Why the Split Benefits Open Source

The same dynamics are at work in the MCP gateway market, with one critical difference: the timeline is compressed. The API gateway split took nearly a decade to resolve. The MCP gateway split is happening in months, because the infrastructure patterns are already established.

Here is why the split structurally benefits open-source builders:

1. Enterprise Platforms Create the Category

When PointGuard, SentinelOne, and ServiceNow build MCP gateway products, they do the expensive work of educating buyers that MCP gateways are a real product category. They fund analyst briefings. They publish whitepapers. They present at RSA and Gartner Security Summit. Every dollar they spend on category creation makes it easier for an engineering team to justify deploying an open-source alternative, because the conversation with the CISO has already happened.

This is exactly what Apigee did for Kong. Apigee spent years educating the market that API gateways were essential infrastructure. By the time Kong was mature enough for production, the category was already established and budgets were already allocated. Kong just had to show that it solved the same problems with a better developer experience and no license fee.

2. Composability Beats Comprehensiveness

Enterprise MCP platforms are comprehensive by design. They bundle discovery, security scanning, DLP, policy enforcement, audit logging, and compliance reporting into a single product because that is what enterprise buyers expect from a platform purchase. But comprehensive platforms are also rigid. They work well when your architecture matches their assumptions, and they fight you when it does not.

Open-source tools are composable by design. MCPProxy handles discovery and quarantine. agentgateway handles routing and protocol bridging. ToolHive handles container isolation. You pick the tools that match your architecture and wire them together. When your architecture changes — and in the current AI infrastructure cycle, it changes constantly — you swap components rather than renegotiating a platform contract.

3. The Developer-Led Adoption Cycle

Enterprise MCP platforms sell top-down. The vendor briefs the CISO, the CISO mandates the platform, and developers are told to use it. This works for compliance-driven deployments, but it generates friction with the engineering teams who actually build and operate MCP integrations.

Open-source tools spread bottom-up. A developer adds MCPProxy to their agent stack because it solves a discovery problem they have today. Their teammate adopts it because the quarantine workflow prevents the kind of incident they dealt with last month. The platform engineering team standardizes on it because it integrates with their existing Kubernetes infrastructure. By the time the CISO asks about MCP governance, the tool is already running in production and the security team just needs to verify that it meets their requirements.

This bottom-up adoption pattern is why Kong, not Apigee, became the default API gateway for cloud-native organizations. And it is why open-source MCP gateways will follow the same trajectory.

4. Security Through Transparency

The enterprise tier sells security through proprietary scanning engines, closed-source DLP models, and vendor-managed threat intelligence. These are genuine capabilities, and for some organizations they are requirements. But they are also black boxes. When PointGuard’s DLP engine flags a tool call, you cannot inspect the detection logic. When SentinelOne’s MCP monitor raises an alert, you cannot audit the model that generated it.

Open-source gateways provide security through transparency. MCPProxy’s quarantine workflow is visible in the source code. agentgateway’s RBAC implementation can be audited by anyone. ToolHive’s container isolation relies on standard Linux kernel features, not proprietary sandboxing technology. For organizations that take security seriously enough to actually verify their security tools, transparency is not a nice-to-have — it is a requirement.

What This Means for Builders

If you are building AI agent infrastructure today, the market split gives you a clear framework for decision-making.

Choose the enterprise tier if your primary constraint is procurement compliance, you need a single vendor to own MCP security end-to-end, or your organization requires commercial support contracts and SLA guarantees. The enterprise platforms are real products solving real problems, and for some organizations they are the right choice.

Choose the open-source tier if you want to control your own MCP infrastructure, your architecture is changing faster than any vendor can keep up with, you need to integrate MCP governance into an existing platform engineering stack, or you believe that security tools should be auditable. Start with the tool that solves your most immediate problem — discovery, routing, isolation, or lightweight proxying — and add components as your deployment grows.

The split is real, it is structural, and it is permanent. Two tiers of MCP gateways will coexist for the foreseeable future, just as two tiers of API gateways coexist today. But the open-source tier is where the innovation happens, where the community forms, and where the defaults get set.

We have seen this movie before. Open source won the API gateway market. It won the container orchestration market. It won the observability market. The MCP gateway market will be no different.

The split is not a problem. It is a signal that the category has matured enough to sustain both approaches. And for those of us building in the open-source tier, it means the hardest work — convincing the market that MCP gateways matter — is being done for us.

MCPProxy is open source and available at github.com/smart-mcp-proxy/mcpproxy-go. Add upstream servers with mcpproxy upstream add, approve them with mcpproxy upstream approve, and run the gateway with mcpproxy serve.