- OX Security analyzed 15,465 public MCP servers, reduced to 5,095 hostnames. It found 15.6% resolved outside the US, 0.45% tied to home or tunneling setups, and 2.3% no longer resolving.
- OX argues MCP has no built-in way to control where connected tools run or where data goes, so agent connections can fall outside cloud governance.
- Treat every MCP server an agent calls as a supplier: inventory them, approve them, and review standing permissions.
A tool server is a supplier, signed contract or not
Cloud adoption forced companies to write rules. Where may data sit? Who may reach it? Which vendors get audited? The argument here is that the tool servers an AI agent calls deserve the same scrutiny, because they receive company data much as a vendor does.
New research from OX Security shows why the question is open. OX argues that MCP connections often sit outside an enterprise's cloud governance. That is OX's argument, not a measured result. The audit measured where servers are hosted. It did not examine how any company manages its connections.
MCP, the Model Context Protocol, is a standard for linking AI models and agents to tools and data. OX's research team examined 15,465 servers listed in five public registries. It reduced them to 5,095 unique hostnames. The percentages below apply to those hostnames, not to servers. OX sells security products, and its full method is in its report. This story uses only the findings OX has published.
Where the servers actually run
OX found that 15.6% of hostnames resolved to infrastructure outside the US. That includes 19 hostnames in China and 18 in Russia. Set against 5,095 hostnames, those two counts are small. Most of the non-US share therefore sits in other countries, which the source does not name.
OX warns that data an agent sends to such servers could land in a jurisdiction the security team never approved. Location alone does not show misuse. The concern is that nobody decided it. OX says MCP has no built-in way to enforce where a connected tool runs or where data is processed.
A snapshot also ages. OX points out that a server could start on a clean-looking US address and have its traffic redirected later.
Three ways a connection goes wrong
The first is personal machines. OX found 0.45% of hostnames tied to home networks or consumer tunneling tools, mainly ngrok-free. That is a small share. OX says these listed servers likely run from personal computers. Agent workflows that call them reach beyond the corporate network.
The second is abandoned domains. Another 2.3% of hostnames no longer resolve. This share is also small. Six of them point at lapsed registrations that cost $4 to $12 a year to claim. OX says a new owner would inherit the server's identity. Any agent still set up to call it would send requests to that owner.
The third is a gap between code and reality. OX says a remotely hosted server may run backend code that looks nothing like its public repository. A code review shows what the developer published. It does not show what is running.
One approval, reused by an attacker
OX also ran a prompt injection test against Claude Code. Prompt injection hides instructions in content an AI reads, so the AI follows them. The model in the test was Haiku 3.5. The user granted one "Always-Allow" permission. A malicious MCP server then used prompt injection to reach privileged files without asking again.
The identical attempt against Opus 4.6 and 4.7 did not succeed. This is one test setup, and OX reports results only for those models.
The point for risk teams is a possible implication, not a settled finding. A permission given once can keep working after the moment it was granted. A defense that depends on which model an employee happens to use would be hard to audit.
No gatekeeper at the door
OX points to Bouncer, the automated scanner Google ran in 2012 to check Android apps for malware. Researchers got malware past it. Even so, a check existed. OX says MCP marketplaces have nothing comparable, and any author can release a server without review.
That pushes the checking onto the buyer. OX's conclusion: until marketplaces add vetting, code signing and origin verification, enterprises must do that work themselves.
Questions to put to your teams
Start with an inventory. Which MCP servers do your agents and developer tools call today, and who approved each one? If nobody can answer, that is the first finding.
Then ask where each server runs and who owns its domain. Ask whether any run from a personal machine or tunnel. Ask whether anyone checks that domains still belong to their original owners.
Finally, review standing permissions. Find out where staff have granted always-allow rights to servers your company does not operate.
An agent is only as trustworthy as the least-checked server it calls. The rules for cloud suppliers already exist. They now need to cover the tools your agents reach for.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: OX Security.
