MCP gateways compared: Cloudflare, Okta, Auth0 and Microsoft
Cloudflare, Okta, Auth0 and Microsoft all offer MCP gateways now. A side-by-side comparison of where each one sits, how it handles auth and logging, and what your MCP server still needs to do.
September filled out the MCP gateway category. Auth0 opened a beta of its Agent Gateway on September 18. Okta used Oktane on September 22 to say its Agent Gateway would be generally available in Q3. Cloudflare made MCP server portals generally available on September 24. Microsoft's MCP firewall for Global Secure Access has been in public preview since August.
The products share a name and a pitch: one place to connect agents to tools, with policy and logs. Underneath, they're built for different buyers and sit in different places in the request path. Two of them aren't really alternatives to each other at all. This post compares all four side by side and covers the part none of them removes: authorization on the MCP server itself.
What is an MCP gateway?
An MCP gateway is a proxy between AI agents and the MCP servers they call. It gives agents one endpoint instead of many, decides which servers and tools each caller can reach, handles the credentials for upstream servers, and logs tool calls. Some gateways also turn existing APIs into MCP tools, shrink tool lists to save context, or inspect traffic for sensitive data. A gateway doesn't replace authorization on the MCP servers behind it.
The four gateways at a glance
Cloudflare MCP server portals
Cloudflare's portals put several MCP servers behind one URL that sits behind Cloudflare Access. Users sign in once through Access, then authorize each upstream server that needs OAuth. Admins pick which tools and prompts each portal exposes, can rename tools without touching the upstream server, and can turn on Code Mode, which collapses every tool into a single code tool so the context cost stays flat no matter how many tools there are.
The GA release added the pieces that matter for production. Traffic can route through Cloudflare Gateway for HTTP logging and DLP scanning. Service tokens let autonomous agents connect without a browser. Static OAuth client credentials cover upstream providers that don't support Dynamic Client Registration (DCR), and Logpush exports activity to a SIEM. Two days earlier, portals gained support for MCP servers that are only reachable on a private network.
Best for: teams already on Cloudflare Zero Trust that want a curated catalog of MCP servers for employees.
Watch for: Cloudflare's docs are direct about the limits of a portal. Hiding a server from a user doesn't stop them from reaching it:
"Blocked users can still connect to the server (and bypass your Access policies) by using its direct URL. If you want to enforce authentication through Cloudflare Access, configure Access as the server's OAuth provider."
Okta Agent Gateway
Okta's gateway is an identity-native proxy. It collects tools from several remote MCP servers behind one Okta-secured endpoint, enforces policy on every tool call and keeps one audit trail. Agents connect to it like any MCP server, so it works without code changes with the agents Okta lists, including Claude Code, Cursor and GitHub Copilot.
The difference from a routing gateway is how upstream credentials work. Agents never hold them. For apps that support it, the gateway uses Cross App Access, Okta's implementation of the ID-JAG token exchange, so the final token carries both the user and the agent. For apps that don't, such as GitHub or Slack, Okta's token service brokers OAuth consent. At Oktane, Okta said it plans to extend its kill switch to the gateway in Q4, so deactivating an agent revokes its active tokens.
Best for: enterprises standardizing on Okta that want every agent's tool calls tied to a person and an agent identity.
Watch for: Okta positions it as an identity layer on top of your existing gateways, not a replacement for them. Check the current GA status before you plan around it, since the Q3 date came from the September 22 announcement.
Auth0 Agent Gateway
Auth0's gateway solves a different problem from the other three. It isn't for an enterprise governing its employees' agents. It's for a SaaS company whose own product has an AI agent acting for customers across many tenants.
The gateway sits between your product's agent and the tools it calls. Each call is checked against the agent, the user and the user's organization, so an agent acting for one customer can't use another customer's Slack connection. It builds on Auth0 Organizations, Token Vault and token exchange to mint user-scoped tokens, while the agent itself gets a short-lived token that only works at the gateway. Every action goes to tenant logs, with optional SIEM streaming, and there's a kill switch.
Best for: SaaS teams building product-native agents on Auth0.
Watch for: it's in beta, and it's built for your product's agent. It isn't a way for your enterprise customers to govern the external agents calling your MCP server.
Microsoft Entra MCP firewall
Microsoft's approach is network-level. The MCP firewall is part of Global Secure Access, Microsoft's Security Service Edge, and inspects MCP traffic leaving managed devices. Admins write allow and block rules by MCP server, method, individual tool and protocol version, and enforce them with Conditional Access. Generative AI Insights logs each MCP operation, including tools/call, and can surface MCP servers nobody registered.
Best for: Microsoft-centric enterprises that want visibility and control over every MCP server employees reach, including ones IT never approved.
Watch for: there's no new endpoint for agents to point at. It requires the Global Secure Access client on an Entra-joined device, TLS inspection and an Entra Internet Access license. Microsoft's docs note that local MCP servers and stdio traffic aren't visible because they never cross the network. It also doesn't broker credentials, so it complements a credential-handling gateway rather than replacing one.
Other MCP gateways worth knowing
The four above are the newest, but they aren't the only options:
- Amazon Bedrock AgentCore Gateway. A managed gateway that turns APIs and Lambda functions into MCP tools and puts them behind one endpoint. It supports on-behalf-of token exchange through AgentCore Identity and added the MCP
2026-07-28spec on release day. - agentgateway. An open source proxy in Rust for MCP, agent-to-agent and LLM traffic. It's a Linux Foundation project and part of the Agentic AI Foundation. It handles tool federation and the MCP OAuth flow for several identity providers.
- Kong AI Gateway. Kong's AI gateway includes an MCP gateway alongside its LLM gateway, for teams already running Kong.
Where each gateway sits
The fastest way to see why these aren't interchangeable is to look at where each one sits in the request path.
Microsoft watches traffic as it leaves the device. Cloudflare and Okta give agents a hosted endpoint to call instead of calling servers directly. Auth0 lives inside a SaaS product, in front of the product's own agent. A large enterprise could reasonably run Microsoft's firewall and Okta's gateway at the same time.
Which MCP gateway should you use?
- You're on Cloudflare and want a curated set of MCP servers for employees: Cloudflare MCP server portals.
- You're standardized on Okta and need every tool call tied to a user and an agent: Okta Agent Gateway, once it's generally available for you.
- You're a Microsoft shop and need to find and control MCP servers nobody approved: the Entra MCP firewall, likely alongside one of the gateways above.
- You're on AWS and turning internal APIs into agent tools: AgentCore Gateway.
- You want to self-host on Kubernetes: agentgateway.
- You're building an agent into your own SaaS product: Auth0 Agent Gateway if you're on Auth0. Otherwise, the same building blocks (a token vault for connected accounts, policy per tool call, audit logs) are available separately. On WorkOS, Pipes keeps third-party tokens out of the agent's runtime with its Relay mode, and Airlock, in early access, checks agent actions against policy before they run.
Do you still need OAuth on your MCP server behind a gateway?
Yes. Every gateway above reduces how many places you configure access, but none of them makes your MCP server's own authorization optional.
The vendors say so themselves. Cloudflare warns that users can bypass a portal by using a server's direct URL. Okta's own post on agent security makes the broader point:
"Fundamentally, a gateway authenticates a key. It can't authenticate a person, and by the time a request reaches the actual resource [...] nobody downstream can tell the difference."
The MCP spec draws the same line. Tokens must be issued for the specific MCP server that receives them, and a server must not pass a client's token through to another service. A gateway that forwards traffic doesn't change who your server should trust.
If you're building an MCP server, assume your enterprise customers will put one of these gateways in front of it, and make sure it works well there:
If AuthKit is your authorization server, most of the left column is configuration. AuthKit's MCP support publishes the discovery metadata, supports Client ID Metadata Documents with DCR as a fallback, and issues tokens whose audience matches the MCP server URL you register. Cross App Access is in early access. Connect's machine-to-machine apps cover the no-user path, and Audit Logs records what each tool call touched, scoped to the customer's organization. We cover the rest of what sits under a gateway in The hard part of an MCP gateway is auth.
The takeaway
"MCP gateway" now covers at least three different things: a hosted catalog of MCP servers (Cloudflare, Okta), a network control on managed devices (Microsoft) and a policy layer inside a SaaS product (Auth0). Pick by where your agents run and which identity stack you already use, not by the name.
Whichever one your customers choose, the requests still end up at your MCP server. A gateway decides who gets to knock. Your server still decides who gets in.
Sources
- MCP server portals are now generally available
- MCP server portals
- Private MCP server support for MCP server portals
- New Okta for AI Agents innovations increase visibility into agent behavior, secure connections at runtime, and enforce continuous agent governance
- Introducing Agent Gateway: Runtime AI agent governance
- Agent Gateway
- Securing AI Agents Beyond the Gateway: Identity Architecture
- Auth0 Agent Gateway: The Identity Control Plane for Customer-Facing AI
- Configure Global Secure Access MCP firewall to secure Model Context Protocol traffic
- Generative AI Insights in Global Secure Access
- Amazon Bedrock AgentCore Gateway: A secure AI gateway for agents, tools, and models
- How AgentCore Gateway supports the MCP 2026-07-28 spec
- agentgateway/agentgateway
- Kong/guidance-for-kong-genai-mcp-and-a2a-gateways-on-aws
- What is MCP authorization? How OAuth works for AI agents
- The hard part of an MCP gateway is auth
- Model Context Protocol
- Pipes
- Audit Logs