Model Context Protocol (MCP) has quickly become the default way AI agents connect to tools and data — often described as the "USB-C of AI." A new audit from security researchers suggests that plug currently has almost no lock on it.
What happened
Researchers scanned 15,465 publicly indexed MCP servers across five major MCP registries, deduplicating down to 5,095 unique hostnames. Their conclusion: none of the marketplaces currently vet, sign, or verify the origin of what gets published. Anyone can submit a server, and nothing stops it from going live.
Three numbers stood out:
- 15.6% of hostnames resolve to infrastructure outside the US — including servers in China and Russia — meaning an agent that connects may be sending data across borders no security team ever approved.
- A small but real share (0.45%) route traffic through consumer tunneling tools such as ngrok, a strong signal the "server" is actually running from someone's personal laptop or home network rather than managed infrastructure.
- Over 2% of listed domains have expired and sit available for a few dollars a year. Whoever buys one inherits the server's identity — and any agent still configured to call it.
The researchers also note that even a one-time code review wouldn't close the gap: a remote MCP server can run backend logic that differs entirely from whatever is published in its public repository. What gets audited isn't necessarily what runs.
Why it matters
Enterprises spent the last decade building governance around cloud adoption — data residency rules, Zero Trust network boundaries, vendor and supply-chain audits. MCP connections, wired straight into agent workflows, often bypass all of it. An AI agent calling an unvetted MCP server is effectively a new, unmanaged third-party integration — one that can be reassigned, relocated, or repurposed by a new domain owner without the agent, or its operators, ever noticing.
Taken together with earlier supply-chain findings in widely-used MCP source code, the pattern is consistent: MCP's security model currently depends entirely on what each enterprise enforces on its own side, not on anything the ecosystem guarantees by default.
What to do
- Inventory every MCP server your agents can reach — treat each one as a third-party integration subject to vendor risk review, not a line in a config file.
- Check hosting location and ownership before connecting an agent to a public MCP server, especially for workflows touching regulated or sensitive data.
- Avoid tunneled or personal-machine endpoints in production agent configurations — they offer no operational guarantees.
- Monitor for domain and certificate changes on any MCP server your agents depend on; a sudden change in ownership is a signal to cut the connection immediately.
- Apply Zero Trust principles to agent traffic the same way you would to any other outbound integration — don't let "it's just an AI agent" become an exception to existing controls.