If 41% of MCP Servers Have No Auth, Is Your Agent Actually Secure?

Forty-one percent. That's the share of officially registered MCP servers that will accept tool calls from any caller, no credentials required, no identity check. A scan of 518 servers listed on the main MCP registry found that nearly one in two will happily invoke read_database, send_email, or delete_record for whoever knows the endpoint URL — and for registered servers, that URL is public by design.

If you're building agents that connect to third-party MCP servers, that number should make you uncomfortable. You have no way of knowing whether the server on the other end has fixed it.

Where does this data actually come from?

TapAuth published a systematic scan of 518 officially registered MCP servers in mid-2026, classifying each by authentication method. Practical DevSecOps compiled a wider audit drawing on an academic measurement study across 39,884 MCP server repositories plus Censys scans of 12,520 publicly exposed MCP services. The MCP specification changelog from the July 2026 release candidate documents what the spec itself now mandates as correct. These sources don't agree exactly — the no-auth share ranges from 38% to 41% across studies — but the direction is consistent.

So who's actually authenticating?

Break down those 518 servers by authentication method and the picture is stark. Eight percent use OAuth 2.x — the approach the July 2026 spec now mandates. Fifty-one percent use static API keys, which at least creates some barrier, though with its own problems: no rotation, secrets living in config files, no expiry. And 41% have nothing at all.

What does "nothing" mean in practice? Your agent's POST to the server's JSON-RPC endpoint hits the router and proceeds straight to tool execution. No bearer token validated, no IP allowlist checked, no mutual TLS. If you know the URL, you can call any tool the server exposes.

This isn't some obscure edge case. The whole point of the MCP registry is discoverability — you list your server so agents can find and use it. Listing with no auth is the equivalent of putting your private API in a public directory and leaving the front door open. The 30+ CVEs filed in the first 60 days of 2026 were not all sophisticated attacks; many were straightforward calls to unauthenticated endpoints.

What's actually hiding inside the "static key" servers?

The 51% using static API keys look safer on paper. The 2026 audit complicates that. Across all server types, 79% of MCP servers handle credentials in plaintext — keys embedded in client configs, passed in headers over unencrypted connections, or written to server logs. A key that never rotates and lives in a flat config file is one leaked .env away from being useless as a security control.

The same audit found command-injection vulnerabilities in 43% of servers. When a tool schema wraps a shell command or SQL query and the server builds it from user-supplied input without sanitisation, the auth layer doesn't help — a caller who knows the schema can inject regardless of whether they authenticated. And the 6% tool-poisoning rate is the one that's hardest to catch: it's where the server's own tool descriptions contain hidden instructions that the model reads but the user never sees, redirecting the agent's behaviour before it ever makes an external call.

Does the auth spec update actually fix this?

The July 2026 MCP spec hardened authentication meaningfully. OAuth 2.1 with PKCE is now required, tokens must be bound to specific resource servers via RFC 8707 Resource Indicators, and refresh token rotation is mandatory. These are real improvements over what existed twelve months ago.

But here's what the spec still doesn't define: tool-level granularity. A server exposing 20 tools gets a single session token that covers all 20. If your agent is authorised to call get_order_status, it's also authorised to call cancel_all_orders — unless the server developer explicitly adds a second layer of per-tool access control. Most don't. A 2026 survey found that 70% of security leaders report AI systems in their organisations have more access than a human employee in the equivalent role. For MCP, that's not a surprise — it's the architectural default.

Forty-five percent of software companies are now running MCP in some form of production. That's a lot of agents inheriting the permissions of their host environment without anyone explicitly deciding that was a good idea.

What should you actually do about it?

If you're deploying your own MCP server, the July 2026 spec gives you a clear target. OAuth 2.1 with PKCE, resource-bound tokens, refresh token rotation. Getting there from a static key setup is not a major project for a small server — it's a weekend job. The harder question is whether your tool schema is doubling as an attack surface. Command injection through tool parameters is easier to introduce than it looks, especially when tools wrap database queries or shell commands. Review every tool that takes user-supplied strings and traces them to an exec call.

If you're building agents that connect to third-party servers, the 41% no-auth figure should shape which servers you connect to. An agent connecting to an unauthenticated server doesn't just expose that server's tools — it exposes whatever context and credentials the agent is carrying. If your agent holds a session token for your own systems and connects to an unauthenticated third-party MCP server, you've effectively handed an unknown operator indirect access to everything your agent can touch.

The practical fix isn't to block all unauthenticated servers — some are deliberately public, some are internal-only, and the ecosystem is still maturing. The fix is to treat MCP server connections the same way you'd treat third-party API dependencies: audit the auth model, review the tool schema for injection risks, and explicitly decide what ambient permissions that server should inherit from your agent's session. The 41% headline is easy to file under "other people's problem." The ambient authority gap is yours regardless of what the server does.