Notifications
Clear all
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.
NHIMG editorial — based on content published by Knostic: exposed MCP servers and unauthenticated tool access
By the numbers:
- Knostic identified a total of 1,862 MCP servers exposed to the internet.
- All 119 servers granted access to internal tool listings without authentication.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern unauthenticated MCP server exposure?
A: Security teams should treat any MCP server that responds before authentication as an overexposed identity endpoint.
Q: Why do MCP servers create risk for IAM and NHI programmes?
A: MCP servers create risk because they expose tool authority through a machine-facing interface, and that authority can exist before identity is checked.
Q: What breaks when tool listings are visible without authentication?
A: What breaks is the assumption that capability disclosure is harmless until execution begins.
Practitioner guidance
- Inventory MCP endpoints as governed identities Add MCP servers to the same inventory used for service accounts, API keys, and workload identities.
- Block unauthenticated capability enumeration Require authentication before tools/list or equivalent discovery calls can return any internal tool metadata.
- Reduce protocol fingerprintability Remove obvious endpoint paths, standard banners, and unnecessary protocol markers from public exposure where possible.
What's in the full report
Knostic's full research post covers the operational detail this post intentionally leaves for the source:
- The exact Shodan filter strategy used to fingerprint MCP servers across protocol markers, endpoint paths, and headers.
- The verification workflow for safely testing tools/list responses without invoking tool execution or changing data.
- The step-by-step methodology for distinguishing active MCP services from unstable or partial deployments.
- The article's guidance on how exposed MCP servers were mapped and analysed at scale.
👉 Read Knostic's research on exposed MCP servers and unauthenticated tool access →
MCP server exposure: what it means for IAM and access controls?
Explore further
09/07/2026 12:44 pm
Unauthenticated tool discovery is the real MCP governance failure. The article shows that servers are answering capability queries before identity is established, which means the control plane is leaking information by design or by default. That is not a minor hardening issue. It means MCP deployments are being treated as integration plumbing when they actually behave like privileged identity endpoints. Practitioners should govern tool enumeration as a protected action, not a harmless probe.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should own MCP server access governance in an enterprise?
A: Ownership should sit jointly with IAM, platform, and application teams, because MCP exposure is both an identity problem and a service design problem. The practical goal is to assign clear accountability for discovery controls, tool scoping, and lifecycle review before the service becomes broadly embedded in AI workflows.
👉 Read our full editorial: Internet-exposed MCP servers are broadcasting tools without auth
