Why 40% of MCP Servers Have No Authentication

A security researcher deployed a honeypot MCP server with a single tool exposed: get_aws_credentials(role="admin"). It received its first call within 48 hours of going live; no reconnaissance phase, no credential stuffing attempt, nothing that looked like an attacker probing the environment first. An autonomous AI agent, scanning for available tools, simply found it and called it.

That anecdote is dramatic, but it isn't an outlier. A peer-reviewed measurement study that actively scanned 7,973 validated remote MCP servers found that 3,233 of them (40.55%) expose tool interfaces with no authentication mechanism at all. Any client capable of establishing a connection can invoke tools or trigger API requests without presenting a single credential. This guide covers what that gap actually exposes, why it keeps happening at this scale across an ecosystem that's barely two years old, and what real authentication for an MCP server requires.

How Many MCP Servers Actually Have No Authentication?

The specific figure varies by study and methodology, but every independent measurement converges on the same conclusion: a substantial share of MCP servers, somewhere between roughly a quarter and 41%, run with no authentication whatsoever.

Sources: Academic measurement study, BlueRock scan, Continuous MCP registry scanning ("Kai" dataset), Trend Micro research, Zuplo State of MCP survey

The lowest figure in that table comes from the least rigorous method; a self-reported survey of roughly 100 builders, which tends to undercount relative to active scanning, since builders self-reporting a security gap face an obvious incentive not to. The two most methodologically rigorous sources; an active academic scan of nearly 8,000 servers, and an independent scan of roughly 7,000 more; both land within a point of each other, at 40.55% and 41%. That convergence across independently conducted studies using different scanning methodologies is what makes the roughly 40% figure the more defensible number to build a security argument around, rather than the lower survey-based figure some earlier coverage of this topic has cited.

Scale matters as much as percentage here. Censys separately counted 12,520 MCP services reachable from the public internet, a large enough population that even the more conservative end of the authentication-gap range still translates to thousands of individually exposed servers, not a handful of edge cases.

What Does "No Authentication" Actually Mean for an MCP Server?

An MCP server with no authentication accepts and executes tool calls from any client that can establish a connection to it, with no credential, token, or identity check of any kind at the protocol level. This is distinct from a server with weak authentication (a static API key, for instance) which at least requires the caller to present something, even if that something is poorly managed.

The same academic measurement study broke authentication status down into three categories across its full sample of 7,973 validated servers: 40.55% with no authentication at all, 30.45% using OAuth-based authentication flows, and 29% relying on static tokens or API keys. The no-authentication category is the most severe by definition, but the static-token category carries its own real risk, a leaked or hardcoded API key provides the same effective access as no authentication at all, once it's been exposed in a public repository or a client-side configuration file, which happens more often than the nominal presence of "authentication" would suggest.

What Can an Attacker Actually Do With an Unauthenticated MCP Server?

An attacker or, as the honeypot example shows, an autonomous agent with no attacker behind it at all, can invoke any tool the server exposes, with whatever permissions that server itself holds against its backend systems. What that means in practice depends entirely on what the server was built to do.

The same measurement study identified a real case rather than a theoretical one: an unauthenticated MCP server connected to a CRM system, exposing over 5,000 internal enterprise records like customer names, email addresses, phone numbers, and physical addresses to any client able to connect, with no credential required. The issue was reported and assigned CVE-2025-61510. The server had been intended as an internal-only service; the authentication mechanism was simply never added.

Trend Micro's separate research identified 492 MCP servers exposed on the public internet with no authentication or traffic encryption, collectively exposing 1,402 tools, more than 90% of which offered direct read access to their underlying data source, and 74% of which were hosted on major cloud providers. Among the categories of exposed tools researchers have documented across these scans: CI/CD pipeline triggers, social media management tools, database query interfaces, and cloud infrastructure controls, meaning an unauthenticated MCP server isn't necessarily a low-stakes exposure limited to read-only data.

The CVE-2025-61510 case isn't an isolated finding, either. A separate sweep of roughly 40,000 MCP server repositories, run under the name VIPER-MCP, produced 67 distinct CVEs across the ecosystem, evidence that authentication gaps are one symptom of a broader pattern of MCP servers shipping without the security review a comparably exposed traditional service would receive. LangProtect's enterprise guide to MCP security covers the fuller range of attack patterns these exposures enable once a tool call succeeds, including tool poisoning and cross-server lateral movement.

Why Do So Many MCP Servers Ship Without Authentication?

The pattern researchers point to consistently is speed: MCP servers are frequently built by wrapping an existing internal API to make it agent-accessible quickly, and that wrapping step doesn't automatically inherit the security review the original API went through when it was built for a narrower, trusted audience. The Zuplo survey found that 58% of builders describe their MCP servers as wrapping existing APIs, a pattern that makes sense given how fast MCP adoption has moved, but one that quietly reintroduces exposure every time an internal-only API gets a new, more accessible front door without anyone re-evaluating who can now reach it.

This mirrors a governance gap LangProtect has covered in the broader context of non-human identity management: an MCP server, like an API key or a service account, is a non-human identity in its own right, and it inherits the same problem which is provisioned quickly, without the same review process a new human employee's access would go through, and easy to lose track of once it's live. The same survey found that only about 23% of organizations have a formal AI-agent identity strategy at all, which helps explain why authentication gaps at the server level persist rather than getting caught during a governance review that, for most organizations, doesn't currently exist.

The pace of adoption compounds this rather than easing it over time. Cisco's State of AI Security 2026 report found that 83% of organizations plan to deploy AI agents into their business functions, while only 29% feel their security posture is actually ready for it, a gap between deployment velocity and security readiness wide enough that the authentication statistics in this guide look less like an anomaly and more like the direct, predictable consequence of that imbalance.

There's also a discovery problem underneath the authentication problem: an organization can't fix an authentication gap on a server it doesn't know is running. LangProtect's guide to zero-day AI detection covers the parallel challenge for AI applications generally, the same "it was never catalogued, so no one reviewed it" pattern applies directly to internally-spun-up MCP servers that never went through a formal deployment or security process.

What Does Proper MCP Authentication Actually Look Like?

Baseline MCP server authentication requires OAuth 2.1 with mandatory PKCE (Proof Key for Code Exchange), validated token audience, and a specific rule that's easy to get wrong even with OAuth correctly configured: never pass a client's token through to an upstream API unchanged.

That last point addresses a specific, well-documented failure pattern sometimes called the confused deputy problem: an MCP server that simply forwards the token it received from a client to whatever backend service it's calling, without verifying that token was actually issued for that specific downstream service, can be tricked into acting as a proxy for access the original token was never meant to grant. Correct implementation validates the token's audience against RFC 8707 and RFC 9068, confirming a token was actually minted for this specific server (before accepting it), rather than assuming any successfully-presented token is valid for whatever the server does next.

Beyond authentication specifically, the same research that measured the no-auth rate also found MCP servers carry other correlated weaknesses worth addressing in the same pass: a March 2025 audit by Equixly found 43% of scanned servers had command-injection flaws and 30% were exploitable via server-side request forgery, vulnerabilities that authentication alone doesn't close, since an authenticated but poorly validated tool call can still be abused by a legitimate, credentialed caller. Input validation and egress restrictions on outbound requests remain necessary even after authentication is fixed.

How Do You Check Whether Your Own MCP Servers Are Exposed?

Start by inventorying every MCP server your organization runs (internal and externally-facing) since the exposure pattern researchers keep documenting begins with servers nobody remembered were internet-reachable at all. For each one, confirm three things directly rather than assuming: whether authentication is required at all, whether that authentication validates token audience rather than accepting any presented token, and whether the server is reachable from the public internet when it was only ever intended for internal use.

Authentication is the highest-impact fix precisely because it's the one most consistently missing, but it's one piece of a larger baseline. The NSA's Artificial Intelligence Security Center published its own guidance on MCP in May 2026, "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation," a 17-page Cybersecurity Information Sheet identifying eight named risk categories and nine specific recommendations for production MCP deployments. Beyond authentication, several of its recommendations map directly onto the gaps this research keeps finding: grant only the minimum access an MCP tool actually needs, rather than broad standing permissions; keep sensitive data processing local where possible instead of routing it through third-party infrastructure by default; validate every input rather than trusting that data passed between systems is safe; and apply message-level integrity checks (signing requests with expiration timestamps and replay protection), so a captured or replayed message can't be reused later. The NSA guidance also names risks that authentication alone never addresses, including poor or missing audit logs and MCP systems' susceptibility to being overwhelmed by request floods.

Pairing that hardening baseline with a discovery step is what closes the loop, knowing a server needs least-privilege access and input validation doesn't help if the server itself was never inventoried in the first place. LangProtect's guide to what a full MCP security implementation actually requires gives a fuller picture of what comes after authentication is confirmed like access scoping, runtime enforcement, and audit logging for whatever gets called once a credential check has passed.

MCP Authentication Readiness Checklist

Frequently Asked Questions

What percentage of MCP servers actually have no authentication?

The most rigorous available research (an active scan of 7,973 validated remote MCP servers) found 40.55% had no authentication at all. A separate independent scan of roughly 7,000 servers found a closely matching 41%. Lower figures around 24-25% come from self-reported builder surveys, which tend to undercount relative to active scanning methodology.

What's the difference between "no authentication" and "weak authentication" for an MCP server?

No authentication means a server accepts tool calls from any connecting client with no credential check at all. Weak authentication (most commonly a static API key or token) at least requires a caller to present something, but carries similar effective risk once that key is leaked, hardcoded in a public repository, or exposed in client-side configuration, which occurs frequently enough that a present-but-poorly-managed credential shouldn't be treated as meaningfully safer.

Can an authenticated MCP server still be vulnerable to unauthorized access?

Yes, through the confused deputy problem, a server that forwards a client's token to an upstream API without validating that the token was actually issued for that specific service can be manipulated into granting access the original token was never meant to authorize. Proper implementation validates token audience against RFC 8707 and RFC 9068 rather than accepting any successfully-presented token as sufficient proof.

Why do so many MCP servers end up unauthenticated in the first place?

Primarily because MCP servers are frequently built by wrapping an existing internal API for fast agent access, and that wrapping step doesn't automatically carry over the security review the original API received. Combined with the fact that only about 23% of organizations have a formal AI-agent identity strategy, authentication gaps at the server level often go uncaught simply because no governance process exists to catch them before deployment.

What kinds of systems have been found exposed through unauthenticated MCP servers?

Documented cases span CI/CD pipeline triggers, social media management tools, database query interfaces, cloud infrastructure controls, and CRM systems; including one documented case (CVE-2025-61510) where an unauthenticated server exposed over 5,000 real customer records from a CRM. Research from Trend Micro found more than 90% of tools on a sample of 492 exposed servers offered direct read access to their underlying data source.

Does fixing authentication alone make an MCP server secure?

No. The same research measuring authentication gaps also found high rates of command-injection and SSRF vulnerabilities in MCP servers independent of their authentication status, an authenticated server with unvalidated tool inputs can still be abused by a legitimate, credentialed caller. Authentication closes who can call a tool; input validation and egress controls address what happens once a call is accepted.

What does the NSA's MCP guidance actually recommend besides authentication?

The NSA's AI Security Center published a formal guidance document in May 2026 identifying eight risk categories and nine recommendations for production MCP deployments. Beyond requiring authentication, key recommendations include granting only the minimum access a tool actually needs rather than broad standing permissions, keeping sensitive data processing local rather than routing it through third-party infrastructure, validating every input passed between systems, and applying message-level integrity checks to prevent captured requests from being replayed later.

How quickly can an organization find out if its own MCP servers are exposed?

An initial inventory of known MCP servers, checked against authentication status and public reachability, can typically be completed within days for organizations with a limited server footprint. The harder and ongoing work is finding servers nobody formally tracked in the first place (internally spun-up servers that were never catalogued) which requires continuous discovery rather than a single audit pass.

Authentication Is the Cheapest Fix With the Highest Impact

Roughly 40% of MCP servers currently run with no authentication at all, verified by an active scan of nearly 8,000 real deployments, not an estimate. The exposures documented against that gap aren't hypothetical like a real CVE, real customer records, real cloud infrastructure controls, and an autonomous agent finding and calling an exposed AWS credentials tool within 48 hours of it going live.

Fixing this specific gap doesn't require a sophisticated security program. It requires knowing which MCP servers actually exist in an environment, and confirming each one requires a properly validated credential before it accepts a single tool call.