1,800+ MCP Servers Accept Requests Without Any Auth — What's Actually Exposed?

Somebody pointed a scanner at the public internet in early 2026 and found 12,520+ live MCP endpoints. They pulled down 1,862 of them for manual verification. The result? Every single verified server permitted unauthenticated access — no credentials, no OAuth handshake, nothing between the open internet and the tool listing. And the tools sitting there weren't hypothetical: confirm_transfer, get_kyc_status, and create_transfer on a fintech platform; lookup_candidate, get_resumes, and schedule_interview on an HR system; create_refund and simulate_payment on a payments provider. No one had to steal credentials to enumerate these capabilities. They just had to make a connection.

Is 38.7% of the production MCP ecosystem really unauthenticated? According to Bloomberry's February 2026 structural analysis of 1,412 identifiable production servers, yes — for the servers where auth status was determinable, that's the number. The Censys internet scan puts the figure slightly higher at roughly 40%. The Zuplo State of MCP survey of 200+ developers and technical leaders pegs self-reported no-auth deployments at 24%. The 15-point gap between what people say and what researchers find is itself informative: the servers deployed without authentication are probably also the ones deployed without careful monitoring of what's happening on them.

So what can someone actually do with an unauthenticated MCP server?

The minimum exposure is your tool schema. MCP's tools/list call returns every tool your server exposes — names, descriptions, parameter schemas, return types. Even if tool execution is protected (and on 38-40% of live servers, it isn't), tool discovery leaks your integration architecture to anyone who asks. What services you've connected. What operations you've built. What data you can query or modify. That's valuable intelligence for anyone planning something more targeted.

When execution is also open, the attack surface is whatever your tools can do. Which brings us to the tool composition question.

Of the 4,126 tools Bloomberry analyzed across 1,412 production servers, 52% are read operations and 25% are write operations. Write operations include transactions, record creation, data modification, and scheduling — the category where execution without auth becomes a direct operational risk rather than just an information disclosure. On the 38-40% of servers with no authentication, those write tools are callable by anyone who discovers the endpoint.

Does the type of operation matter for the security exposure?

Not in the way you might think. Read operations on an unauthenticated server can be just as damaging as writes — a get_resumes call returns candidate data, a get_account call returns financial account details, a lookup_candidate call might contain employment history. The distinction between read and write matters for data integrity. For privacy and access control, it matters less than whether authentication exists at all.

The operational pattern worth noting is that tools tend to cluster by function. A server built to integrate with an HR platform has recruiting tools. A server wrapping a payments API has transaction tools. The exposure isn't random; it's aligned with whatever the builder was trying to enable for their AI agent, which means the sensitive capabilities tend to group together on the same server.

The gap between developer self-reports (24% no auth) and observed reality (38-40%) is consistent across three independent measurements. It's not a measurement artifact. Developers who deploy unauthenticated servers are less likely to audit them or notice external access. That's the demographic driving the discrepancy.

Who's building these servers, and why does that matter?

The ecosystem profile is younger and smaller than you'd expect. Bloomberry found that 81% of companies running production MCP servers have fewer than 200 employees. The median server has five tools. 70% of servers are built by B2B companies. 58% are wrappers over existing APIs rather than purpose-built from scratch.

That's the context for why the auth gap exists. A startup integrating MCP into its first AI agent workflow is starting from an existing internal tool or SaaS API. The MCP spec mandates OAuth 2.1 with PKCE S256 for remote servers — a meaningful implementation overhead when the team is also building the product, the API, and the MCP integration simultaneously. So they ship the integration first and plan to add auth in the next sprint. Sometimes that sprint arrives. Often it doesn't, because the server works, the AI agent works, and the auth gap isn't visible in normal operation.

The scale at which this is happening is not trivial. Local MCP server packages were downloaded 67 million times in April 2026 alone. Public directories now list over 16,000 servers. The authentication gap is a moving target that scales with every new developer shipping their first MCP integration.

What should you actually do about this?

The three most impactful things, in order:

Start with tool listing. Even before full OAuth is implemented, disable unauthenticated tools/list responses. Return an authentication challenge or an empty response to unauthenticated requests. Revealing your tool schema is the zero-cost discovery step for anyone probing for exposed servers. The spec allows servers to require authentication before listing tools — most frameworks don't enforce this by default, but it's a single configuration change that eliminates the easiest reconnaissance path.

Don't pass through tokens. The MCP specification explicitly prohibits passing the client's access token directly to upstream APIs. The correct pattern is for the MCP server to independently obtain a short-lived token from each upstream service. This scopes the breach radius: if your MCP server is compromised, it doesn't hand an attacker a token that works against every connected service. Token exchange is marginally more complex to implement than passthrough, and it's the difference between a contained incident and a multi-service breach.

Add server-side call logging before anything else. You cannot know whether your MCP server is being called by unauthorized parties if you're not logging which tools are called and with what parameters. This is separate from auth implementation — you can add logging to an unauthenticated server today. It tells you whether you have a problem, which is the prerequisite for everything else.

The protocol has clear answers to the authentication question. OAuth 2.1 with PKCE S256, Protected Resource Metadata discovery, and token exchange rather than passthrough — these are specified, not suggested. The implementation gap between what the spec requires and what 38-40% of the observable ecosystem has shipped is the current state of the problem. Closing it starts with knowing which category your server is in.