WorkOS compares the September 2026 MCP gateway wave — Cloudflare portals, Okta Agent Gateway, Auth0 Agent Gateway, and Entra's MCP firewall — and then names what none of them remove: authorization on the MCP server itself. Putting a gateway in front is not an authorization strategy.

What WorkOS Published

On October 1, 2026, WorkOS published MCP gateways compared: Cloudflare, Okta, Auth0 and Microsoft. Status as of that date:

  • Cloudflare MCP server portals — generally available September 24, 2026.
  • Okta Agent Gateway — GA planned for Q3 2026; research release since July.
  • Auth0 Agent Gateway — beta September 18, 2026.
  • Microsoft Entra MCP firewall — public preview (since August).

The products share a name and a pitch. They sit in different places in the request path and are built for different buyers.

Four Seats In The Path

  • Cloudflare — a hosted catalog. Several MCP servers behind one URL, Cloudflare Access in front, tools curated per portal. Built for employees' agents reaching approved servers.
  • Okta — a hosted virtual MCP server. Policy on every tool call; agents never hold upstream credentials (Cross App Access or brokered consent). Built for enterprise agents reaching enterprise tools.
  • Auth0 — in-product, between a SaaS company's own agent and its tools, checked against the user's organization. Built for product-native agents, not for enterprise customers governing external agents that call your MCP server.
  • Entra MCP firewall — network SSE inspection through Global Secure Access. Allow or block by server, method, tool, and protocol version. No new endpoint; local / stdio traffic is not visible; credentials are not brokered.

WorkOS's map: Microsoft watches traffic as it leaves the device. Cloudflare and Okta give agents a hosted endpoint. Auth0 lives inside a SaaS product. A large enterprise could run Microsoft's firewall and Okta's gateway at the same time.

The Server Still Decides Who Gets In

Cloudflare's docs, quoted by WorkOS, are direct about portal limits: blocked users can still connect to the server — and bypass Access policies — by using its direct URL. If you want Access enforced, configure Access as the server's OAuth provider.

WorkOS also quotes Okta on the broader point: a gateway authenticates a key. It cannot authenticate a person, and by the time a request reaches the actual resource, nobody downstream can tell the difference.

The MCP spec line WorkOS restates: 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.

What The MCP Server Still Must Do

WorkOS's operator table for a server sitting behind any of these gateways:

  • Publish standard OAuth discovery metadata.
  • Support Client ID Metadata Documents, with pre-registered clients as a fallback.
  • Accept ID-JAG token exchange where enterprises use it.
  • Validate token audience on every request.
  • Enforce scopes per tool — a gateway can hide a tool; only the server can refuse the call.
  • Offer a machine-to-machine path for agents with no user to sign in.
  • Emit your own audit events. Customers will want your side of the record, not only the gateway's.

What The Comparison Does Not Prove

  • Status dates and GA plans are WorkOS's October 1, 2026 snapshot. Check current vendor status before planning around Okta's Q3 target.
  • WorkOS also names Amazon Bedrock AgentCore Gateway, the Linux Foundation agentgateway project, and Kong AI Gateway as other options. This note stays on the four-way September wave.
  • A gateway comparison is not registry governance, SDK hardening, or MCP Events subscriptions.

Related: See our notes on ungoverned MCP registries and gateway admin auth and WorkOS Airlock.