Why Are 41% of MCP Servers Basically Open to Anyone?

Forty-one percent. Kai Security scanned 518 MCP servers from the official registry and found 214 with no credentials required. BlueRock swept roughly 7,000 public endpoints and hit the same 41%. Zuplo checked 17,000+ listed servers as of February 2026 — still 41%. When three teams use different methodologies and converge on the same number, you're looking at a structural problem, not sampling noise.

Where does this data come from?

The stats in this post are drawn from three security scan studies conducted in H1 2026, plus a detailed code-level audit by AgentsID's open-source MCP security scanner. AgentsID pulled 100 packages from public registries, reached 41 live servers, and ran 893 automated checks across 485 distinct tools — an average of 11.8 tools per server. Separately, Censys's internet-wide scan identified 12,520 publicly exposed MCP services. The Kai Security audit focused specifically on the official MCP registry.

So what does "no auth" actually mean in practice?

Of the 214 unauthenticated servers Kai Security found, 156 expose callable tools — not just manifests, but actual action endpoints — to anyone who can reach them over TCP. Some of those tools have write access: creating records, triggering callbacks, modifying state. No token, no API key, no OAuth flow. Just open.

The architecture story here matters. MCP was originally designed for local use — a desktop AI client calling tools on the same machine. The protocol spec never required authentication because it assumed a trusted local context. Builders then picked it up, deployed it on the public internet, and skipped the auth layer the spec had implicitly assumed someone else would add.

What do security grades actually tell us?

The AgentsID audit graded servers across auth, validation, permissions, and injection resistance on a standard A–F scale. The results: 0% scored A, 5% scored B. Seventy-one percent scored F. The researchers noted that every vendor-maintained server that exposed tools received an F — which isn't a comment on any specific vendor, but a signal about how the ecosystem as a whole has approached security so far.

Is OAuth 2.1 actually being used?

Of the servers that do enforce some kind of authentication, only 8.5% use OAuth 2.1. The remaining roughly half (those with any auth at all) run on static API keys. Static keys work, but they're missing rotation, scoped permissions, and revocation without rolling every client. For a protocol used to expose tools to AI agents that operate autonomously across sessions, that's a meaningful gap.

The MCP specification introduced OAuth 2.1 with PKCE as the recommended approach for remote servers, and support across major AI assistant ecosystems has improved substantially through 2026. The main reason teams avoid it is setup overhead — which is lower now than it was twelve months ago, with widely available middleware.

What's a hallucination-based vulnerability, and should you care?

AgentsID identified a category of findings that sits outside the usual security taxonomy: 163 hallucination-based vulnerabilities (HBVs) across 41 servers, roughly 4 per server on average. These exploit the fact that tool descriptions are interpreted by AI systems rather than parsed by code. A description like "manages user permissions" can be read by an AI agent as implicit authorisation to escalate privileges, even if the underlying function never intended that.

Scope boundary ambiguity, conflicting tool names, implicit authority language — traditional WAFs don't catch any of this. It's semantic attack surface, not syntactic. Validation issues were the single biggest finding category (61% of 893 total findings), but HBVs were the most novel: 18% of findings, and zero of them would have been caught by a standard SAST scan.

What should you actually do about it?

The fixes aren't complicated, but they do require deliberate decisions.

For authentication: the minimum viable approach for any public-facing MCP server is OAuth 2.1 with PKCE. Static API keys are fine for private deployments or internal tooling, but not for anything customer-facing that can mutate state. If you're currently in the 41% with nothing, even a simple bearer token check — plus key rotation on a quarterly schedule — is a substantial improvement over zero controls.

For HBVs: write defensive tool descriptions. Be explicit about what a tool cannot do, use negative constraints, and avoid authority-adjacent verbs like "manage", "handle", or "control" when a narrower term exists. Every ambiguous word in a tool description is potential semantic attack surface for AI agents that interpret natural language.

For rate limiting: any reverse proxy with token-bucket support can front an MCP server and cap invocations per client per minute. Given that many unauthenticated servers also have no rate limiting, this is probably the highest-leverage single control to add right now for preventing runaway agent loops.

The ecosystem is growing fast — 22,000+ servers on PulseMCP as of July 2026, up from around 9,400 in April. That growth is outpacing the security tooling, and the 41% no-auth figure reflects a large cohort of early deployments that got capability running and then moved on. If you're exposing MCP tools on the public internet, now is a reasonable time to audit what you actually have.