WorkOS pairs an Ox Security registry audit — 15,465 MCP servers, zero checkable governance — with Bifrost gateway flaws where an unauthenticated management call could run a command before any MCP handshake. Pointing an agent at a registry-listed server is not an authorization decision.

What WorkOS Published

On September 29, 2026, WorkOS published two companion posts: What 15,465 ungoverned MCP servers tell us about the authorization gap and Bifrost's MCP flaw.

Ox Security's report title, as cited by WorkOS, is "15,465 MCP Servers, 0 Governance." The count pulls from the official MCP registry, the Cline marketplace, and the GitHub MCP registry. WorkOS's line is: Ox counted servers listed, not servers governed.

Registries Answer Existence, Not Trust

A registry entry tells you a name, a publisher, maybe a README. It does not tell you whether the server checks who is calling before it runs a tool. WorkOS notes that discovery is often unauthenticated by design in current implementations, so a listing and an open port can look the same from the outside.

WorkOS also restates Ox hostname findings from the same audit: of about 5,095 unique hostnames, 15.6 percent (796) resolved outside the United States, including 19 in China and 18 in Russia; 2.3 percent no longer resolved; and six of those domains were sitting unregistered. Those figures are Ox's, cited by WorkOS — not Institute measurements.

Bifrost: Management Auth Off By Default

The companion post covers JFrog's September 2026 disclosures against Bifrost, an open-source AI gateway. CVE-2026-90898 (CVSS 9.8, disclosed September 14) let an unauthenticated caller register an MCP stdio client and run an attacker-supplied command as the gateway process. WorkOS says there was no MCP handshake first: registration and execution were the same event.

A earlier issue the same month, CVE-2026-86242, covered unauthenticated custom plugin registration. WorkOS traces both to the same design: the management API ships with authentication disabled by default, and the official Docker image bound that API to 0.0.0.0.

WorkOS is precise about the layer. Dynamic Client Registration and Client ID Metadata Documents are about how an agent proves identity to an OAuth server. Bifrost's /api/mcp/client path is an admin operation that adds a tool-providing server to the gateway's own configuration. Fixing one does not fix the other.

The Root WorkOS Names

MCP defines tool providers and tool consumers in careful detail. It says much less about the management surface that decides which servers a gateway trusts. That surface is ordinary application infrastructure sitting next to an MCP-speaking service, and it ships with sane defaults or it does not.

What Operators Should Change

  • Do not equate "listed" with "governed."
  • Treat MCP connect allowlists as policy, not as a catalog browse.
  • Harden gateway and admin surfaces: authentication on by default, no internet-bound management ports.
  • Scope who may register a tool provider, and check what the registration actually executes before it runs.

What The Posts Do Not Prove

  • 15,465 / zero checkable governance is Ox's cited count across three registries, restated by WorkOS. It is not an Institute census.
  • Bifrost's CVEs are one gateway's management-plane defaults. WorkOS presents them as a pattern, not as a protocol-layer hole the MCP spec can close by itself.
  • This is registry plus management-plane auth. It is not Airlock runtime intent.

Related: See our notes on WorkOS Airlock and MCP TypeScript SDK 2.1.0 DPoP and scope challenges.