A survey of publicly indexed Model Context Protocol infrastructure has identified governance weaknesses around hosting, domain ownership and the code executed by remote services.
OX Security says it examined 15,465 MCP server listings from five registries, then consolidated those records into 5,095 unique hostnames. The findings do not describe 15,465 separate operators or affected organizations: the larger number represents indexed server records, while the smaller figure represents distinct hostnames.
According to the OX Security account of the research, some listed servers were hosted in potentially unapproved jurisdictions, exposed through consumer tunnels or associated with domains that no longer resolved.
This is not a report of a confirmed breach. OX did not identify a victim, verified data theft or active exploitation tied to the surveyed servers in the published account. Instead, the research maps ways in which an AI agent could place trust in infrastructure that later changes ownership, location or behavior.
Thousands of listings collapse into 5,095 hostnames
MCP emerged in 2024 as a standard for connecting AI models, software agents and integrated development environments to external tools and data sources. An MCP server can make capabilities available to an agent, potentially placing that service inside sensitive workflows.
OX’s analysis covered five MCP registries, although the published account does not identify them or describe their individual admission and review procedures. That limits comparisons between registries and prevents an assessment of whether all five apply the same controls.
The distinction between listings and infrastructure matters. OX collected 15,465 publicly indexed servers, but deduplication produced 5,095 unique hostnames. Multiple registry entries may therefore point to the same hostname.
The reported percentages apply to hostnames rather than people. They should not be interpreted as numbers of compromised systems, customers or organizations.
Unlike a conventional vulnerability advisory, the research does not identify a defective product version, assign a CVE or provide a severity score. The issue is broader: agents may connect to third-party services without sufficient assurance about who operates them, where requests travel or which backend code processes them.
Hosting location can create an unapproved data path
OX reports that 15.6% of the hostnames resolved to infrastructure outside the United States. The account specifically identifies 19 in China and 18 in Russia, but it does not provide complete country-by-country totals.
Geographic location is not evidence that a server is malicious. It can, however, determine which legal jurisdiction and internal data-residency requirements apply when an agent sends prompts, source code, credentials or business information to that service.
An enterprise may have approved a particular AI tool without separately reviewing every MCP endpoint the tool can call. In that situation, an agent connection could create a data path outside regions authorized by the organization.
OX also describes a scenario in which an operator initially hosts a service on a US-based IP address and later redirects it elsewhere. The published findings do not establish that OX observed such a transition among the surveyed servers. It is a threat scenario illustrating why a one-time location check may not provide lasting assurance.
The practical issue is continuous verification. A hostname can remain unchanged while the infrastructure behind it moves, leaving existing agent configurations intact.
Consumer tunnels weaken confidence in server ownership
OX says 0.45% of the surveyed hostnames routed traffic through consumer tunneling services, primarily ngrok-free.
A tunnel can expose a locally running application without requiring the operator to deploy it on conventional hosted infrastructure. That is useful for demonstrations and development, but it offers enterprises less information about the environment behind the public endpoint.
OX characterizes the listed tunneled services as operating from personal machines. It also assesses that they are likely connected through home networks, although that network-location claim is an inference rather than a confirmed result for every endpoint.
The concern is operational control, not a demonstrated compromise of the tunneling platform. A publicly listed MCP service may depend on an individual computer, an informal deployment process or infrastructure outside an organization’s normal monitoring and change-management systems.
That can affect availability as well as security. The agent sees an accessible endpoint, but its operator may not provide the identity, lifecycle and supply-chain assurances expected from an enterprise service.
Expired domains could transfer a trusted server identity
OX found that 2.3% of the hostnames no longer resolved. Six were reportedly associated with expired domains available for registration at an estimated $4–$12 per year.
This creates a potential identity-transfer problem. If an agent remains configured to contact one of those domains, a new registrant could restore the hostname and begin receiving future requests intended for the previous MCP operator.
The domain becomes valuable because trust may persist in client configurations after ownership has lapsed. Users may continue to recognize the server name, while automated agents may not distinguish between the former operator and the new registrant.
OX does not report that any of the six domains was actually registered by an attacker. Nor does the account document requests being intercepted through those domains. The finding identifies a feasible takeover path, not a completed takeover or confirmed exposure.
Its impact would also depend on how the agent uses the endpoint. The published figures do not establish which tools, permissions or information were available to clients configured for the affected domains.
A public repository does not prove what a remote server runs
The research also challenges a common software-review assumption: that examining a public repository is enough to establish the behavior of a remote MCP service.
Repository review can help assess source code, dependencies and declared functionality. But unless users can verify the relationship between that code and the deployed service, the remote backend may run a different build or entirely different logic.
OX describes MCP marketplaces as lacking an equivalent to app-store malware screening and says publishers can make servers available without comparable vetting. The account does not name the five registries or document their specific controls, so this characterization cannot be applied uniformly to each one from the available information.
The article uses Google Bouncer, which Google operated in 2012 to scan Android applications, as a comparison. It also acknowledges that researchers found ways to evade Bouncer. Screening is therefore not an absolute guarantee, but it can add a review layer that OX argues is missing from the MCP ecosystem.
OX’s complete report, titled “15,465 MCP Servers, 0 Governance,” is said to include a prompt-injection proof of concept and additional threat scenarios. The published summary does not provide enough technical detail to determine the proof of concept’s conditions or whether it was exercised against a live third-party service.
Enterprises need controls around the connection, not just the code
OX calls for MCP marketplaces to introduce marketplace vetting, code signing, and origin verification. Together, those measures would help answer three different questions: who may publish, whether an artifact has changed, and whether a remote service corresponds to an expected source.
Organizations using MCP can also bring the connections under existing governance programs. The practices identified in the research include data-residency rules, Zero Trust boundaries, granular identity and access management (IAM), and supply-chain audits.
Applied to MCP deployments, that means maintaining visibility into which agents can reach which servers and determining whether those endpoints remain within approved jurisdictions and ownership boundaries. Domain status and hosting location are not permanent properties, so an approval based on an initial review may become outdated.
Repository inspection should likewise be treated as one source of evidence rather than proof of runtime behavior. Where a workflow handles sensitive information, organizations need assurance about the deployed service and its operator, not only the code advertised in a public project.
OX also refers to earlier research involving vulnerabilities in Anthropic’s MCP source code, characterizing those issues as critical and saying the code had been downloaded more than 150 million times. The available account supplies no CVE identifiers, affected versions, technical evidence or remediation details for those earlier findings. They cannot therefore be evaluated as part of the present server survey.
The newly reported measurements remain OX’s findings and have not been independently validated in the material available for this story. They nevertheless describe a concrete governance problem: an AI agent’s trust relationship may outlast the infrastructure, domain owner or software implementation that originally justified it.
