MCP Server Security Crisis: 70% of AI Agent Tool Listings Can Be Accessed Anonymously

AI agents are taking over more and more workflows, and the MCP (Model Context Protocol) servers that support their communication with external tools are exposing unsettling security gaps. In the seventh episode of SecValley Insights, host Jessica and security expert George discuss the findings of a Wiz Research scan, revealing a neglected fact: the tool bridge you built for your AI assistant may be wide open to the whole world.

What Exactly Is an MCP Server

In George's words, an MCP server is "the bridge between AI agents and tools." The agent sends a request, and the server executes the operation using the credentials it holds. The problem lies precisely in these "credentials" — the server does not care who is calling it, only what permissions it can use to complete the task.

This means an MCP server is essentially a privilege proxy layer. It translates the AI agent's intent into actual calls to Microsoft Graph, databases, and SaaS platforms. Once this bridge is exposed to the public internet and lacks authentication, anyone who knows the address can borrow all the permissions behind it.

Model Context Protocol (MCP) was proposed and open-sourced by Anthropic in late 2024. It is a protocol that lets AI agents call external tools and data sources in a standardized way. Its architecture is divided into three layers: Host (the host application, such as Claude Desktop or an IDE), Client (the protocol client), and Server (the tool provider). Communication is based on JSON-RPC 2.0 and supports both stdio local pipes and HTTP+SSE remote transport. An MCP server declares three types of capabilities externally: tools (executable actions), resources (readable data), and prompts (predefined prompt templates), and can hand the capability list to the client through interfaces such as list_tools. This design is exactly what makes the server a universal adapter between agents and external systems, but the protocol itself does not mandate an authentication method — whether OAuth or token validation is required for remote deployment depends on the implementer's choice. This is the technical root cause of why a large number of servers are exposed on the public internet by default.

The Numbers Revealed by the Wiz Scan

In July of this year, Wiz Research conducted a scan of MCP servers exposed on the internet, and the results were far from encouraging: about 70% of servers hand their complete tool list to anonymous callers — no login required, no credentials required.

More seriously, about 42% of servers returned real data when tools were invoked. Some servers even exposed tools that could create or delete records. In other words, attackers can not only see what is behind the door, but also push it open and change things.

George's assessment was direct: "Worse than you'd hope."

Why This Is an Identity Problem, Not a Configuration Problem

The discussion leads to a key judgment: the risk of MCP servers is fundamentally an identity problem.

Consider a typical scenario: an MCP server calls Microsoft Graph's mail.read with application permissions, and this permission covers all mailboxes in the tenant, requires no user login, and has no MFA prompt. Then anyone who can access that server — or anyone who can inject instructions into content that the AI agent reads — is effectively borrowing this tenant-level access.

This is far more dangerous than a traditional "weak password." Attackers do not need to crack an account; they only need to find an unprotected MCP server, or use prompt injection to make the agent send requests on their behalf. The credentials are always legitimate, and everything looks normal in the logs.

Application permissions and delegated permissions are the two paths in the Microsoft Graph permission model. Delegated permissions require a signed-in user context; operations are performed as that user and are limited by that user's visibility. Application permissions are held by the application's own service principal and run as a daemon, requiring no user login and no MFA, and often apply to the entire tenant. The typical Mail.Read application permission can read all mailboxes in the tenant, and Sites.ReadWrite.All can cover all SharePoint sites. Once such permissions are granted to an MCP server, the server's credentials become a master key that bypasses all user-level controls. During audits, focus on service principals in Entra ID that have been granted high-privilege application roles, and use conditional access policies to restrict their source networks.

Prompt injection is the key link that escalates MCP risk from passive exposure to active attack. Attackers do not need direct access to the server; they only need to hide malicious instructions in content that the agent will read — an email body, a web page, a document — and the agent may be induced, while processing that content, to call connected tools and perform read or write operations using the server's legitimate credentials. Because the request genuinely comes from an authorized agent, traditional logs and permission checks will classify it as normal behavior. When this type of attack is combined with MCP's exposure surface, a complete chain forms: anonymously list tools on the public internet → locate a high-privilege server → drive the agent through injection to act on the attacker's behalf. This is why the discussion emphasizes incorporating server access control and content trust boundaries into the design together.

Three Things You Can Do This Week

George's action recommendations are as specific as possible, avoiding staying at the level of principles.

First, ask one question: Which MCP server holds Graph credentials, and who can access it? Once found, tighten access control immediately. This is the highest-priority investigation action, because exposure of tenant-level mail read/write permissions has the greatest impact.

Second, every remote server must require login. Not some servers — every one. Assign each server an independent identity and grant only the minimum permissions it actually needs. Shared credentials or overly broad application permissions will turn a single point of failure into a failure of the entire environment.

Third, newly onboarded AI connectors should require administrator approval. Make the introduction of connectors a recorded and auditable process, rather than something a developer can configure and put online casually.

Visibility Is the Starting Point for Protection

SecValley's own approach is to flag, in every scan, service principals that hold broad tenant-level permissions, such as the ability to read and write every mailbox. This approach is worth adopting: before discussing how to harden, first figure out what you are actually exposing.

The MCP ecosystem is still in a period of rapid expansion, with a large number of servers deployed by developers themselves, and default configurations often prioritize availability over security. Wiz's data shows that this is no longer an isolated oversight but a widespread phenomenon. For teams using AI agents, inventorying MCP servers, reviewing their credential scope, and closing anonymous access are currently the security actions with the highest return on investment.

As the half-joking reminder at the end of the episode goes: go find that Graph credential.

One-line Summary

A Wiz scan found that 70% of public MCP servers anonymously expose tools, and the risk is fundamentally a credential identity problem.

Paragraph Summary

Episode 7 of SecValley Insights discusses the results of Wiz Research's MCP server scan. The scan shows that about 70% of MCP servers exposed on the public internet hand their complete tool list to anonymous callers, about 42% return real data when invoked, and some even expose the ability to create or delete records. Host Jessica and security expert George point out that the root cause is not a configuration oversight but identity design: MCP servers proxy AI agent requests with their own credentials. If they hold Microsoft Graph application permissions that cover the entire tenant (such as mail.read), anyone who can reach the server is effectively borrowing this tenant-level access, with no login and no MFA, while everything looks normal in the logs. The episode offers three immediate actions: identify servers holding Graph credentials and tighten access, require login for every remote server and assign independent least-privilege identities, and require administrator approval for new AI connectors. It also emphasizes understanding your exposure surface before discussing hardening.