# 12,520 agent tools are on the internet with no lock on the door Security researchers scanned the internet and found 12,520 MCP servers — the tool connectors that let AI agents do real things — sitting in the open, most with no authentication at all. Some let any stranger run database queries or shell commands. The protocol just made auth mandatory in its June spec, but the damage shows the deeper bug: the default was 'no lock,' and people shipped the default. If your agent can reach a tool, so can everyone else — unless you decided otherwise on purpose. - **Author:** Fedor Chishchin - **Published:** 2026-06-06 - **Tags:** security, architecture, agents, mcp - **Source:** https://fedorthinks.com/blog/tools-on-the-internet-no-lock --- 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](https://censys.com/blog/mcp-servers-on-the-internet/). 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](https://censys.com/blog/mcp-servers-on-the-internet/). 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](https://www.csoonline.com/article/4168979/1800-mcp-servers-exposed-without-authentication-how-zero-trust-can-secure-the-ai-agent-revolution.html). ## 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](https://modelcontextprotocol.io/specification/draft/basic/authorization) — 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](https://censys.com/blog/mcp-servers-on-the-internet/). 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](/blog/your-agent-trusts-the-tool) — 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](https://www.csoonline.com/article/4168979/1800-mcp-servers-exposed-without-authentication-how-zero-trust-can-secure-the-ai-agent-revolution.html) 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](https://www.csoonline.com/article/4168979/1800-mcp-servers-exposed-without-authentication-how-zero-trust-can-secure-the-ai-agent-revolution.html). 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.