MCP Authentication in 2026: 25% Open, 53% on Long-Lived Keys
Six months after OAuth 2.1 became mandatory in the MCP spec, 25% of production servers have zero authentication and 53% rely on static API keys.
One in four production MCP servers has no authentication at all. The November 2025 revision of the Model Context Protocol specification made OAuth 2.1 with PKCE mandatory for all HTTP-based servers. As of May 2026, 25% of servers on the official registry ignore that requirement entirely — no API key check, no token validation, nothing preventing any agent from calling every tool endpoint the server exposes.
Method
This post synthesizes data from three sources: the Zuplo State of MCP survey (technical practitioners, Nov–Dec 2025), the Astrix State of MCP Server Security audit (automated analysis of public registry entries), and a DEV Community analysis covering 118 security findings across 68 packages. Server population data is anchored to the official MCP Registry, which logged 9,652 records on 24 May 2026, and the GitHub mcp-server topic count of 15,926 repositories on the same date.
Authentication method distribution
A majority of deployed servers — 53% — rely on static API keys. The pattern is straightforward: the client sends a static secret in an Authorization: Bearer header, the server validates against a stored string, and the session proceeds. Static keys have no expiry, no revocation workflow, and no scope constraint. A single leaked key grants unrestricted access to every tool the server exposes, indefinitely. Rotation requires a coordinated change on both the client and server side.
The spec-compliant cohort — OAuth 2.1 with PKCE, access tokens scoped per RFC 8707 — sits at 8.5%. That is fewer than one in ten publicly registered servers. OAuth 2.1 was defined as the auth standard in March 2025, reframed as a resource-server model in June 2025, and PKCE was made mandatory in November 2025. The current 8.5% compliance rate is roughly where most ecosystems land six months after a security-forward spec revision.
The remaining ~14% cover heterogeneous approaches: environment-variable secrets passed from the host process (appropriate for local stdio servers, not remote HTTP endpoints), bearer tokens without a backing OAuth authorization server, and custom header schemes with no published expiry or revocation path.
The 25% with no authentication at all represent the acute risk segment. Any agent that can reach these endpoints can invoke every tool, read every returned value, and chain operations without any access record. In January 2026, a mass internet scan found over 1,000 MCP server instances running without authentication, leaking API keys, collaboration-tool credentials, and session histories to any caller that connected.
Security as the primary adoption barrier
The Zuplo survey found that security and access control is the top stated challenge among MCP builders, cited by 50% of respondents. More concretely, 38% say security concerns are actively blocking increased MCP adoption within their organizations — not a theoretical risk but a live deployment constraint.
Separately, 41% of surveyed software organizations had MCP servers in limited or broad production as of early 2026. The gap between "deployed and growing" and "security posture in place" is not narrow. Builders know the exposure exists and are choosing to ship anyway, or are blocked from broader rollout until it is addressed.
A further data point: 58% of MCP builders say they are wrapping existing APIs rather than building from scratch. The implication is that auth coverage is partially inherited — if the upstream API requires a valid token, the MCP wrapper may carry that forward. But the wrapper itself often adds a new unauthenticated surface: the MCP endpoint through which agents invoke the tool, before the underlying API credential is forwarded.
Rate limiting: the protocol-level gap
Authentication controls who can call a tool. Rate limiting controls how many times they can call it. The MCP specification has no protocol-level mechanism for either.
There is no standard way to publish per-tool invocation caps, session-level token limits, or context-size ceilings in a server metadata document. An agent that authenticates successfully faces no built-in throttle. Cost exhaustion attacks — agents requesting maximum-context tool responses in tight loops — are invisible to the protocol layer.
MCP gateway products address rate limiting at the infrastructure layer, implementing per-tool, per-user, and per-team quotas with sub-millisecond enforcement overhead. But these are add-on deployments, not protocol guarantees. A server deployed without a gateway receives no rate protection by default. The 2026 MCP roadmap prioritizes stateless operation, browser-based agent PKCE flows, and enterprise SAML/OIDC integration — protocol-level rate limiting does not appear in the published roadmap.
The discovery gap
The .well-known/mcp.json endpoint for automated server discovery is still a proposal. SEP-1649 and SEP-1960 are under active discussion; an IETF Internet-Draft (draft-serra-mcp-discovery-uri) is in progress. Until the mechanism is ratified and client-side support ships, AI assistants learn about MCP servers through manual configuration, third-party registries, or hardcoded references. There is no structured channel for a server to publish its authentication requirements — or the absence thereof — before a connection is attempted.
The consequence: when an AI assistant connects to an MCP server for the first time, it negotiates auth requirements at runtime, after the transport is already open. Servers that want to signal their auth posture can include it in the initialize response, but nothing in the current spec requires them to, and no standard client behavior exists for handling a downgrade from expected to actual auth level.
What this means for site owners
If you are deploying a public MCP server, OAuth 2.1 with PKCE is not optional under the current spec for remote HTTP endpoints. Hosted authorization servers from identity providers including Auth0, WorkOS, and Stytch all publish MCP-specific integration documentation. The tooling is mature; the gap is implementation prioritization.
Treat static API keys as scaffolding, not production auth. They carry no lifecycle: no expiry, no per-agent scoping, no audit trail of which key was used by which client at which time. If a key is compromised — and agent environments substantially increase the attack surface, since tools can be invoked autonomously without human review of each call — revocation requires a coordinated change across every client that holds a copy.
Rate limits belong at the application layer until the protocol catches up. If you are not deploying a gateway, implement per-tool invocation caps and session-level token budgets directly in the server. A sliding-window counter keyed on client identity is the practical starting point: 100 tool calls per minute per authenticated agent is a reasonable default for most data-serving use cases.
Finally, audit your tool permission surfaces independently of authentication. The most common finding in published MCP security audits is not missing auth — it is tools exposing broader data or more operations than the documented use case requires. Minimize tool schemas to the narrowest necessary input and output. What your tools return shapes what AI assistants know about your data, across every interaction, indefinitely.