Dora NodaSix trusted MCP server domains are sitting unregistered right now, available for about the price of a coffee. Anyone who buys one inherits the trust every agent that ever connected to it.
That is one finding from research OX Security published on September 24, 2026, an analysis of 15,465 published MCP servers distilled in its report "15,465 MCP Servers, 0 Governance." The headline is not a vulnerability in any single server. It is that the whole tool layer AI agents reach through sits outside the governance controls enterprises spent a decade building around their cloud environments — no geographic boundaries, no operator identity, no attestation that the code running behind a live server matches its published source.
This post states the census findings with their exact numbers, names the protocol gaps that make them possible, walks the Always-Allow attack OX demonstrated step by step, and turns each finding into a concrete control for governing a deploy-from-chat tool fleet.
What OX found: the census in one table
OX reduced 15,465 published servers to 5,095 unique hostnames and mapped where agents actually connect. Every number below comes from the published findings:
| Finding | Number |
|---|---|
| Hostnames resolving outside the US | 796 of 5,095 (15.6%) |
| …in China | 19 |
| …in Russia | 18 |
| Routed via consumer ISP networks or personal tunneling tools | 0.45% of hostnames |
| No longer resolving (dead) | 2.3% of hostnames |
| …unregistered and purchasable | 6 domains, $4–$12/year |
Always-Allow permission escalated to unauthorized .env access | Demonstrated on Claude Code + Haiku 3.5; blocked on Opus 4.6/4.7 |
Two quotes from the researchers frame the table. CEO Neatsun Ziv: enterprises built a decade of cloud security around infrastructure they could see and control, and agents are now reaching beyond those boundaries. Research lead Moshe Siman Tov Bustan, on why marketplace servers resist validation: you can inspect the code, but the server might run a different version — and you do not know who controls it, what data it collects, or what a future update changes.
Read the rows as four distinct failure modes, because each demands a different control. Data-residency blind spots (the 796) are a compliance problem: MCP has no protocol-level mechanism to enforce geographic boundaries, so an agent handling regulated data can silently route it to infrastructure your auditors never approved. Home-network routing (the 0.45%) is an access-control problem: enterprise AI workflows flowing through a consumer tunnel sit outside centralized authentication and audit logging.
Dead domains (the 2.3%, and specifically the six) are a takeover problem: an attacker who spends $4 inherits a trusted endpoint's reputation with every agent configured to call it. And the Always-Allow escalation is a permission-model problem — the one worth walking through in full, because it interacts badly with a policy change that shipped seven days before this report.
Why MCP has no immune system for this
MCP, introduced by Anthropic in November 2024, is an open standard for connecting agents to tools and data. What OX's findings make concrete is everything the standard deliberately does not establish: where a server should run, who should operate it, what data it may receive, or whether the deployed code matches the published source. Those decisions fall entirely on whoever connects.
That is not a design oversight anyone missed — it is the same shape as the early web, where TLS, certificate transparency, and content security policies arrived years after the first pages. The difference is the timeline pressure: a May 2026 preprint measuring nearly 8,000 live remote MCP servers found around 40% exposed tools with no authentication mechanism at all.
The ecosystem is scaling past fifteen thousand published servers while two in five live ones still have no front door. (A separate 453-server sample scored 16.3 out of 100 on code hygiene — a different lens on the same ungoverned supply chain.)
So treat OX's four gaps as the checklist the protocol leaves blank and operators must fill themselves: geographic enforcement, operator identity, data-collection disclosure, and deployed-code attestation. None has a protocol primitive today. Every control in the matrix below is an operator-side substitute for one of them.
The Always-Allow attack, step by step
The report's most actionable finding is a live demonstration, not a statistic. In security testing with Claude Code paired with Haiku 3.5, a malicious MCP server executed this chain:
- The agent requests a benign file read. The user grants it Always-Allow — never ask again for this kind of request.
- The malicious server returns tool output carrying a prompt injection.
- The agent, following the injected instructions, reads a sensitive
.envfile. - No secondary confirmation appears. The original Always-Allow permission covers the escalation, and the secrets leave without the user ever seeing a second prompt.
The same attack run against Opus 4.6 and 4.7 was detected and blocked. Your permission model's strength currently depends on which model answers — a defense that varies by SKU is a policy gap wearing a capability's clothes.
Here is why the timing stings. On September 17, 2026 — seven days before OX published — GitLab 19.4 shipped MCP tool classification by annotation: tools marked read-only default to Always Allow and, in GitLab's own words, "execute silently without prompting the user." The intent is reasonable: routine lookups should run without interruption.
But OX's chain starts exactly there, at a silently-executing read whose output the agent then obeys. Annotation-based auto-allow assumes the tool's declared behavior bounds its actual behavior — and Bustan's core warning is that a live server's behavior is precisely what you cannot verify. Every platform copying GitLab's default this month should read the OX chain as the threat model for that default: silent reads are only safe when the reader cannot be instructed by what it reads.
Governing a deploy-from-chat tool fleet
Each control below answers one row of the census table. Together they are the minimum for letting agents touch anything that deploys:
| Census finding | Control |
|---|---|
| 796 hostnames outside the US (19 China, 18 Russia) | Geo-pinned hostname allowlist: enumerate every MCP hostname your agents may reach, resolve and pin the set, and refuse connections outside approved regions. Residency is enforced at the egress proxy, not requested of the protocol. |
| 0.45% via home networks and tunnels | Refuse consumer-tunnel endpoints: no *.trycloudflare.com, ngrok-style, or residential-ASN hosts in the allowlist. A deploy tool that lives behind someone's tunnel is not infrastructure. |
| 2.3% dead, 6 domains buyable for $4 | Dead-domain watch plus pinned server identity: monitor allowlisted hostnames for lapsed registration, and pin each server to a version hash or image digest so a resurrected domain serving new code fails closed instead of inheriting trust. |
Always-Allow → .env without re-confirmation | Tiered approvals with an annotation audit: reads may auto-allow only from allowlisted servers whose annotations you verified yourself; anything that sends, publishes, pays, or deletes needs per-action approval, always — and re-audit annotations on every server update, since the update is unverified by default. |
Three notes on operating this matrix. First, the allowlist is the load-bearing control: without it, the other three have nothing to attach to, because MCP gives you no discovery primitive that distinguishes your blessed servers from fifteen thousand strangers.
Second, pinning must cover the deployed artifact, not just the source repo — the report's "different version behind the live server" warning means a source-vendored hash is necessary but not sufficient; prefer servers you host or whose images you mirror. Third, budget for the update treadmill explicitly: every server update re-opens the attestation question, so the annotation audit and hash re-pin belong in the same change ticket as the version bump, not in a quarterly review.
Verdict: the deploy rule
OX's census says the tool supply chain your agents browse is geographically unbounded, partially homeless, partly dead and purchasable, and one silent permission away from your secrets — and the protocol offers no primitive to fix any of it. The operator-side answer is the matrix above: allowlist the hostnames, pin the geography, refuse the tunnels, watch the dead domains, pin the artifacts, and tier the approvals with annotations you audited yourself.
One line to carry into your next deploy-tool review: no MCP server that is not allowlisted, pinned, and approval-tiered touches a production deploy. Everything else is a demo with credentials.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Governed agent tooling starts with infrastructure you control: star the repo on GitHub or deploy your first app today.
Sources
- OX Security via PR Newswire, "New Research: MCP Servers Connect AI Agents to China, Russia, Home Networks and Abandoned Domains" (September 24, 2026) — 15,465 servers, 5,095 hostnames, all four key findings, researcher quotes.
- OX Security report, "15,465 MCP Servers, 0 Governance" (ox.security) — full methodology and threat scenarios.
- Unite.AI, "OX Security Finds MCP Servers Reaching China, Russia and Home Networks" (September 24, 2026).
- ByteHide, "MCP Security Considerations: The Complete 2026 Guide" — May 2026 preprint: ~8,000 live remote servers, ~40% without authentication.
- Automater Intel on GitLab 19.4 (September 17, 2026) — annotation-based MCP tool classification, read-only defaults to Always Allow.
- aiagentslibrary.com, "The MCP Security 7-Point Checklist (2026)" — per-action approval for send/publish/pay/delete tools.
