Internet-exposed MCP servers are broadcasting tools without auth

At a glance

What this is: Knostic’s research shows that exposed MCP servers can broadcast internal tool listings to unauthenticated users, turning protocol discovery into an access-control problem.

Why it matters: IAM and NHI teams need to treat MCP endpoints as identity-bound services, because unauthenticated tool enumeration creates a direct path from exposure to misuse.

By the numbers:

• Knostic identified 1,862 MCP servers exposed to the internet.
• Knostic manually verified a sample of 119 exposed servers.
• All 119 manually verified servers granted access to internal tool listings without authentication.

Context

MCP servers are tool brokers that expose capabilities to clients, and in this case the security gap is straightforward: the servers answered unauthenticated requests with internal tool listings. That makes identity enforcement part of the protocol boundary, not a later hardening step.

Knostic’s study matters to IAM and NHI practitioners because a service that advertises tools without validating the requester turns exposure into an access problem. The finding also shows that early-stage adoption can create public discovery surfaces before governance catches up.

This is not a theoretical design flaw. The sample servers were not just reachable, they were operational enough to enumerate, which means teams may already be deploying MCP with production intent but without access control maturity.

Key questions

Q: What breaks when MCP tool listings are available without authentication?

A: What breaks is the assumption that tool metadata is harmless. Anonymous listings give outsiders a map of internal capabilities, which shortens reconnaissance and helps them prioritise targets. Even without direct compromise, the organisation has already revealed enough structure to make later abuse easier and faster.

Q: Why do unauthenticated MCP servers create governance and audit risk in enterprise environments?

A: Unauthenticated MCP servers make it impossible to tell which user or organisation is invoking a tool, which breaks accountability at the source. That creates blind spots for access control, data scoping, and incident review. Once AI clients can reach sensitive capabilities without identity, teams lose the ability to apply least privilege or reconstruct who did what.

Q: What are the signs that an MCP deployment is not ready for production?

A: Common warning signs include tool server sprawl, unmanaged access tokens, broad service-account credentials, and audit logs that cannot reconstruct the user, agent, policy, and action chain. If teams cannot prove who acted, what was called, and under which permissions, the deployment is still in prototype territory and not ready for regulated production use.

Q: How should security teams treat DNS in identity and access programmes?

A: Security teams should treat DNS as an upstream dependency for access, not as a separate network concern. If name resolution is slow, unstable, or tampered with, authentication, federation, certificate validation, and service discovery can all fail before identity controls are applied. DNS therefore belongs in access assurance, resilience testing, and incident response planning.

Technical breakdown

Why unauthenticated MCP discovery becomes an access problem

MCP servers use protocol-defined handshake and discovery patterns so clients can identify capabilities before invoking tools. When those discovery responses are exposed without authentication, the server effectively publishes its internal tool catalogue to anyone on the internet. That is different from ordinary website exposure because the enumeration itself reveals operational functions, not just static content. In identity terms, the first trust decision happens at discovery time, not only at execution time. If the server does not bind discovery to an identity, the boundary between public reachability and authorised use disappears.

Practical implication: Treat MCP discovery endpoints as protected identity surfaces, not passive metadata endpoints.

What tool listings reveal about MCP deployment maturity

A tools/list response tells a requester what the server can do, which often maps directly to sensitive internal actions, data sources, or workflow integrations. If that response is available without authentication, an attacker can map the environment before attempting abuse. In early deployments, the risk is not just that tools may be callable. The risk is that the server exposes enough structure to support targeting, service discovery, and later abuse of adjacent credentials or integrations. That is why discovery controls and authentication cannot be separated in MCP governance.

Practical implication: Restrict tool enumeration to authenticated identities and log every discovery request.

Why protocol design and deployment practice both matter

Knostic’s findings point to a split responsibility. The protocol ecosystem may allow insecure defaults, but operational deployment determines whether those defaults reach the internet. This means risk concentrates in server configuration, exposure management, and how teams treat the MCP endpoint inside the wider identity model. If the environment assumes that protocol compliance implies trust, teams will miss the governance gap entirely. The real control question is whether the server can distinguish an approved agent, user, or integration from an unauthenticated probe.

Practical implication: Model MCP servers as externally reachable applications that need explicit identity, authorisation, and exposure governance.

Threat narrative

Attacker objective: The attacker objective is to enumerate internal tool capabilities without authentication and use that visibility to prepare for later abuse or follow-on access.

1. Entry occurs through internet exposure of an MCP server that responds to unauthenticated, protocol-compliant handshake requests.
2. Credential access is not required for discovery because the server itself returns internal tool listings to any requester who asks.
3. Impact begins when exposed tool intelligence enables reconnaissance, targeting, and potential misuse of internal capabilities behind the server.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Unauthenticated MCP discovery is an identity failure, not a documentation issue: when a server reveals its tool catalogue before checking who is asking, the access decision has already failed. That means IAM has to govern discovery as well as invocation, because tool enumeration itself is a privileged signal. Practitioners should treat MCP exposure as a control boundary problem, not a usability trade-off.

Need-to-know for tools must start at the handshake: the article shows that protocol-compliant handshakes can still leak enough information to map internal capability. That creates a new form of identity blast radius, where a single open endpoint exposes operational intent, integration surfaces, and downstream workflow risk. Teams need to recognise that authorised use and visible capability are no longer the same thing.

Early-stage MCP adoption is already producing governance debt: the sample was small relative to the likely installed base, yet none of the verified servers enforced authentication for tool listings. That suggests security is being bolted onto MCP after deployment rather than built into the access model. The implication is that governance teams need to measure exposure and authorisation before broad rollout becomes the default.

MCP exposes the gap between transport trust and identity trust: a server can be reachable, compliant, and operational without being safe to query. That separation matters because many programmes still assume that if the endpoint speaks the right protocol, the requester has some implied legitimacy. The practical conclusion is that protocol compliance must never be confused with authorisation.

Tool discovery is the new sensitive surface in AI infrastructure: once internal capabilities are broadcast without auth, the control problem shifts from blocking calls to controlling visibility. That is a broader NHI lesson for AI-connected systems, where the first leak may be the shape of the environment rather than the data inside it. Practitioners should reclassify tool listings as governed access artefacts.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Tool visibility has become an access-control issue: MCP deployments can leak enough structure at discovery time to create a usable attack map, even when no tool is invoked. That shifts governance from runtime-only enforcement to endpoint-level authorisation and exposure management.

Need-to-know now applies to tool catalogues: if a server can reveal its internal functions without identity checks, the problem is not just secrecy but delegated trust. Teams should assume tool listings can be sensitive operational artefacts, especially when protocol discovery is internet reachable.

According to the State of Secrets Sprawl 2026, 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows that MCP is already accumulating the same governance debt seen in other fast-adopted identity surfaces.

For practitioners

• Protect MCP discovery endpoints Require authentication before any handshake or tools/list response is returned, including environments that are only intended for internal use.
• Inventory exposed MCP services Scan internet-facing assets for MCP markers, endpoint paths, and banner fingerprints so public tool surfaces are identified before they are used.
• Log and review tool enumeration Capture every unauthenticated discovery attempt, then investigate repeated requests for tool names, server banners, and endpoint metadata.
• Separate protocol support from authorisation Design MCP deployment standards so protocol compatibility never implies access approval, and make identity-bound authorisation mandatory for all tool surfaces.

Key takeaways

• Internet-exposed MCP servers can reveal internal tool listings before any identity check occurs, which turns discovery into a governance problem.
• The verified sample in this study showed a uniform failure pattern, not an isolated misconfiguration, which points to a broader maturity gap in MCP deployments.
• Practitioners should govern MCP as an identity-bound service surface, with authenticated discovery, exposure scanning, and logging around tool enumeration.

Key terms

• MCP Server Exposure: MCP Server Exposure is the risk that a Model Context Protocol server can be reached, misused, or observed by unauthorized parties. It covers exposed endpoints, weak authentication, overbroad tool access, and unsafe data sharing. In practice, exposure can let an AI agent invoke tools, retrieve sensitive context, or leak credentials.
• Authenticated Discovery: Authenticated discovery is the requirement that a requester prove identity before a service reveals what tools, functions, or resources it exposes. For MCP, this means even read-only catalogue responses must be behind authorisation, because the catalogue itself can be sensitive operational information.
• Tool enumeration: The act of listing the capabilities a server exposes before any tool is called. In MCP, enumeration is itself a security-sensitive event because revealing sensitive tools to the wrong principal can create a precursor to misuse or social engineering.
• Identity Chained Authorisation: Identity chained authorisation is a pattern for preserving who approved a task and what authority was delegated as work moves across agents and services. Each receiving system uses that evidence alongside its own policy, so access decisions can be tied back to the originating approval, the acting principal, and the intended scope of use.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.