Model Context Protocol has been rapidly gaining popularity ever since its debut, but adoption of its security features hasn't caught up. Wiz Research recently looked at one part of that gap: MCP servers that organizations have left reachable from the Internet, often entirely unauthenticated. We set out to answer two questions: How widespread this is and How bad it can get. In the course of our research we found multiple unauthenticated MCP servers, including ones run by Fortune 500 companies. These expose sensitive data like employee PII and internal business records, write and delete operations on production systems, and in some cases code execution and access to cloud credentials.
By the numbers
Despite being a relatively new technology, our data shows that MCP can be found across 80% of cloud environments.
About 1 in 6 of those environments expose at least one MCP server.
Of exposed servers:
~70% return their full tool catalog to an anonymous caller
~42% return real data when a tool is called
~10% expose a sensitive backend
A small but confirmed share is vulnerable to SSRF against the cloud metadata endpoint, returning temporary credentials.
Nearly all still negotiate the original protocol version (2024-11-05), from before authentication was added to the spec in March 2025.
How MCP works, and why “exposed” understates it
The Model Context Protocol provides a way for AI agents to use remote or local software. A server advertises a set of capabilities, a client connects and asks what’s available, the server responds with a list of capabilities and their parameters, and then the client calls whatever it needs. From an attacker’s perspective, because every MCP server speaks the same handshake, one generic client can scan any server in the world.
Here is what that looks like. A single unauthenticated curl returns the server name, protocol version, and the tools it exposes - names, descriptions, parameter schemas.
Some MCP servers act as privileged proxies. The MCP endpoint requires no authentication, but it connects to the backend using stored credentials - an API token, a database connection string - and returns the result to any caller.
A well-built server can list its tools openly but reject unauthenticated or unauthorized calls. In the course of our research we scanned many MCP servers, some of which blocked our anonymous tool calls while others allowed them. Anonymous access isn’t automatically a risk, and many MCP servers allow it by design. Whether it turns into a security risk depends on how the backend is configured, what actions the MCP server can perform, and how the two connect.
What makes exposed MCP servers easier to exploit
It’s reasonable to ask what separates this from any unauthenticated REST endpoint left open to the Internet, granting access to a sensitive server.
First, it describes itself by default. The tools/list call returns a full, machine-readable catalog of everything the server can do, with the parameter schema for each tool. An API can certainly publish the same in the form of a spec, but with MCP this is built into the protocol, so the reconnaissance potential is baked in.
Second, as mentioned above, one generic client can communicate with any server. A fleet of custom APIs doesn’t work that way (though AI-enabled scanning certainly brings us closer to that state).
Third, some MCP servers wrap a language-model agent that has shell access to the service backend and expose it as just another tool, making every request a prompt the agent acts upon. The same endpoint that returns a cost report can be talked into running malicious commands, because the only thing deciding what's allowed is the model itself, and its guardrails might be lacking.
The problem classes
Sensitive-data access is the most common class. Servers in this group proxy tools that reach production databases, internal mailboxes, issue trackers, and regulated records - returning real data to an anonymous caller because the backend credentials are baked into the deployment. One server exposed a tool that returned a named participant’s retirement-account balance with no login at all. Another proxied an internal issue tracker holding security cases alongside hardcoded credentials. A third handed back an organization’s entire application-security program: every scanned component, the findings against each one down to file and line, and which had already been written off as false positives. A BI platform exposed query_sql alongside get_connection_schemas and get_connection_table_columns, letting an anonymous caller enumerate every connected database and run arbitrary queries across them.
The March 2025 spec revision added tool annotations - flags like readOnlyHint and destructiveHint - that let a client tell safe reads from dangerous writes. Nearly all the servers we found still run the original 2024-11-05 protocol version, which predates these flags.
Write and delete access is the second most common class. These servers expose tools to create, update, and delete records against CRM, IAM, and infrastructure backends. We didn’t call any of them to avoid potentially destructive actions during our testing, so we can’t confirm every one would execute successfully. The capability is in the catalog for anyone who connects.
One IAM backend exposed add_application, update_application, and delete_application. A team management platform listed send_blast_message (“Send a text and/or email message to a group of people”) alongside tools to delete rosters and appointments.
Code execution and server-side network access are the rarest cases but arguably the most severe, and they often overlap. In some cases a tool directly runs commands or evaluates code on the server. In others, the server wraps a language-model agent that has shell access to the backend - the “tool” is really a prompt the agent acts on, and the model is the only thing deciding whether a request is allowed. The same agent can also be aimed at the cloud metadata endpoint: a tool that fetches a URL or proxies a request can reach internal services a caller could never access directly. On a small but confirmed number of hosts, we reached the instance metadata service and received temporary credentials.
One agent we tested refused a blunt request for secrets but carried out the same action once it was described as routine maintenance:
Direct secret exposure is the most straightforward class. Some tools hand back credentials or connection strings outright, with no agent or pivot needed. In one case, Lambda function logs retrieved through cloudwatch_get_lambda_logs contained environment variables with API keys. In another, a tool's response included a database connection string with embedded credentials.
Why this happens
The protocol’s first widely-used version shipped without an authentication mechanism. The spec added OAuth 2.1 in March 2025, but nearly all the servers we found still run the original version and don't use it. The pattern is the same across most of them: backend credentials baked into the deployment, a managed cloud endpoint that's internet-reachable by default, no auth layer added on top.
Why this is hard to catch
A malicious call to one of these servers looks nearly identical to a legitimate one. The server makes the same backend request with the same embedded credential it always uses, and the backend answers an authorized, well-formed request without complaint. No failed login attempt, no denied-access spike indicative of a brute-force attack, and therefore no alert. The fix is preventive: add authentication, or scope the server's backend credentials so there's nothing sensitive to reach.
For the code-execution class in particular, there's one place the activity can stand out: the agent's prompt and invocation logs may show requests that look suspicious on their own - a prompt asking for secrets, or for a command to run - even when the network telemetry looks clean. But that only helps if the deployment captures those prompts, and many don't have that logging enabled.
Recommendations
Audit which MCP servers are Internet-reachable and whether they require authentication.
If a server must be public, gate tool execution behind auth even if the tool catalog is open. The protocol now supports OAuth 2.1 out of the box - use it wherever possible. Otherwise, limit the permissions of the MCP server to prevent anonymous access to sensitive data or destructive actions.
Capture agent prompts and enable invocation logs. For the code-execution class, they’re the only place an attack leaves any useful trace.
Treat an MCP server’s role like any other privileged service account: adhere to the principle of least privilege and scope its backend credentials to the bare minimum it needs to function.