MCP Server Security Alert: 70% Expose Tool Lists Without Authentication

When AI's "Hands and Feet" Become Public Infrastructure

AI agents can book flights, query databases, and send emails because MCP (Model Context Protocol) servers act as the intermediary. You can think of it as a translator between AI and external tools—the agent issues commands, and the server executes them using the credentials it holds. The problem is that this translator is far too easy to leave wide open.

According to disclosures from a YouTube security channel, Wiz Research conducted a scan of publicly reachable MCP servers in July, and the results were quite ugly: about 70% of servers hand over their complete tool list directly to anonymous callers without requiring any login. In other words, anyone passing by can see what equipment is in this "restaurant's" kitchen and what dishes it can make.

It's Not Just "Looking at the Menu"

Exposing tool lists is bad enough, but the bigger problem is that 42% of servers actually returned data when tools were invoked. This means anonymous users can not only know what tools you have, but also actually trigger them. Some servers even exposed tools for creating and deleting records—once such write operations are abused, the consequences go far beyond information leakage.

Wiz Research's scanning method was simple: traverse public IPs and see who responds to the MCP protocol. Being scannable means these servers have no network-layer isolation at all and no access control configured.

MCP (Model Context Protocol) is a protocol standard proposed and open-sourced by Anthropic at the end of 2024 to standardize how AI models interact with external data sources and tools. It uses a client-server architecture: the Agent acts as the client and initiates requests, while the MCP server connects to specific systems (such as databases, email services, and cloud platforms) and holds the credentials needed to access them. The protocol itself defines standard methods such as tool discovery (tools/list) and tool invocation (tools/call), enabling Agents across different frameworks to access various tools in a unified way without writing separate adapters for each system. Because of this layer of abstraction, MCP servers effectively become aggregation points for permissions—whoever can call the server can indirectly use all the credentials behind it.

mTLS (mutual Transport Layer Security) means the client and server verify each other's certificates when establishing a TLS connection, rather than the common practice of only the client verifying the server. Compared with API keys, the advantage of mTLS is that credentials are not passed in plaintext in request headers, and certificates can be bound to specific service instances, making fine-grained authorization easier in service meshes or zero-trust architectures. OAuth, by contrast, is better suited to scenarios that require accessing resources on behalf of a user's identity, using short-lived tokens and scope restrictions to reduce the impact of credential leakage. For MCP servers, which approach to choose depends on whether the caller is a human, a service, or another Agent, but the key principle is the same: anonymous requests must be rejected at the gateway layer, not left to the tools themselves to judge.

Why Developers Make This Mistake

The MCP protocol was designed for easy integration—quickly connecting AI to existing systems. When developers test locally, the default environment is trusted, and skipping authentication saves a lot of code. By the time they deploy to the public internet, many forget to add this layer. In essence, it is exactly the same as when Redis and Elasticsearch defaulted to no password—the tech stack changed, but the way people make mistakes did not.

Another factor is that MCP servers often host "internal tools," and developers psychologically feel these things are not sensitive. But the tool list itself is an attack surface map: knowing you have a "delete user" tool tells them where to strike.

Three Hard Recommendations for Developers

First, don't throw MCP servers directly onto the public internet. If remote access is needed, use a VPN or zero-trust gateway, or at least add a layer of network isolation.

Second, authentication is not optional. API keys, OAuth, mTLS—choose a solution you can actually implement. Anonymous invocation should never be allowed in any scenario.

Third, review tool permissions. Group creation and deletion tools separately, and add secondary confirmation or approval flows. The fact that 42% return real data shows that many calls are not being intercepted.

This Is Not Just an MCP Problem

Every time a new protocol emerges in AI infrastructure, it goes through a wild growth phase of "get it running first." MCP's convenience has led to rapid adoption by various Agent frameworks, but the accompanying security practices clearly have not caught up. The most valuable part of Wiz Research's scan data is not that it tells you "there are vulnerabilities," but that it gives you the scale—the two numbers 70% and 42% show that the default configuration itself is the problem, not isolated negligence.

For enterprises using MCP to build internal AI assistants, what they should do now is not wait for an official patch, but conduct a self-check first: can your MCP server be reached directly from the external network?

The core idea of a zero-trust gateway is "never trust, always verify"—that is, do not automatically allow requests just because they come from the internal network; every access must go through identity authentication and authorization checks. Specifically for MCP servers, common implementation approaches include: deploying the server in a private subnet and exposing it only through a reverse proxy; integrating an identity provider (IdP) at the proxy layer for OAuth validation; and binding tool invocation permissions to identities, for example so that a read-only identity cannot trigger deletion tools. This approach can also provide audit logs, recording who invoked which tool and when, leaving evidence for post-incident accountability and anomaly detection.