Topic starter
09/07/2026 12:38 pm
TL;DR: 1,862 MCP servers were exposed to the internet, and all 119 sampled servers allowed unauthenticated access to internal tool listings, while the protocol’s weak authorization defaults can expose files, credentials, and cloud spend, according to Knostic. The risk is not just discovery, but unmanaged tool access that turns MCP into an identity boundary without identity controls.
Editorial analysis by NHI Mgmt Group, based on content published by Knostic: “How to Find an MCP Server with Shodan”.
Key questions
Q: What breaks when MCP servers do not require authentication?
A: When MCP servers do not require authentication, the access boundary disappears.
Q: Why do local MCP servers create secret exposure risk?
A: Local MCP servers often receive API keys or tokens through environment variables, which makes secrets visible to the process and potentially to logs, memory, and inspection tools.
Q: How do security teams know whether MCP authorization is actually working?
A: Look for evidence that consent is stored per client, tokens are validated at each hop, and invalid audience or redirect values are rejected consistently.
Practitioner guidance
- Lock down tool discovery Require authentication before an MCP server returns any tools, resources, or capability metadata, and treat unauthenticated tool listings as a reportable control failure.
- Inventory every exposed MCP endpoint Map all public MCP listeners, note their transport and endpoint paths, and remove anything that is not intentionally internet-facing.
- Reduce downstream credential scope Review the service accounts, API keys, and OAuth tokens behind each MCP server and remove permissions that are not needed for the server's declared function.
Bottom line: Exposed MCP servers can turn protocol discovery into an access problem when tool listings are available before authentication.
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 just an exposure issue: The article shows that an exposed server can advertise its tools before the caller is authenticated or authorized. That collapses the boundary between discovery and access, which is exactly where NHI governance needs to begin. The practitioner takeaway is that tool inventory must be treated as protected capability data, not public metadata.
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: Should organisations treat MCP servers as part of the identity control plane?
A: Yes. An MCP server that brokers access to secrets, models, or downstream services is effectively making authorisation decisions on behalf of machine workloads. That makes its retrieval policy, identity trust chain, and audit trail part of identity governance. If those controls are weak, the server becomes a privileged access path rather than a neutral integration layer.
👉 Read our full editorial: Exposed MCP servers reveal a growing identity and access risk