Someone Scanned 518 MCP Servers. 41% Had No Auth at All.
We've been saying for months that the MCP ecosystem has an auth problem. This week, someone brought receipts.
A security researcher at Kai Security scanned 518 MCP servers listed on the official MCP registry and published what they found. The numbers are worse than I expected, and I'm someone who thinks about this every day.
Here's the headline: 214 servers (41%) have no authentication at all. 156 of those expose callable tools to anyone who connects. And among the 59% that do have auth? Almost none enforce per-action authorization. A valid API key gives you access to everything.
If you're building with AI agents, these numbers should change how you think about trust.
Three Architectures, One Gap
The research identified three patterns in the wild:
1. MCP-Layer Auth (the gold standard). Servers like Slack, Linear, and GitHub's official MCP implementations enforce OAuth at the protocol level. Your agent authenticates before the server responds to anything. This matches the spec exactly. It's also the minority.
2. API-Layer Auth (the illusion). The MCP endpoint itself is wide open — anyone can call tools/list and enumerate every tool, every parameter schema, every piece of business logic the server exposes. But actual tool calls require credentials. This is how Google's MCP integrations work. It's technically "authenticated," but it leaks your entire API surface to any agent that connects.
3. No Auth at All (the long tail). The server responds to any tool call from any client. No token, no check, no questions asked. Thirty percent of all servers scanned fall here — and they're not all read-only documentation fetchers. The researcher found 32 servers with no auth that can post tweets, trigger CI/CD builds, send emails, process payments, and create websites.
Read that last part again. Thirty-two MCP servers on the registry let any AI agent that connects post to social media, trigger deployments, or process payments — no credentials required.
The Authorization Layer That Doesn't Exist
But here's the finding that hit hardest: even among the 59% of servers that have authentication, almost none implement per-action authorization.
Think about what that means. The researcher describes a three-layer risk model:
- Transport: Is the connection encrypted? (Mostly yes — HTTPS.)
- Identity: Does the server know who's calling? (59% yes.)
- Authorization: Does the server verify the caller can do this specific action? (Almost none.)
The industry got transport security right. It's getting identity partially right. But authorization — the layer that actually determines what an agent can do with your data — is nearly absent.
A valid API key gives you access to all tools. Not "the tools the user approved." Not "read-only for the next hour." All of them. Forever. Until someone manually rotates the key.
This is the same gap we wrote about two weeks ago, but now we have data. And the data says it's not a theoretical concern — it's the default state of the ecosystem.
The Enumeration Problem Nobody's Talking About
There's a subtler issue the research surfaced that deserves attention: tool enumeration.
Even servers with API-layer auth let any connecting agent call tools/list without credentials. That means your internal API surface — tool names, parameter schemas, data models — is discoverable by any agent. Tool names like get_customer_by_email and delete_subscription reveal business logic. Parameter schemas expose data structures. It's reconnaissance-as-a-service.
The MCP spec doesn't require auth before listing tools. And most implementations follow that default. It's the kind of design choice that's fine in a world where only trusted clients connect to your server. We don't live in that world anymore.
Where HTTP Was in 2010
The researcher makes an analogy I keep coming back to: MCP auth is where HTTP was in 2010. TLS existed. It worked. But it was optional, and most sites didn't bother until HSTS made it effectively mandatory and browsers started shaming HTTP sites with "Not Secure" warnings.
We're at the same inflection point. The MCP 2025-11-05 spec introduced OAuth 2.0 with PKCE as the recommended auth mechanism. It's well-designed. But "recommended" isn't "required." And when security is optional, the data shows exactly what happens: 41% of servers skip it entirely, and the rest stop at the identity layer without ever asking "should this agent be allowed to do this specific thing?"
Meanwhile, Dark Reading is calling 2026 the year agentic AI becomes the attack-surface poster child. Major ISVs — SAP, Oracle, Salesforce, ServiceNow — all have agentic capabilities that leverage MCP and non-human identities to stitch together business solutions. The attack surface is growing exponentially. The auth story isn't keeping up.
What This Means for Builders
If you're building MCP servers:
- Implement auth at the MCP layer, not just the API layer. Don't let unauthenticated clients enumerate your tools.
- Add per-action authorization. A valid token shouldn't mean "access to everything." Scope your grants to specific tools and specific operations.
- Time-limit everything. No permanent API keys. Issue tokens that expire, and build refresh flows.
- Audit tool calls. If you can't answer "which agent called which tool with which user's credentials at what time," you're flying blind.
If you're building AI agents that consume MCP tools:
- Don't trust the server. Validate tool descriptions. Don't blindly follow instructions in tool metadata — that's how tool poisoning attacks work.
- Request minimum scopes. If you only need to read a calendar, don't request write access "just in case."
- Use a trust layer. Don't manage credentials yourself. Use an auth layer that handles user consent, scoped grants, and revocation.
Why We Built TapAuth
This is exactly the problem TapAuth exists to solve. We're the trust layer between humans and AI agents — the authorization layer that the MCP ecosystem is missing.
When an agent connects through TapAuth, every tool access is:
- User-approved: The human sees exactly what's being requested and explicitly grants access
- Scoped: Read-only calendar for one hour, not "all Google services forever"
- Time-limited: Grants expire automatically
- Auditable: Every tool call is logged with the agent, the user, the scope, and the timestamp
- Revocable: Users can cut access instantly
MCP gave us the plumbing. The 518-server scan shows us what happens when you turn on the plumbing without locks on the faucets. TapAuth is the lock.
The ecosystem is telling us — with data now, not just intuition — that auth can't stay optional forever. The question is whether we build the right patterns now, or wait for the breach that forces the conversation.
We'd rather not wait.