What 15,465 ungoverned MCP servers tell us about the authorization gap

Ox Security's registry audit, published in a report titled "15,465 MCP Servers, 0 Governance," counted 15,465 MCP servers across the official MCP registry, the Cline marketplace, and the GitHub MCP registry and found zero with consistent, checkable governance. The audit attributes the gap to MCP leaving authentication and authorization to each implementation, and points to the 2026-07-28 spec revision that replaced Dynamic Client Registration with Client ID Metadata Documents, which WorkOS Connect has supported since before that revision shipped.

What 15,465 ungoverned MCP servers tell us about the authorization gap A new registry audit counted servers, not security controls. The number matters more than it sounds like it should. Ox Security spent the past few weeks doing something nobody running an MCP registry seems to have done yet: counting. Not servers listed, but servers governed. The result, published this week in a report titled "15,465 MCP Servers, 0 Governance" https://www.ox.security/ebooks/15465-mcp-servers-0-governance/ , pulls from three public registries, the official MCP registry, the Cline marketplace, and the GitHub MCP registry, and finds the same thing in each: a growing catalog of tool-providing servers with no consistent authorization model, no lifecycle accountability, and no way for an enterprise to tell, from the registry entry alone, whether a server enforces access control at all. That number is worth sitting with. Fifteen thousand is not a long tail of abandoned side projects. It is the current shape of the MCP ecosystem, and it is growing faster than the governance conversation around it. 15,465 MCP servers across three registries. Zero with consistent, checkable governance. Registries answer "does it exist," not "should you trust it" A registry entry tells you a server's name, its publisher, maybe a README. It does not tell you whether the server checks who is calling before it runs a tool. That distinction sounds obvious once stated, but it is exactly the gap that keeps showing up in MCP security research this year. Independent scans have repeatedly found MCP servers answering tools/list with no login wall at all, because the discovery step in MCP is unauthenticated by design in most implementations. A registry listing and an open port are not the same claim, but from the outside they can look identical: both say "this exists and you can point a client at it." Ox Security's contribution is to make that gap a number instead of an impression. Zero governance, across three registries, at the scale the ecosystem has already reached. Why this is an authorization problem, not a discovery problem It is tempting to read "0 governance" as a call for better vetting: registries should check servers before listing them, the way an app store reviews submissions. That would help, but it treats the symptom. The actual failure mode is that MCP, as a protocol, was built to make tools easy to discover and easy to call, and left authentication and authorization to each implementation. A server author has to decide, on their own, to gate tools/list , to validate the caller's identity before tools/call , to scope what a given caller can do once connected. Most of the fifteen thousand did not make that decision, or made it inconsistently. That is not a registry defect. It is what happens when a protocol ships a capability model without a matching identity model, at the speed MCP has shipped. What actually closes this gap The protocol side has started to answer this, and it is worth being specific about what exists today rather than what is still a proposal. Client registration. Dynamic Client Registration let any caller register itself as a client with no verification step, which is part of how registries end up full of servers nobody vetted. A client under DCR just states who it is: Client ID Metadata Documents replace the assertion with something checkable. The client id itself is a URL, and dereferencing it returns metadata the client's owner is accountable for, hosted on a domain they control: Same fields, different trust model: one is a statement, the other is a lookup. The MCP spec named CIMD as DCR's replacement in the 2026-07-28 revision. WorkOS Connect has supported CIMD resolution since before that revision shipped. Enterprise-managed authorization . For the servers an enterprise actually depends on internally, the fix is bringing in the identity provider both sides already trust. An admin authorizes a client to reach an MCP server once, through the IdP, and every later exchange is a token redemption governed by that policy rather than a fresh consent screen or a static key. This reached Stable status in MCP as an extension in June 2026. AuthKit accepts these assertions from enterprise identity providers today. Agent registration. Client identity and admin policy do not answer who is behind an agent when it shows up with no account at all. That is a separate, earlier problem: establishing a verified user before you provision anything. auth.md https://workos.com/auth-md , the open agent-registration protocol WorkOS authored, is built for exactly that gap, and it needs no WorkOS account to publish or read. Runtime policy. None of the above stops an authorized, correctly identified agent from doing something it should not. A tool call can be exactly the access an agent was granted and still be the wrong thing to do with it. That is the problem WorkOS Airlock evaluates against, checking an agent's declared intent and your policy before a governed call proceeds, not just whether the caller and the credential match. The gap Ox Security measured is closing, unevenly Put together, these are not four competing products solving the same problem. They are four different points in an agent's lifecycle, and a server or platform can get any one of them right while leaving the other three exactly as ungoverned as the fifteen thousand Ox Security counted. That unevenness is probably a better description of the current state of MCP than "0 governance" is: governance is not absent everywhere, it is inconsistently present, which from an attacker's perspective is close enough to absent to matter. The number will change. What will not change as quickly is whether the servers being counted next time were built against a protocol-level identity model or built the way most of this year's fifteen thousand were: fast, functional, and ungated by default.