Topic starter
09/07/2026 12:38 pm
TL;DR: 1,862 internet-exposed MCP servers were found, 119 were manually verified, and all 119 exposed internal tool listings without authentication, showing that model context protocol deployments are already creating an unauthorised tool-discovery surface, according to Knostic. The governance problem is not MCP alone but the assumption that tool access can remain safe without identity-bound authorisation and scoped permissions.
Editorial analysis by NHI Mgmt Group, based on content published by Knostic: “Exposing the Unseen: Mapping MCP Servers Across the Internet”.
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.
Key questions
Q: What breaks when MCP tool listings are available without authentication?
A: What breaks is the assumption that tool metadata is harmless.
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.
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.
Practitioner guidance
- 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.
Bottom line: Internet-exposed MCP servers can reveal internal tool listings before any identity check occurs, which turns discovery into a governance problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
09/07/2026 12:44 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Internet-exposed MCP servers are broadcasting tools without auth