41% of MCP Servers Have No Authentication. Here's How to Tell If Yours Does.

You are one tab over from installing an MCP server you have not read the source of, written by someone you have not met, that will run on the same machine you read your email on. Most of the time, that is fine. About four in ten times, that server cannot tell whether you are you, and neither can anyone watching the connection.

That line has been sitting in my head for the last two weeks. It came out of a piece of analysis from BlueRock Security, surfaced again in the NSA's first formal MCP advisory, and was reinforced when OX Security demonstrated a remote code execution flaw running through tools downloaded more than 150 million times.

I am not writing this to scare you. I install MCP servers too, and the question I want to answer is the same question you want to answer when you are looking at a listing: should I click install on this one.

Below is the three-question check I run now. It works on any directory, any GitHub README, any tweet that links to a new server. You can apply it in under two minutes. By the end of this post you should be able to recite the three questions back without scrolling up.

What Actually Changed in the Last 60 Days

Three things happened in close succession, and the cumulative effect is that the MCP conversation has crossed from researcher niche to executive readable.

First, the NSA published a Cybersecurity Information Sheet on MCP. The agency that does not usually weigh in on developer tooling weighed in on developer tooling. The document is short, plain, and frames MCP as a category of risk most organizations have not yet folded into their existing controls. If you have not read it, that is fine. Most of your peers have not read it either. The point is that it now exists, and the next time the topic comes up in a security review meeting, somebody is going to cite it.

Second, OX Security disclosed a systemic vulnerability in MCP's design, reaching across SDKs covering more than 150 million downloads. The Hacker News covered the disclosure as well. The flaw is not a bug in one server. It is a default behavior in the protocol that, until you opt out, lets any STDIO transport talk to any tool with no manifest, no allowlist, no friction. Anthropic's response was to call this "by design," which is technically accurate and also exactly the surface a writer of malicious code would have asked for if they had been allowed to draft the spec themselves.

Third, BlueRock Security's April analysis found that roughly four in ten public MCP servers run with no authentication of any kind. About half use static API keys, which is barely better. Fewer than one in ten use OAuth or any modern auth pattern. I want to be careful here: those numbers cover public servers researchers could reach, not every server running on a private machine. The pattern still tells you something. The default posture of the public space is open.

You can debate any one of these. Together they say the same thing. MCP is a category where the install-time decision matters more than the post-install hardening.

The Gap Nobody Is Writing Into

If you go looking for guidance on MCP security right now, you will find two kinds of coverage.

The first kind is security press. Dark Reading. The Register. Tom's Hardware. They are writing for security leaders. The framing is alarm, the audience is "what should our policy be," and the read leaves a developer feeling like they should escalate something to a team that does not exist yet at their company.

The second kind is developer hardening. OWASP guides, framework-author posts, OX's own remediation writeups. These are excellent if you build MCP servers. They are not written for the person installing one.

Neither kind is written for the person standing in front of a listing for the first time, finger over the install button, asking the only question that actually matters at that moment: is this one safe enough for what I am going to use it for. That gap is the gap I am writing into.

The Three Questions Before You Install

These are the three you can answer in under two minutes from any reasonable listing. If the listing does not give you what you need to answer them, that is itself an answer.

Question 1: Does the server authenticate at all?

This is the floor. No authentication means no trust boundary. If anything in the network path between you and the server gets compromised, there is nothing on the server side that can tell the attacker apart from you.

What to look for: the listing or README should say, in plain language, that the server requires a credential to call its tools. The server should refuse anonymous calls. If the only mention of auth is "configure your API key in the environment," and that key is optional, read that as no auth.

What a "no" costs you: the cost is not that someone reads your data. The cost is that someone calls your tools. If the server can read files, write files, run shell commands, or hit cloud APIs on your behalf, a no-auth server lets anyone who reaches it do those things as you. About four in ten public servers fail at this question, which means the most common failure mode is also the one that costs you the most.

Question 2: How does it authenticate?

This is the part where the answer "yes" to question one starts to fragment.

What to look for: the listing should name the method. Static API key is the most common, and it is the bottom of acceptable. OAuth, especially OAuth with token rotation, is the floor for anything touching customer data, billing systems, or cloud credentials. Mutual TLS or workload-identity patterns are the ceiling, and you will mostly see them on servers built for enterprise contexts.

What a "no" costs you: a static key that lives in an environment file is one stolen .env away from being someone else's key. OAuth with rotation costs the attacker the ability to use a stolen token after a short window. The cost of choosing a static-key server for a task that touches sensitive data is that one bad shell history entry, one mistaken commit, one screen-sharing accident becomes a real incident, instead of a near miss.

For most people reading this, the practical guidance is: use static-key servers for tools that touch nothing sensitive (a markdown parser, a unit converter, a public-data lookup). Demand OAuth or better for anything that reads your inbox, writes to your code repo, talks to your billing platform, or holds your cloud credentials.

Question 3: Does the transport require a manifest or allowlist?

This is the OX Security question, in plainer terms.

What to look for: the listing should say which transports the server supports (STDIO, HTTP, WebSocket) and whether the server requires a declared manifest of which tools are exposed. The newer SDK releases default to allowlist required. Older releases default to open, and a meaningful share of the installed base is still on older releases.

What a "no" costs you: this is the flaw OX demonstrated. On a STDIO transport with no manifest, a hostile process on your machine, or a hostile dependency inside your project, can talk to the MCP server and call any tool the server exposes, without you ever seeing the call happen. The mitigation is one configuration line. The default is that the line is not there.

A good listing will say, plainly, "we require a declared manifest" or "we run an allowlist." A listing that does not address this question is asking you to inherit the default, and the default is the problem.

What to Look For in a Directory

The reason I broke those three questions out is that they are also the three things a directory should surface before you ever click into a listing.

Most directories today do not. Most directories show you the name, the description, the stars, the install count, and sometimes a category tag. They show you what the server claims to do. They do not show you what it does to your trust boundary.

The pattern I look for when I review any directory now is this: at the listing level, before I click in, I can see the authentication method, the transport defaults, the update recency, and the public CVE history. If I have to open the README to find out whether a server authenticates, the directory is doing less work than it could be doing.

That is the move that closes the gap I named above. It pulls security-relevant signal out of the README and into the surface a busy person actually reads. It does not turn the user into a security reviewer. It just asks the directory to do that part once, so a thousand users do not each have to do it for themselves.

A directory that does this does not need to call itself a security directory. It just needs to put the answer to the three questions on the card.

The Two Questions for After You Install

These are quick. They matter, but they are not the leverage point.

How often does the server update? A server that has not seen a commit in nine months is a server whose maintainer is either done with it or has moved on. That is fine for some categories (a deterministic data converter, a stable filesystem helper) and not fine for others (anything touching evolving APIs, anything touching auth flows). Check the last-commit date before you trust a server with anything ongoing.

What is its public CVE history? A server with reported CVEs that have been fixed and disclosed is, counter-intuitively, often a better bet than a server with zero CVEs that has never been reviewed. Disclosure history tells you someone is paying attention. Empty history tells you nobody is. The directory's job here is to show you both signals next to each other.

These two are sanity checks. They do not replace the three install-time questions. They reinforce a point I want to leave you with: selection is where the work pays off. Post-hoc hardening is what you do when selection went wrong.

Where That Leaves You

If you take nothing else from this post, take the three questions.

1. Does it authenticate?
2. How does it authenticate?
3. Does the transport require a manifest?

The next MCP server you install, run that check first. If the listing answers all three in under two minutes, you are working with a tool whose author thought about your trust boundary. If you have to dig, dig. If you cannot find the answers at all, that is the answer.

That is what changed for me after the NSA advisory and the OX disclosure. Not that I am more scared. I am not more scared. I am more deliberate. The threat was always there. The check is what is new.

You are not safer because you read this post. You are safer because the next time you stand in front of an install button, you are going to do something different.

That is the only thing I wanted to give you.

If you want a community-rated directory of MCP servers and Claude skills to start that check against, Clelp lists more than 1,700 of them. Bring the three questions.