15,465 MCP Servers and Almost No Governance

15,465 MCP Servers and Almost No Governance

MCP was supposed to be the USB-C of AI: one standard for plugging models, agents and IDEs into tools and data. The protocol largely delivered. Thousands of developers built servers for it, and enterprises wired those servers straight into agent workflows. What never arrived was the part that usually comes with growth — a bouncer at the door.

OX Security Research published a survey of the ecosystem on September 24, 2026, analyzing 15,465 published MCP servers and narrowing them to 5,095 unique hostnames for infrastructure analysis. The headline number is the easy part. The uncomfortable part is what those hostnames resolve to.

A marketplace with no bouncer

Back in 2012, Google ran Bouncer, an automated scanner that checked Android apps for malware before they reached users. It wasn't perfect — researchers slipped malware past it — but it existed. MCP marketplaces have no equivalent. Anyone can write a server, push it, and publish it.

The OX researchers argue that even a review would not close the gap. Remote MCP servers can run backend code that differs completely from what their public repository shows. Code review tells you what the developer published, not what the server actually executes. The team previously presented "In GitHub We Trust: 10 Ways You Can Get Pwned" at RSAC and OWASP, and they see the same over-trust repeating here. This is also OX's second pass at the protocol: earlier in 2026 the team traced critical vulnerabilities in Anthropic's MCP source code, which has been downloaded more than 150 million times. If you want the mechanics of how that over-trust gets abused, my earlier post on MCP tool poisoning walks through the attack surface.

What the numbers actually say

The survey is worth reading carefully because the percentages are small and the consequences are not:

• Infrastructure without borders. 15.6% of the analyzed hostnames — 796 of 5,095 — resolve to infrastructure outside the United States, including 19 in China and 18 in Russia. MCP has no protocol-level concept of geographic region, so an enterprise can enforce strict residency on its own cloud workloads while its agents happily call servers beyond those boundaries.
• Production traffic on consumer infrastructure. About 0.45% of hostnames route through home networks and consumer tunneling services, mainly ngrok-free. That means production agent workflows depending on infrastructure with no uptime guarantee, no enterprise access controls, and no real audit trail.
• Abandoned domains, live risk. 2.3% of hostnames no longer resolve. Six of them were unregistered and available for $4 to $12 a year. Buy one, and you inherit a server identity that some agent config somewhere may still be calling.

That last point is the one to sit with. A dangling MCP hostname is not just a dead link; it's a takeover target priced like a domain registration. And location is not permanent either: an operator can stand up a server on a clean US IP address today and quietly route traffic somewhere else tomorrow, so any residency check is a snapshot, not a guarantee.

The prompt injection that outlives one click

The most concrete finding is also the simplest to reproduce. The researchers tested a malicious MCP server against Claude Code paired with Haiku 3.5. The server first asked for access to a harmless file. The user approved it with an always-allow permission. The server then requested a sensitive file — .env among them — and got it, with no further prompt required.

The same attack failed against Opus 4.6 and 4.7, which the report attributes to stronger model-level detection. Anthropic's response, as summarized by OX, is that once always-allow is granted, that is the documented behavior, and model-level detection of malicious content is a best-effort heuristic, not a security boundary. That distinction matters. A permission you granted once is a permission the server keeps, regardless of how convincing any single model is at spotting a bad request.

The report is careful not to overstate this: it is a finding about the permission model, not proof that every agent will hand over .env. But the asymmetry is the point. One approve click authorizes the class of action, and revoking it is a manual step that nobody remembers to take. Every MCP server you have ever clicked through is still holding whatever you granted it that day.

Audit your own MCP config

You cannot govern what you have not inventoried. Most teams have MCP servers scattered across editor configs, project files and CI settings. Here is a small pure-Python script that reads an MCP config and flags the infrastructure you may not actually control:

#!/usr/bin/env python3
"""Flag remote MCP servers in a config whose infrastructure you don't control."""
import json
import socket
import sys
from urllib.parse import urlparse

CONSUMER_TUNNELS = ("ngrok.io", "ngrok-free.app", "loca.lt",
                    "localtunnel.me", "trycloudflare.com")

def host_of(entry):
    if isinstance(entry.get("url"), str):
        return urlparse(entry["url"]).hostname or ""
    for arg in entry.get("args", []):
        if isinstance(arg, str) and arg.startswith(("http://", "https://")):
            return urlparse(arg).hostname or ""
    return ""

def main(path):
    servers = json.load(open(path)).get("mcpServers", {})
    dead = []
    for name, entry in servers.items():
        host = host_of(entry)
        if not host:
            print(f"  [local]  {name}: stdio server, no remote host")
            continue
        tag = "consumer-tunnel" if host.endswith(CONSUMER_TUNNELS) else "remote"
        try:
            ip = socket.gethostbyname(host)
            print(f"  [{tag}] {name}: {host} -> {ip}")
        except socket.gaierror:
            dead.append(name)
            print(f"  [DEAD]   {name}: {host} does not resolve")
    print(f"\n{len(dead)} unreachable server(s) still wired into your config.")

if __name__ == "__main__":
    main(sys.argv[1] if len(sys.argv) > 1 else "mcp.json")

Run it across every mcp.json and claude_desktop_config.json you can find. A [DEAD] line is a dangling domain someone could register tomorrow; a [consumer-tunnel] line is a server running on somebody's laptop. Neither belongs in an enterprise agent path by accident.

What good discipline looks like

None of this is a reason to abandon MCP. It is a reason to treat MCP servers like the third-party dependencies they are:

• Inventory every server. Record the hostname, who operates it, and where the code runs. If you can't answer "who owns this domain?", you don't have governance.
• Prefer self-hosted or pinned servers for anything touching credentials or production data. A remote server whose repo you reviewed is still a remote server.
• Kill blanket always-allow. Grant scoped, per-resource permissions, and treat every remote server as untrusted even after one approval.
• Watch DNS egress. An agent reaching a host outside your approved set is the cheapest possible signal, and it catches the case where a server's location changes after you approved it.

The protocol isn't the problem. The trust we hand it is. Until marketplaces add vetting, code signing and origin verification, the enterprise has to do that work itself — and the inventory is where it starts.

Sources

• OX Security: How MCP Is Bypassing a Decade of Cloud Security Best Practices
• OX Security: 15,465 MCP Servers. 0 Governance.
• The Hacker News: Welcome to the Jungle: What We Found Inside 15,465 Public MCP Servers