MCP's Open Relay Problem: 40% of Live Servers Require No Authentication
A May 2026 scan of 7,973 live MCP servers found 40.55% accept tool calls without any credentials—while write-capable tools now constitute 65% of the ecosystem. Here is what that exposure looks like in practice.
Among 7,973 validated live remote MCP servers probed in May 2026, 40.55% expose their complete tool interface to any caller with no authentication required. That figure is not a staging-environment artifact: Knostic's independent scan confirmed production systems with write access to financial databases, social media accounts, and CRM platforms in a 119-server deep-inspection sample—all accessible without a single credential. The protocol is growing fast; its security posture has not kept pace.
Method
The 7,973-server count and the 40.55% authentication-gap figure come from a preprint published at arXiv in May 2026 (paper 2605.22333), which catalogued live HTTP-reachable MCP endpoints via active fingerprinting. Knostic located 1,862 servers using Shodan and Python-based tooling, then deep-inspected 119 of them for access controls and tool capabilities. Enterprise authentication preferences come from a Q1 2026 practitioner survey of teams running MCP servers in production. Tool-capability shift data covers 177,436 tools across public MCP repositories from November 2024 through February 2026.
Authentication: What Is Actually Protecting These Servers
When the 59.45% of servers that do implement access controls are examined more closely, the picture is mixed. A Q1 2026 production survey found that 77% of teams rely on shared API keys, with only 23% having deployed OAuth 2.1 with PKCE as the specification requires. Shared keys are revocable—but only by rotating the secret across every agent, every deployment pipeline, and every CI secrets store that holds a copy. A compromised key cannot be invalidated for a single agent while leaving others functional. OAuth 2.1 provides per-client tokens and instant per-token revocation without touching any other client's access.
The arXiv study classified the authentication gap as systemic rather than incidental. The scanning methodology used standard MCP JSON-RPC fingerprinting against known ports and path patterns. These servers are not obscure; they are indexed. An unauthenticated tools/list call returns the server's full capability schema—tool names, input parameter types, descriptions—before any authorization check runs.
The Risk Surface Has Grown
In November 2024, 73% of catalogued MCP tools were read-only—fetching context without modifying external state. By February 2026, write-capable tools had grown to 65% of 177,436 analysed tools: posting, modifying, deleting state in external systems. Software development tooling accounts for 67% of all MCP tools by count and 90% of SDK downloads, concentrating the highest-risk write operations—code execution, file writes, shell commands—in the segment with the most deployed servers.
A practical amplification factor: an unthrottled AI agent stuck in a retry loop against an unauthenticated MCP server can generate over 1,000 API calls per minute against downstream APIs. Without authentication to verify who is calling and rate limiting to cap what they can trigger, a single misbehaving agent can exhaust API quotas, trigger unintended mutations, or run up costs in minutes. The Knostic sample included live systems with write access to financial databases; a single agent loop against one of those is not theoretical.
Rate Limiting: The Overlooked Second Control
The MCP specification's 2026 release candidate introduced Mcp-Method and Mcp-Name HTTP request headers so that API gateways can apply per-operation rate limits without parsing JSON bodies. The intent is to allow different throttle ceilings per tool: a files/write tool should not share a call budget with a docs/read tool. The practical gap is that most self-hosted MCP deployments do not sit behind a configured gateway at all. Header-based rate routing only helps when something is reading those headers.
Practitioners who audited production servers in Q2 2026 recommend a per-tool kill-switch as a minimum viable safety control: a feature flag that disables a single tool while leaving the rest running. This prevents a vulnerable or rate-exceeded tool from requiring a full server restart and costs less than a day to implement.
What This Means for Site Owners
If you publish a public MCP server, treat your tool listing as already visible to scanners. Automated probes target standard MCP paths continuously—the 1,862-server Shodan discovery required no target list and no privileged access. At minimum, apply an authentication check at the JSON-RPC dispatcher level before processing any method, including tools/list. An unauthenticated capability listing hands a complete schema of your server's capabilities and parameter shapes to any caller.
On authentication choice: OAuth 2.1 with PKCE is the specification standard and the only option that supports per-client revocation. The incremental-scope pattern—issue a minimal mcp:tools-basic scope at first authorization, escalate only when a write tool is invoked—limits what a leaked token can do without requiring users to re-authorize for each session. If shared API keys are unavoidable for operational reasons, scope them to the minimum set of tools the client actually requires and rotate on a fixed schedule.
For rate limiting: write tools warrant a lower calls-per-minute ceiling than read tools. If a gateway in front of your server can read the Mcp-Name header, that is the right place for per-tool limits. If not, an in-process call counter per tool will catch most runaway retry loops before they reach downstream APIs.