Your agent's plumbing is wide open

Here's a sentence that should make anyone running AI agents sit up. The first large-scale measurement of authentication on remote MCP servers — the connectors that let agents reach your tools, your files, your databases — found that roughly 40% expose their tools with no authentication at all. Censys counted 12,520 internet-reachable MCP services, and most of them were unauthenticated. No password. No key. Anyone who finds the address can use the tools.

That's not a theoretical risk. MCP — the Model Context Protocol — is the plumbing the whole agent boom runs on: it's how an agent gets permission to read your repo, query your database, send mail, hit an API. The industry wired that plumbing into production extraordinarily fast, and the security obviously didn't keep up. A separate sweep of 40,000 MCP server repositories produced 67 new CVEs, and the NSA felt the need to publish its own guidance on locking MCP down. When the NSA writes a memo about your plumbing, the plumbing is leaking.

Let me lay out why this is dangerous and what to actually do, because the fix is mostly boring and mostly skipped.

What an open MCP server actually means

An MCP server isn't a document. It's a set of actions exposed to whatever agent connects: "read this directory," "run this query," "send this message," "call this paid API." That's the point of it — to give an agent real hands.

So "no authentication" doesn't mean someone can read a config file. It means the hands are available to anyone who finds the door. An unauthenticated MCP server on the public internet is a set of capabilities — your capabilities — handed to the world. Depending on what it wraps, that's data exfiltration, a deleted database, a drained API budget, or a foothold to go deeper. And researchers found one runtime that trusts a client-controlled ownership flag, letting a stranger simply claim to be the owner and take over the gateway. The locks that do exist aren't all real locks.

Why it happened, and why it's on you

This isn't because MCP is uniquely bad. It's the oldest pattern in tech: a powerful new capability spreads faster than the safety norms around it. Spinning up an MCP server is easy, the tutorials optimize for "it works," and auth is the step you add later — except later often means never. Multiply that by every developer racing to give their agent more tools, and you get 12,520 open doors.

It connects to something I keep flagging: your agent trusts the tool, and memory and connectors are the new attack surface. We spent a decade learning to secure our APIs and front doors. MCP is a new door, cut into the same house, and a lot of teams haven't thought of it as a door at all.

What to check today

The defenses here aren't exotic. They're the basics, applied to a layer people forgot to apply them to:

• Authenticate every MCP server. No exceptions. If a server exposes tools, it needs a key or token in front of it. An internal-only server still needs auth — "it's on our network" stopped being a security boundary years ago.
• Don't put it on the public internet unless it has to be. Most MCP servers have no business being internet-reachable. Bind to localhost or a private network and you remove yourself from the 12,520.
• Scope the tools to the minimum. An agent that only needs to read shouldn't be handed write and delete. Least privilege at the tool level limits the blast radius when something does get through.
• Distrust the ownership claims. After the client-controlled-flag finding, don't assume a server's own access checks are sound. Verify identity outside the thing you're trying to protect.
• Inventory what you've exposed. A lot of these open servers are forgotten — spun up for a demo, never shut down. You can't secure a door you don't remember cutting.

The bottom line

The agent era added a powerful new layer to your stack — connectors that hand software real hands — and shipped it faster than anyone secured it. A 40%-unauthenticated rate isn't a sophisticated-attacker problem; it's a left-the-door-open problem, and the attacker just has to walk in. The good news is the fix is unglamorous and well understood: authenticate it, don't expose it, scope it down, and know what you've got running.

So before you give your next agent another tool, go look at the plumbing you've already laid. The exciting part of agents is what they can do; the part that decides whether you regret it is who else can make them do it. Right now, for a lot of teams, the answer is anyone — and that's a one-afternoon fix you do not want to keep postponing.