12,520 agent tools are on the internet with no lock on the door

Here's a sentence that should worry anyone building with agents. In late April, the scanning firm Censys went looking across the public internet and found 12,520 MCP servers reachable by anyone, most of them with no authentication at all.

If "MCP server" doesn't land, here's the plain version. MCP — the Model Context Protocol — is how an AI agent gets hands: it's the standard way to give a model tools, so it can query a database, send an email, run a command, touch a real system. An MCP server is the box that exposes those tools. And 12,520 of them were sitting on the open internet with the door unlocked.

It gets worse when you look at what those tools do. The biggest category Censys found was direct database query interfaces. Another big slice was "system control" — servers exposing command execution and remote system interaction. In other words: strangers on the internet could list the available tools, then call them — read the data, run the commands — with nobody checking who they were. A separate team, Knostic, found 1,862 exposed servers and hand-checked a sample; every single one let an anonymous visitor read its internal tool listing.

The protocol just mandated the lock. That's the tell.

The good news, sort of: the MCP spec was updated, and now any server reachable over a network must use OAuth 2.1 with PKCE — real authentication, not an honor system. Auth is finally required.

But sit with why it had to be added. For most of MCP's life, the specification simply did not require authentication. The protocol was designed to run locally, on your own machine, inside a trusted boundary — so "no auth" was a reasonable default there. Then people took those same servers and put them on the internet, where a no-auth local tool becomes an open, unauthenticated remote-control endpoint. The thousands of exposed servers aren't mostly the result of people disabling security. They're the result of people shipping the default and the default being "off."

That's the lesson, and it's older than MCP: defaults are destiny. Whatever the easy path does, that's what most deployments will do. A protocol whose easy path was "no lock" produced twelve thousand unlocked doors, exactly as you'd predict.

This is the same hole, one layer down

I've written that your agent trusts the tool description — that the model will believe whatever a tool tells it, which is a poisoning risk. This is the floor beneath that: before you even worry about a tool lying to your agent, worry about whether a stranger can call your tools at all. The exposed MCP server is the agent equivalent of a database with no password. It doesn't require a clever attack. It requires noticing the door is open, which scanners do automatically, at internet scale, every day.

And it's not theoretical. One popular MCP helper package carried a command- injection flaw and was downloaded over 437,000 times before it was caught. The tooling layer is new, moving fast, and full of the kind of basic exposure the web spent twenty years learning to close.

What to actually do

You don't need to be a security specialist to not be one of the twelve thousand. A short, unglamorous checklist:

• Assume every tool endpoint is reachable until you've proven it isn't. Don't trust "it's only on our network." Knostic's whole point is that "internal" servers end up exposed constantly. Put auth on it regardless.
• Turn the lock on — the spec now hands it to you. OAuth 2.1 with PKCE is the required baseline for any networked MCP server. Use it. "We'll add auth later" is how you become a statistic.
• Give each tool the least power it needs. A system-control or raw-database tool exposed to an agent is a loaded weapon. Scope it down: read-only where possible, narrow queries, no shell unless a human is truly in the loop.
• Watch the calls. A Cisco survey this year found 71% of organizations are running agents they can't properly monitor. If you can't see which tools fired and on whose behalf, you can't catch the day it goes wrong.

The bottom line

Agents are exciting because they can do things. That's also the entire danger: the moment your agent can run a query or a command, the question isn't whether that capability is powerful — it's who else can reach it. Twelve thousand teams just answered that question by accident, and the answer was "anyone."

The spec adding mandatory auth is the ecosystem growing up. Don't wait for the default to save you. The door doesn't lock itself — and on the internet, someone is always already trying the handle.