What happened
Research from Ox Security says the Model Context Protocol, the standard that lets AI applications reach external tools and data without bespoke integration code, has no governance layer to match its adoption. The report, titled 15,465 MCP Servers, 0 Governance, was built from an analysis of three public registries: mcp-official-registry, cline-marketplace and github-mcp-registry.
Nearly 16 per cent of the 5,095 unique hostnames examined resolved outside the United States, including hosts in Russia and China. MCP has no protocol level concept of geographic region, so an enterprise can enforce strict residency rules over its own cloud workloads while the agents it runs connect freely to servers outside those same controls. More than 2 per cent of the hostnames no longer resolve, and some are unregistered and available to buy, which means an attacker could stand up a server at an address an organisation already trusts.
The team also tested how far a single permission decision can travel. In a Claude Code test running Haiku 3.5, a malicious MCP server asked for access to a harmless file and was granted always-allow. It then requested sensitive files, .env among them, and received them with no further prompt. Anthropic's position, as relayed in the report, is that once always-allow is granted this is the documented behaviour, and that model level detection of malicious content is a best effort heuristic rather than a security boundary.
This is not the first warning. Backslash Security reported in June 2025 that hundreds of MCP servers were exposed to anyone on the same local network through a flaw it named NeighborJack, with around 70 carrying severe issues. In April 2026 Ox Security described a systemic flaw in Anthropic's official MCP SDKs, claiming it could allow arbitrary command execution across as many as 200,000 instances, a finding Anthropic dismissed as expected behaviour.
Why this is a GRC story
Residency commitments stop at the agent. A data residency control that only covers workloads you own describes half the flow. Once an agent is allowed to call a third party server, personal data can leave the region without a transfer assessment, and nobody signed a data processing agreement for that hop.
Third party risk registers do not list MCP servers. Most onboarding processes capture vendors with a contract and an invoice. An MCP server pulled from a public marketplace by a developer is a supplier relationship with none of that paperwork.
Permission decisions outlive the person who made them. Always-allow converts a one time convenience into standing authority, which is the same failure mode we spend years removing from human accounts.
Evidence has to separate agent activity from human activity. If tool calls are not logged against the agent's own identity, an incident review cannot reconstruct what the agent read and on whose authority.
What to watch
Watch whether the registry operators add any verification step, and whether the protocol itself gains scoping or region awareness. Until either happens, the practical controls sit with the organisations deploying agents.
A useful exercise this month: ask for the list of MCP servers your developers have connected, who approved each one, what data each can reach, and whether any sit outside your residency perimeter. If that list takes a week to produce, that is the finding.
Attribution: Analysis based on Infosecurity Magazine's reporting and related public reporting. This article is original commentary, not a repost of the source material.