41% of Production MCP Servers Have No Auth — and Only 8.5% Meet the Spec

Forty-one percent of servers catalogued in the official MCP Registry required no credentials to connect as of February 2026. Another 53% authenticated with static API keys alone — long-lived credentials with no expiration and no per-tool scope boundary. Only 8.5% implemented OAuth 2.1, the authentication model the specification mandated for internet-accessible deployments in its November 2025 revision. Over the same period, Censys tracked internet-accessible MCP services growing from 12,520 on April 28 to more than 21,000 by May 6. The authentication posture did not improve proportionally with the scale.

Method

Authentication distribution figures — 25% no authentication, 53% static API keys, 8.5% OAuth 2.1 — come from the Astrix Security 2026 audit of production MCP deployments. The 41% no-auth rate applies specifically to the official registry: an independent February 2026 scan checked all 518 accessible server records and found 212 requiring no authentication at the protocol level. Internet-accessible service counts and protocol version data come from Censys, which observed 12,520 MCP services across 8,758 unique IPs on April 28, 2026, with approximately 40% unauthenticated. Vulnerability data comes from VIPER-MCP, published May 20, 2026, which scanned 39,884 MCP repositories and identified 106 zero-day vulnerabilities.

The Authentication Distribution

The November 2025 specification revision made OAuth 2.1 with PKCE mandatory for any MCP server accessible over the public internet. Short-lived tokens, scoped permissions, and rotation on expiration are the baseline requirements — not optional hardening. The intent was to prevent the credential-sharing problems endemic to static keys: a single long-lived secret grants the same access to every caller who holds a copy, with no expiration and no per-operation scope. Three months after that revision landed, 25% of production servers still accepted connections without any credentials, and 53% had not moved past static API keys. Only 8.5% met the specification requirement.

The static key problem is structural. For local STDIO-transport MCP servers — the original deployment model — environment variables are the correct approach. A key stored in a local environment file never traverses a network boundary. The risk emerged as operators began exposing these servers over HTTP without revisiting the credential model: the same environment variable pattern that worked correctly for local use became a long-lived shared secret in a network-accessible context. Among servers enforcing static-key authentication, 79% pass those keys via environment variables in production — a configuration visible to anyone with access to container runtime settings, orchestration metadata, or cloud function configuration panels.

Scale Outpaces Security Posture

Censys identified 12,520 internet-accessible MCP services across 8,758 unique IP addresses on April 28, 2026. Nine days later the count exceeded 21,000. At approximately 1,000 net-new services per day, and with the unauthenticated fraction holding near 40%, roughly 400 new credential-free MCP endpoints were being made public daily during that window.

The Censys data also details what these services expose. The largest category was Data & Knowledge, with 1,776 services presenting database query interfaces — tools that return records from production data stores in response to natural language queries. The Infrastructure category included 687 System Control services exposing command execution and remote system interaction. Unauthenticated access to either category is not a theoretical risk.

Eighty-nine percent of observed services ran protocol version 2025-03-26, the then-current release. Operators are clearly following the specification for transport behavior. The same diligence has not carried over to authentication. Protocol version compliance and security requirement compliance are disconnected in the current deployment population.

The Rate Limiting Gap

Neither the MCP specification nor the official SDK imposes default rate limits on tool invocations. A single agent session can invoke any tool at any frequency until the underlying system fails or the session ends. For servers that proxy external APIs, each invocation translates to a downstream request, an authentication check, and possible quota consumption. An agent in a retry loop — a documented failure mode in agentic workflows — can exhaust API quotas in minutes from a single session.

The OWASP MCP Top 10 lists resource exhaustion via unlimited tool calls as a critical risk. The GitHub MCP server issue tracker documents an open thread noting that the server has no rate limits or per-tool access controls, filed after users observed agents consuming downstream API quotas unexpectedly during automated test runs.

Enterprise gateway products have addressed this at the gateway layer. Kong Gateway 3.12 added per-tool rate limit policies via its AI MCP Proxy plugin. Solo.io and TrueFoundry ship managed MCP infrastructure with in-memory token buckets that apply session and per-tool ceilings. These work, but they require a deliberate architectural choice: adding a gateway in front of the MCP server rather than deploying it directly. Most of the 21,000+ services Censys catalogued appear to be direct deployments without gateway intermediaries. Rate limiting is absent from the default server-side surface entirely.

What This Means for Site Owners

Three checks apply to any MCP server before it reaches internet-accessible deployment.

Verify the authentication model first. If the server accepts connections without credentials, that is the first fix regardless of what else the server exposes. The November 2025 specification requires OAuth 2.1 with PKCE for internet-accessible deployments. Static API keys are acceptable for local and private network contexts. They are not an acceptable credential model for any server reachable from the public internet, where key exposure cannot be bounded.

Add per-tool rate limiting at the handler level. A flat per-session invocation ceiling — returning a rate limit error after N calls per minute regardless of which tool is invoked — is the minimum viable implementation. It does not require a gateway layer. A token bucket enforced in the tool handler before any downstream call, limits the blast radius of an agent retry loop without affecting normal agentic workflows. Typical agentic tasks do not require hundreds of tool calls per minute; elevated rates are reached only in error conditions or deliberate abuse.

Audit tool description strings as a separate concern. VIPER-MCP identified 106 zero-day vulnerabilities across 39,884 repositories, a category that includes prompt injection via tool description fields. Instructions embedded in description text can redirect agent behavior without bypassing authentication — authentication controls unauthorized callers, not the behavior of authorized ones. Tool descriptions should specify parameter types and return values tersely, without open-ended natural language that can be co-opted. This applies whether the server uses OAuth or static keys: the description attack surface is independent of the credential model.