The Model Context Protocol became the plumbing between language models and everything else faster than anyone secured it. It is what lets an agent read your files, call your APIs, and run your shell. So the interesting question is not whether MCP is risky in the abstract. It is what the servers people actually deployed look like.
A measurement study of real-world remote MCP servers gives the clearest answer so far. Of 7,973 validated servers, 3,233 — 40.55% — expose tool interfaces with no authentication at all, meaning any client can invoke tools or trigger API requests without presenting credentials. Of the rest, 29% rely on a static token or API key, and 30.45% implement OAuth.
Other counts land in the same place. A survey of some 17,000 listed servers put the no-authentication share at 41% as of February 2026; a separate analysis of about 7,000 public servers reported 41% with no authentication and 8.5% using OAuth. Different methods, different populations, same order of magnitude.
The number I would not use
Before going further: be careful with “X% of MCP servers are vulnerable” headlines, including from people selling you something.
One independent audit ran two open-source scanners across 33 servers. They flagged 27 patterns; on review, 6 were genuine — a false-positive rate of roughly 78%. Eight of the twenty-seven were labelled prompt injection and were, in fact, ordinary tool dependency instructions (“You MUST call this function first”). A browser-tooling server drew nine detections, all for doing exactly what it is built to do. The scanner flagged the product’s purpose as an attack.
That is a useful cautionary tale about pattern-matching, and it is the reason the authentication numbers above are worth more than the vulnerability percentages. Does this server require credentials is not a judgement call that a rule can get wrong in either direction. It is a fact about a configuration, and you can count it.
What is actually broken here
Read the list of what has gone wrong with MCP this year, and separate the exotic from the ordinary.
Exotic: a malicious server that shipped two harmless tools and withheld its payload until the client had made exactly three tool calls — a reviewer checking a new server is unlikely to spot that. A command-injection flaw in the STDIO transport across all four official SDKs. Poisoned tool descriptions that read as instructions.
Ordinary: no authentication on four in ten servers. Static API keys instead of scoped credentials on most of the rest. Credentials passed through environment variables. Servers bound to every interface by default. And the category OWASP’s new MCP list calls shadow servers — the “quick test” instance somebody stood up two months ago on a default config and forgot. One engineer writing up that list went and audited his own fourteen servers: three had hardcoded API keys, and one was exposed to the internet with no authentication, set up for quick testing and forgotten.
The exotic problems are genuinely hard and mostly runtime. The ordinary ones are configuration, and they are where most of the exposure actually sits — the same lesson the summer’s agent-intrusion post-mortems taught, arriving again in a different costume.
Configuration facts you can check today
For every MCP server in your stack, these are answerable on paper, before anything is attacked:
- Does it require authentication, and of what kind — OAuth, a static key, or nothing.
- Where does it bind. Loopback, an internal interface, or every interface.
- What credential does the server itself hold, and what does that credential reach if the server is compromised. A server with a token that works across several systems is the blast-radius problem from every recent incident, wearing a new name.
- Which servers are connected at all — including the ones nobody declared. A server you have not written down is a server nobody reviews.
- Is there a gate in front of the consequential tools: an approval step before something is sent, spent, deleted, or deployed.
- Is anything logged. OWASP’s list has a category for this because most servers do not record what they executed. No trail, no incident response.
None of that requires watching traffic or catching an attack in progress. It requires reading configuration and comparing it to what someone decided the system should be.
What this does not cover
A configuration read does not detect a poisoned tool description. It does not notice a server that behaves for three calls and then does not. It does not tell you whether an agent was manipulated by a sentence in a pull request title. Those are runtime and adversarial, and anyone telling you a static check handles them is selling the fear of one problem with the tool for another.
What a configuration read does is make the ordinary failures visible while they are still boring: the forgotten server, the token that reaches too far, the missing gate, the absent log. Four in ten servers currently fail the easiest of those questions. That number is not evidence that AI is uncontrollable. It is evidence that we deployed something new quickly, with the defaults, and have not yet gone back to look.
Going back to look is the cheap part.
Skulk reads an AI application’s repository, cloud control plane, stores, and declared intent together — including which MCP servers the code connects to, what scope they carry, and whether a gate stands in front of the consequential ones. Every finding carries its evidence, and every report states what it did not assess. Scoping costs nothing.