Somebody at your company may have put an AI agent on the public internet

A preprint posted at the end of July surveyed Model Context Protocol servers reachable from the open internet, and the number that should get a mid-market reader's attention is not the biggest one in it.

It is 41.6% — the share of confirmed servers that disappeared within three days, between one measurement run and the next. Those are not production deployments. They are experiments that were briefly on the public internet, and then were not.

What the study actually measured, with the right denominators

This matters because the finding is easy to quote wrongly, and the wrong version has been circulating. The two headline numbers come from different populations.

Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale (arXiv:2608.00150, submitted 31 July 2026) reports, in its own terms:

• Over 21,000 MCP server instances detectable on the public internet, via passive discovery across eleven data sources.
• 640 confirmed production servers, across four measurement runs spanning July 2026.
• 414 of those dynamically audited — actively tested, not just fingerprinted.
• 68 reportable vulnerabilities found, including SQL injection, server-side request forgery targeting cloud metadata services, prompt template injection, and path traversal via cursor manipulation.
• 91.8% of the dynamically audited servers lack OAuth authentication.
• 687 tool instances across confirmed servers expose shell execution capabilities without access controls.
• 41.6% of confirmed servers vanish within three days between consecutive runs, which the paper reads as rapid deployment cycles without security review.

So “21,000 exposed servers, 91.8% with no authentication” is not what was found. The 21,000 is what was detectable; the 91.8% is of the 414 that were actually audited. Both figures are real and they describe different things, and multiplying one by the other produces a number nobody measured.

Read the caveats before you act on it

Three, and they cut in both directions.

It is a preprint: single author, thirteen pages, no journal reference, no peer review at time of writing. That is not a reason to dismiss it — the method is described and the tooling was released open-source, which is more than most vendor security reports offer — but it has not been through review and should be read as such.

The population is self-selecting in a way that cuts against alarm. This is a census of servers reachable from the open internet. A properly deployed corporate MCP server sits behind a VPN or a private network and does not appear in it at all. So the study cannot tell you that MCP is insecure, and it does not claim to; it tells you about the subset that ended up publicly reachable, which is a different and narrower claim.

And the population is self-selecting in a way that cuts toward alarm, which is the more interesting half. If the majority of what is publicly reachable turns out to be short-lived and unauthenticated, that is consistent with the exposed population being mostly experiments — and an experiment on the public internet with shell execution and no authentication is a worse object than a badly configured production server, because nobody is watching it and nobody has written it down.

Why this happens, and why it is nobody's fault in particular

Standing up an MCP server is genuinely easy. That is the point of the protocol, and it is a feature: it is how an agent gets access to a real system instead of a demo. The tooling is free, the guides work, and somebody technical can have one running in an afternoon — which we said in as many words when discussing what an AI agent costs to build, because it is true and useful.

The gap is that the easy path does not pass through anyone who would ask about network exposure. A developer solving a real problem on a Tuesday, on a cloud instance they have legitimate access to, is not doing anything wrong and is not thinking about the default bind address. Authentication is optional in the easy path, so the default is open. Nothing in the workflow prompts the question.

This is ordinary shadow IT with a new surface, and the reason it deserves attention is not that the people involved are careless. It is that the blast radius is unusually large for how little effort it takes: an MCP server exists specifically to give something else the ability to act on your systems.

A short self-audit

None of this needs a project. It is a morning, and the first two items find nearly everything.

• Ask. Not through a survey — ask the two or three people most likely to have tried this whether they have an agent talking to anything real, and where it runs. This is the highest-yield step by a wide margin, and it works better as curiosity than as an audit.
• Look at what is listening. Cloud security groups and firewall rules, filtered for anything open to the world that nobody can name. This is worth doing periodically regardless of AI, and it will surface more than MCP servers.
• For anything you find, ask what it can reach. Not what it does — what its credentials permit. That is the scope question, and it is the one that decides how much the exposure actually matters. We have written separately about why the credential is the real boundary, and the argument applies unchanged here.
• Check for shell execution specifically. A tool that can run commands is categorically different from one that reads a database, and per the study it is a common capability to expose without controls.
• Then make the easy path a safe one. Not a ban — a ban moves this onto laptops and personal cloud accounts, where you cannot see it at all. A sanctioned place to run these things, private by default, is the only version of this policy that survives contact with people who have work to do.

What this does not mean

It does not mean MCP is unsafe to use, and it does not mean an integration built on it is a liability. The protocol is doing what it was designed to do. The finding is about deployment defaults and about who was in the room when the deployment happened — and the honest read of the 41.6% is that most of the exposed population was never intended to be a deployment at all.

Nor is it a reason to slow down. The organizations that will handle this well are the ones where trying things is easy and the place to try them is already private. Those are not in tension; the second one just has to exist before the first one happens.

Where we sit

The self-audit above is something your own people can run and it costs nothing, which is why it is written out rather than offered. If it turns something up and the question becomes what the credential can reach and what to do about it, that is AI integration work — labor and judgment, on infrastructure and accounts that stay in your name.

Source: arXiv:2608.00150, fetched 25 August 2026. All figures above are the paper's own, with its own denominators. Preprint, not peer reviewed.

Related reading: AI agent security risks — the credential is the boundary, which is the scope question this post defers to. And your AI agents need a manager, not just an API key — on who owns one of these once it is running.