We spent fifteen years learning not to leave a database on the open internet. MongoDB ransom notes. Wide-open Elasticsearch clusters. Redis instances anyone could connect to. Every one of those was a tool built for a trusted local network, shoved onto a public IP by someone in a hurry.
We learned the lesson. Then we built a new kind of endpoint, gave it a tool called execute, and put 12,500 of them back on the internet.
Censys scanned for it. As of late April they counted 12,520 internet-facing MCP services across 8,758 IP addresses. A week later it was past 21,000. Roughly 40% accept unauthenticated requests. No key, no token, no login. Just an open port that speaks Model Context Protocol.
That is not a leak. That is a front door with no lock, on a house full of power tools.
The protocol isn't the villain
A few days ago I wrote about the MCP supply chain, the config-to-command RCE baked into the official SDKs. That was about the code you install. This is the other half: the server you stand up and forget to lock.
And to be clear, the design isn't the problem. MCP was built local-first. The assumption was a trusted boundary: the server runs on your machine, or inside your network, talking to an agent you control. Inside that boundary, skipping authentication is a reasonable default. It's the same reason your Postgres listens on localhost with trust auth out of the box. Convenient, and fine, right up until someone binds it to 0.0.0.0.
The protocol assumed a wall. People deployed it with the wall missing.
When you expose a local-first MCP server to the public internet, the spec doesn't require authentication, so what you've published is an unauthenticated RPC endpoint. Anyone who finds it gets the same access your agent has. And your agent is the most credentialed, most trusting process you run.
Worse than a database
Here's why I'll die on this hill: an open database is bad, but an open MCP server is worse.
An exposed database leaks nouns. Rows, documents, keys. Terrible, but bounded. You lose the data that was in it.
An exposed MCP server leaks verbs. It doesn't sit there holding data. It does things. Look at what these servers actually expose. Across the ecosystem the most common capabilities are network access, filesystem access, and secrets handling. Those are the three you'd put at the very top of the "never expose this" list, and they're the three most common things an MCP server can do.
A database breach is someone reading your filing cabinet. An open MCP server is someone walking into your office and using your hands. It can read files, reach internal services, and pull credentials, because that is the job you gave it. The attacker doesn't need an exploit. They need the URL.
This is the gap nobody internalised in the rush to wire agents into everything. We treated MCP servers like API endpoints, web-shaped things you put behind a load balancer and call a day. They are not endpoints. They are remote hands.
The spec let you, so you did
It would be one thing if the unsafe path were hard. It isn't. It's the easy one.
The specification doesn't mandate authentication. The local-first defaults don't fight you when you expose them. So the path of least resistance, the thing that happens when an engineer just wants the remote agent to reach the server, is an open port. The safe path costs extra work. The unsafe path is free. We know exactly what a population of developers does when you price security that way.
Even the servers that bothered with auth mostly did the minimum. Among the authenticated ones, 53% use a single static API key. One long-lived credential, no expiry, no per-operation scope. Leak it once, in a log, a screenshot, a git commit, and it's a master key until someone notices. That's not authentication. That's a password taped to the monitor.
And the supporting cast of bugs is exactly what you'd predict from people building fast in a young ecosystem. One scanner, VIPER-MCP, chewed through around 40,000 server repositories and surfaced 106 zero-days, turning into 67 CVEs. Nine of those traced back to broken OAuth flows, which is its own dark comedy: the servers that tried to do auth properly introduced vulnerabilities doing it.
We have seen this exact film
None of this is new. That's the depressing part.
MongoDB shipped binding to all interfaces with no auth for years, and we got a ransomware season out of it. Elasticsearch and Kibana, wide open, indexing the world's incident reports. Redis, the eternal example, a service so trusting that an open instance is basically remote code execution if you know the trick. Exposed Docker sockets. Public Kubernetes dashboards. Memcached amplification attacks taking down half the internet for an afternoon.
The pattern is identical every single time. A tool optimised for frictionless local development gets pushed onto a public IP because someone needed remote access and the deadline was yesterday. The defaults were never written for that environment, and the defaults win.
MCP isn't breaking new ground here. It's running the same play, just faster. It took MongoDB years to become a cautionary tale. MCP managed it in about eighteen months, because the adoption curve is steeper and the thing being exposed is more dangerous than a document store ever was.
When the NSA writes you a letter
You can usually tell a technology has outrun its own safety culture by who starts writing about it.
In mid-2026 the NSA put out a Cybersecurity Information Sheet on Model Context Protocol security. Not a blog post. Not a vendor whitepaper. A signals-intelligence agency publishing formal guidance on a protocol that didn't exist three years ago.
Read what it says and read what it implies. It lists authentication controls and prompt-injection defences as required mitigations, not optional hardening. It wants least-privilege tool APIs, end-to-end audit logging of every invocation with parameters and identities, and tools segregated by data-classification zone so the public-facing stuff can't touch the sensitive stuff.
That is a sensible list. It is also, line by line, a description of everything the ecosystem shipped without. You don't tell people to add authentication unless a lot of them skipped it. The advisory is a confession in the negative space: deployment outran governance, and now the adults are documenting the floor.
What to actually lock down
You don't need the NSA's full checklist to stop being one of the 12,500. You need to stop treating an MCP server like a web page.
- Default to localhost. Bind to a loopback address or a unix socket. The overwhelming majority of MCP servers have no business listening on a public interface at all. If your agent and your server live on the same machine, they should never touch the network.
- If it must be remote, put auth in front of it. No exceptions. A reverse proxy with real authentication, mutual TLS, or a tunnel that requires identity. An MCP server on a public IP with no auth is not "exposed", it's donated.
- Treat it like a database, not an endpoint. Assume that public reachability equals compromise, and design from there. Network policy, IP allowlists, the works. You wouldn't put Postgres on
0.0.0.0with trust auth. Same rule. - Kill the static keys. If 53% of authenticated servers are leaning on one long-lived credential, don't be in that 53%. Short-lived, scoped tokens. Rotate them. The same system-level constraint over politeness logic applies: a credential that expires is a real boundary, a credential you intend to rotate is a hope.
- Least privilege on capabilities. Does this server genuinely need filesystem and network and secrets? Probably not. Every capability you grant is a verb you've handed to whoever reaches it. This is the same sandbox-the-process reflex I applied to my own server: assume hostile, grant the minimum.
- Know what you've got. You can't secure an inventory you can't see. That's part of why I built MCP Observatory: to track the ecosystem's releases, CVE feeds, and risk grades, including the network and secrets capabilities that turn an open port into a real problem. Before you trust a server, know whether it's a known quantity or a stranger with hands.
The uncomfortable truth is that almost none of this is novel security work. It's the same hygiene we worked out the hard way with every exposed-service panic of the last fifteen years. Bind locally. Authenticate remotely. Least privilege. Rotate credentials. Know your inventory.
We wrote that runbook in blood already. MCP just handed it back to us with a tool list attached, and a lot of people are reading it for the first time.
The door was never locked. It's just that now, when someone walks through it, the room is full of things that can act on your behalf.