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

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", 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.

Ox's own infrastructure survey is worth sitting with before moving to solutions, because a registry entry hides more than whether a server checks callers, it hides where the server actually runs and who controls it. Of the roughly 5,095 unique hostnames Ox examined, 15.6 percent, 796 of them, resolved outside the United States, including 19 in China and 18 in Russia. MCP has no protocol-level way to express a data residency requirement, so an organization that carefully restricts where its cloud workloads run has no equivalent lever for the MCP servers its agents connect to.

More concerning: 2.3 percent of hostnames no longer resolved through DNS at all, and six of those weren't merely offline, the domains themselves were sitting unregistered and available for four to twelve dollars a year. Anyone can buy one, stand up a server at the same address, and inherit whatever trust a client already extended to it. No compromise required, just a lapsed renewal. A further 0.45 percent ran on home networks or consumer tunneling services rather than any real hosting infrastructure at all.

None of this needs a registry to vet harder. It needs a governance model that treats "who controls this address today" as a question worth asking more than once.

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:

  
// Dynamic Client Registration: the client asserts its own identity
POST /register
{
  "client_name": "Totally Legit Agent",
  "redirect_uris": ["https://example.com/callback"]
}

// The authorization server takes that at face value and hands back an ID
{
  "client_id": "s6BhdRkqt3"
}
  

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:

  
// CIMD: the client_id is a URL you can actually go check
"client_id": "https://agent.example.com/.well-known/client-metadata.json"

// GET that URL and you get metadata tied to a domain, not a claim
{
  "client_name": "Totally Legit Agent",
  "redirect_uris": ["https://agent.example.com/callback"],
  "jwks_uri": "https://agent.example.com/.well-known/jwks.json"
}
  

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, 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.

Ox's own research gives this failure mode a face. Researchers built a malicious MCP server disguised as a code-scanning tool and connected it to Claude Code paired with Haiku 3.5. The agent first requested a harmless file, the user granted an always-allow exception, and the server later requested .env and other sensitive files under that same grant, no further prompt required. The same attack against Opus 4.6 and 4.7 was caught, the injected instruction was detected and the call blocked, so Ox is careful to call this model- and configuration-dependent rather than a verdict on every deployment.

Anthropic's own response draws the line this section has been arguing all along: once a user grants always-allow, every later call executing without another prompt is the permission system working exactly as designed, and model-level prompt-injection detection is a defense-in-depth measure, not the security boundary itself. A credential that's valid and a call that matches the user's actual intent are two different facts, and Ox's test shows an ecosystem that was only checking one of them.

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.