The scan: 15,465 live MCP servers
OX Security conducted a scan of 15,465 live MCP servers discovered through public registries and developer community references. The headline numbers: 15.6% are hosted on infrastructure in non-US jurisdictions, including servers in China and Russia. Another 2.3% resolve to domains that are abandoned or unregistered, meaning any actor that re-registers the domain gains control of a trusted MCP server that developers are actively connecting their AI agents to.
There is no native protocol mechanism in MCP that enforces data residency, validates server provenance, or attestates trust. An MCP client trusts any server it is configured to connect to. The protocol is designed for capability discovery and invocation, not for governance.
The injection finding
OX Security tested prompt injection against Claude Code using two model configurations. With Haiku 3.5 in "Always-Allow" mode, a malicious tool description embedded in a connected MCP server's manifest successfully exfiltrated tool definitions from other connected servers. The attack required no special access. The injected prompt instructed the model to read and relay the tool list from the other connected server.
Testing against Opus 4.6 and 4.7 did not reproduce the exfiltration. Those models refused the injected instruction. The practical implication: the attack surface is model-dependent, and the same MCP server configuration is either safe or vulnerable depending on which model processes it.
What the governance gap means in practice
Developers treat MCP servers like npm packages: if it is listed in a registry and has a reasonable description, it gets connected. Unlike npm, there is no signature verification, no provenance chain, and no sandboxing of what a server can read from other connected tools. A compromised or malicious MCP server can observe all tool interactions in the session.
For teams building on MCP today: the gap is real and the protocol will not close it soon. The best current control is an allowlist of approved MCP servers with domain pinning. If a server's domain changes ownership, it drops off the allowlist and requires explicit re-approval. ASN pinning adds a second layer: a server that moves to a new cloud provider triggers a review.
Recommended controls
Maintain an approved-server allowlist with domain and ASN pinning at the client configuration layer. Audit the list quarterly and after any MCP ecosystem update. Use Opus-class models for sessions that connect to external MCP servers. Avoid "Always-Allow" mode in any environment where the MCP server list is not fully controlled. Review the OX Security report for the full list of flagged server categories and apply their scanner to your own server inventory.
Gigia Tsiklauri is a Security Architect and AI Security practitioner focused on AI-era threat modeling and secure SDLC. Get in touch