Ox Security: Nearly 16% of Analyzed MCP Hostnames Resolve Outside the US

Ox: residency controls stop where the agent's connections begin

Ox Security argues that data-location rules can hold for the workloads a company hosts and still say nothing about where an AI agent's tool calls end up. Infosecurity Magazine reported the research on September 28, 2026. It draws on three public registries of MCP servers: the official MCP registry, Cline's marketplace and GitHub's MCP registry. The report's title, "15,465 MCP Servers, 0 Governance," sums up its argument.

Model Context Protocol (MCP) is a standard that lets AI applications connect to external tools and data without custom integration code. Ox argues that this convenience may carry a cost. Ox claims this may expose organizations to risks that residency requirements, zero trust boundaries and IAM policies are meant to mitigate. In the report's words, "MCP has no protocol-level concept of geographic region." Ox describes a scenario in which an enterprise enforces strict residency controls on its own cloud workloads while its agents "connect freely to servers sitting outside those same controls."

What the analysis does and does not show

The 16% figure applies to the 5,095 unique hostnames Ox analyzed, not to all 15,465 servers in the report's title. The source does not explain the gap between the two numbers. The hostnames come from public registries, not from every MCP server in use, and Ox names Russia and China among the countries where some resolved. Resolving abroad is not evidence of malicious intent. It is a residency and jurisdiction question, and a budget-holder with data-location obligations needs to know whether agent traffic falls under them. The findings are Ox Security's own, and the source does not mention independent replication.

Abandoned addresses that someone else can buy

Ox also found that over 2% of the hostnames no longer resolve. Some are currently unregistered and available to purchase. According to the report, a threat actor could buy one and impersonate the server it used to point to. The source describes this as a possibility and does not report an observed takeover.

One approval, then no further prompts

Ox tested Claude Code with Haiku 3.5 against a malicious MCP server. In the test, the server opened with a request for an innocuous file, and the user approved it with an "always-allow" permission. The same server then requested a sensitive file, .env among them, and received it without a further prompt. Ox says Anthropic's reply was that once always-allow is granted, this is the documented behavior, and that model-level detection of malicious content is a best-effort heuristic rather than a security boundary.

Separately, in April 2026, Ox released a report on what it described as a "critical, systemic" vulnerability in MCP tied to Anthropic's official MCP SDKs. Anthropic dismissed the report as "expected behavior," leaving the AI supply chain to work on fixes for the individual open source projects affected. These are two Ox-reported cases, not a measured trend. In both, Anthropic characterized the behavior as expected or documented, which means deploying organizations should not assume the vendor will add the guardrail.

Questions to put to your team

1. Do we hold an inventory of every MCP server our agents and developer tools connect to, with each hostname and the country it resolves to?

2. Who approves a new MCP connection, and is there an allowlist, or can any developer add a server from a public registry?

4. Do we check the MCP endpoints we configured for domains that have lapsed or changed hands?

5. Does our data residency policy name AI agent traffic, or does it cover only the workloads we host?

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: Infosecurity Magazine.