What can an AI agent actually do once it connects to your MCP server?
PolicyLayer audited 2,031 MCP servers in June 2026 and found 31,000 tools — 7.8% of which can permanently delete data or move money. And 40% of internet-facing MCP services have no authentication at all.
If someone handed you the keys to a server and said “here, any AI agent that finds this can run anything on your tool list” — would you want to know what 31,000 of those tool lists actually look like?
PolicyLayer classified every working tool across 2,031 public MCP servers in June 2026. The headline number is 7.8% of tools can permanently delete data or move money. Not “could theoretically” — just do, with a well-formed tool call and whatever permissions the server was granted.
Where this data came from
PolicyLayer’s State of MCP report (June 2026) crawled public MCP endpoints, called tools/list on each, and classified every tool by capability: read-only, write, arbitrary command execution, destructive operations (irreversible deletes, bulk removes), and financial operations (payments, transfers). Separately, Censys ran an internet-wide scan of port 443 and port 8080 in April 2026 and found 12,520 publicly accessible MCP services — then classified their authentication schemes.
Both datasets are snapshots in time, and the ecosystem is changing weekly. But they’re the only large-scale audits we have.
What the tools actually do
The short answer is: more than most people building with them realise.
Of the 31,000 tools classified by PolicyLayer, 61% are read-only — browsing, querying, searching. That’s the safe bucket. But 21% perform write operations, and the dangerous tail goes further than that.
Twenty-nine and a half percent of the 2,031 servers expose at least one tool capable of arbitrary command execution. Not arbitrary in a theoretical “if someone passes a shell command as input” way — these are tools explicitly designed to run shell commands, spawn processes, or call exec() equivalents. A quarter of servers have at least one tool classified as “destructive”: deletes, bulk removes, purges. 3.4% have at least one financial tool.
The double-counting is intentional — a server can appear in multiple rows. The point isn’t the individual percentages, it’s that connecting an AI agent to a random public MCP server is not like calling a read-only API. You need to actually look at what the tools do.
Who can reach these tools?
This is where it gets awkward. If you think “fine, but those are probably behind some kind of authentication” — Censys found otherwise.
Of the 12,520 MCP services accessible from the public internet in April 2026, roughly 40% had no authentication at all. Zero. The MCP spec recommends OAuth 2.1 for production deployments, and exactly 8.5% of servers have implemented it. The remaining ~51% use static API keys or other schemes.
Static keys get rotated eventually — OAuth 2.1 requires proper token scopes and revocation. But 40% with nothing is a bigger problem than either. A server with arbitrary command execution and no auth is an open shell on the internet.
The discovery problem — can AI agents find your server at all?
Even if you’re not worried about the risk side, the discoverability question matters for the opposite reason: how do AI assistants find your MCP tools in the first place?
The current answer is messy. There are two main paths: /.well-known/mcp.json (a draft discovery spec) and explicit manual registration in AI agent directories. Neither is dominant. The MCP registry that the protocol’s maintainers host listed around 9,652 servers as of mid-2026, while Censys found 12,520 publicly reachable services — meaning roughly 23% of live internet-facing MCP servers aren’t indexed anywhere.
For site owners, this cuts both ways. If you’re serving a public MCP endpoint, you probably want AI agents to find it — but you might not realise how many have already found it. If you’re not serving one, you might not realise how many unauthenticated endpoints look like yours from the outside.
What does this mean for site owners?
First: audit what your server actually exposes. If you’ve published a /.well-known/mcp.json manifest, what tools are listed? What do they actually do when called? The classification mismatch between what developers think they’re exposing and what a security audit finds is the core finding of the PolicyLayer report. “It’s just a data API” frequently becomes “it has a tool that bulk-deletes rows” when someone looks carefully.
Second: if your server is internet-facing, authentication isn’t optional. The Censys data shows 40% of servers have nothing. The ones that get compromised first won’t be the ones with weak auth — they’ll be the ones with no auth. OAuth 2.1 is the spec recommendation, but even a static key with rotation beats an open endpoint for most threat models. For servers with destructive or financial tools, the bar should be higher.
Third: don’t assume your server is invisible. If you’re listening on a public IP and port 443 with an MCP-shaped response, internet scanners have already found you. The discovery registry gap (9,652 indexed vs 12,520 reachable) isn’t a privacy layer — it’s just a counting lag. Plan your permissions based on the assumption that any AI agent with a tool-discovery loop will eventually call tools/list on your endpoint.
The underlying shift that MCP represents is real: AI agents that can take actions rather than just answer questions are becoming infrastructure. The same questions you’d ask about any API — who can call it, what can they do, what happens if they get it wrong — apply here too. The answers are just less often written down.