----------------
🎯 AI
===================
OX Security published a research report covering 15,465 published MCP servers and 5,095 unique hostnames. The short version: the Model Context Protocol ecosystem has no native governance for data residency, domain lifecycle, or permission persistence, and a prompt injection test against Claude Code succeeded under one specific model configuration.
🔹 Research Scope
The team enumerated 15,465 published MCP servers and resolved 5,095 unique hostnames behind them. Coverage falls into three buckets: geolocation of resolved infrastructure, domain registration and resolution state, and servers sitting on consumer-grade network paths. A separate test checked whether a granted permission in Claude Code survives a subsequent prompt injection.
🔹 Key Findings
• Data residency: 15.6% of analyzed hostnames resolved to infrastructure outside the US, including infrastructure in China and Russia. MCP currently provides no native protocol mechanism to enforce where connected tools run or where data is processed, so residency enforcement is left entirely to the deploying side.
• Consumer infrastructure: 0.45% of hostnames were associated with home networks or consumer tunneling tools. Agent workflows can therefore reach endpoints that never crossed corporate network controls, which breaks standard visibility assumptions.
• Domain takeover: 2.3% of hostnames failed to resolve. Six of the underlying domains are unregistered and available for around $4 per year. If MCP clients or workflows keep trusting and calling those names, whoever registers them can stand up a matching server and inherit the traffic. It is the classic dead-domain takeover problem, showing up one layer above the web.
• Permission persistence: In testing against Claude Code with Haiku 3.5, a single 'Always-Allow' grant was enough for a malicious MCP server to follow up with prompt injection and execute privileged file access without another user confirmation. The same attack did not succeed against Opus 4.6 or 4.7, so the result appears model-dependent, and it comes from the vendor's own testing.
🔹 Analysis
The takeover finding is the mechanically simplest one. Published MCP server listings operate as a de facto trust directory, but nothing in the protocol verifies that a hostname still belongs to its original operator. A handful of $4 registrations is close to the cheapest infrastructure acquisition available, and the public summary describes no pinning or allowlist control that would stop it.
The residency numbers matter mostly because agent workflows call these hostnames automatically. If a connected tool resolves to infrastructure in a jurisdiction the organization never approved, nothing in MCP surfaces that to the user or the admin at connection time.
The Claude Code result deserves the most caution. Permission scoping, exact prompts, and injection payloads are not described in the public summary, and the gap between Haiku 3.5 and Opus 4.6/4.7 has no published root cause. It is a reasonable hypothesis that smaller models tolerate injected instructions over an existing allow, but that is a hypothesis, not a confirmed mechanism.
🔹 Operational Notes
Translating findings into checks: inventory which MCP hostnames your clients actually resolve, geolocate them, flag anything dead or sitting on consumer tunneling, and review how client-side 'Always-Allow' grants are scoped. None of that is enforced by MCP itself today. The report does not publish a defense list in the summary, so these are the checks its own findings point at.
🔹 Limitations
This is vendor research from OX Security. The public summary omits the full methodology, the hostname list, and any detection coverage. The percentages should be treated as indicative until reproduced, and the prompt injection result has not been independently tested.
🔹 MCP #AISecurity #PromptInjection #ModelContextProtocol #SupplyChain
🔗 Source: https://www.ox.security/ebooks/15465-mcp-servers-0-governance/
