The Unauthenticated MCP Server

What this is

An unauthenticated MCP server is a Model Context Protocol server, reachable over a network, that accepts tool calls from any client without a valid credential. Because MCP tools are chosen for their power - they read internal data, query production databases, restart services - an unauthenticated server exposes those capabilities to anyone who can reach it. It is not an information leak. It is a remote control with no lock on it.

This is one of the fastest-growing surfaces we test, because it did not meaningfully exist two years ago and now ships with almost every AI feature.

Why it keeps happening

MCP was designed for a trusted setting: an AI agent and its tools, running together on one machine or one private network. In that setting, not requiring authentication is a reasonable default - the only caller is the agent you built.

The trouble starts when that server moves to production. A team builds an agent, gives it tools that do real work, and stands the server up on a host so the agent can reach it. Under deadline pressure, the tools are the deliverable and the authentication is assumed - “only our agent talks to this.” Then the host turns out to be reachable from outside the private network, and nobody circled back to add the auth that the trusted-caller assumption quietly depended on.

This is the same collision Greywatch sees across AI-forward teams: code ships fast, a new protocol arrives with a trusting default, and the gap between “works for our agent” and “safe on a reachable host” is exactly one control that no one was assigned to add.

How the attack works

MCP has a small, predictable handshake, which makes an exposed server trivial to identify:

1. initialize starts a session. On an unauthenticated server, it succeeds with no credential.
2. tools/list returns the catalog - every tool the server exposes, with its parameters. This alone is a serious disclosure: it maps the internal capabilities the agent was given.
3. tools/call runs a tool. Whatever the tool does, the anonymous caller can now do.

There is a second, subtler failure we see often: the server checks that an Authorization header is present but never validates the token inside it. A made-up bearer string returns 200. This is functionally identical to no authentication, and it is more dangerous because it looks authenticated in a casual review.

What it looks like in the wild

We have found this pattern across very different companies, which is what makes it a pattern and not an anecdote.

• A cloud-telephony platform exposed an MCP server whose tools reached into its production estate across multiple regions - inventory of internal servers and databases, plus tools to delete rows, delete files, and restart services. No credential was required, and an invalid token returned 200. On a company whose product is keeping phones connected, an anonymous “restart service” tool is a denial-of-service button. Full teardown: The MCP Server That Ran Production.

• A real-estate CRM ran an MCP server that authorized on the presence of a bearer token, not its validity. Sending Authorization: Bearer test returned the full catalog of internal tools, exposing more than a hundred internal CRM routes to an unauthenticated caller.

• A B2B messaging platform and a coworking-management SaaS each exposed tools/list without authentication and, separately, allowed open dynamic client registration - anyone could register a client and enumerate the server’s capabilities, mapping the internal surface even where the sensitive tool calls themselves failed closed.

• A payments-orchestration company left an internal MCP catalog readable without authentication, disclosing the set of internal tools it had wired up for its agents.

The consistent theme: the catalog leaks first, and on the servers where the tools were not separately gated, the catalog is the exploit.

How to tell if you are exposed

A five-minute self-check:

1. From outside your private network, resolve your MCP server’s address and send an initialize request with no credentials. If it succeeds, the server is reachable and unauthenticated.
2. Send any request with a deliberately invalid bearer token. If you get 200 instead of 401 with a WWW-Authenticate challenge, your server is validating presence, not the token.
3. Call tools/list. Read the catalog as an attacker would: which of these tools touch production data or change state? Those are your blast radius.

How to fix it

1. Authenticate the transport, and validate the token. Reject missing credentials and invalid credentials with a real 401. Presence checks are not authentication.
2. Keep the server off the public internet. An MCP server for an internal agent belongs on the private network, behind your mesh or a VPN. Treat public reachability as an alertable misconfiguration.
3. Least-privilege the tools. The registered tools are the attack surface. Scope each to the narrowest job, and separate read from write.
4. Never expose destructive tools on a reachable endpoint. Delete, restart, and cleanup belong behind a separate authenticated and audited path - never in a catalog that untrusted callers can reach.
5. Log and attribute every tools/call. If you cannot tie a call to your own agent, treat it as an intrusion. Open servers are usually open for a while before anyone notices.

The takeaway

Treat an MCP server as the most powerful administrative interface you run, because its tools were chosen for power. Authenticate it like one, isolate it like one, and never let a destructive tool sit one anonymous request away from production.