Notifications
Clear all
Topic starter
09/07/2026 12:37 pm
TL;DR: 1,862 MCP servers were found exposed to the internet and 119 targets were verified, all of which allowed unauthenticated access to internal tool listings, according to Knostic research. The deeper problem is not discovery alone, but the assumption that tool access stays bounded once MCP endpoints are published.
NHIMG editorial — based on content published by Knostic: exposed MCP servers and AI-assisted discovery research
By the numbers:
- Knostic discovered 1,862 MCP servers exposed to the internet.
- From a sample of 119 servers, all 119 allowed access to internal tool listings without authentication.
Questions worth separating out
Q: How should teams secure MCP servers that expose internal tools?
A: Teams should require authentication before any tool listing is exposed, then scope each MCP server to the minimum set of tools needed for the approved use case.
Q: Why do exposed MCP servers matter to IAM and NHI programmes?
A: Exposed MCP servers matter because they sit on the access path for AI-driven execution.
Q: What breaks when MCP tool listings are available without authentication?
A: What breaks is the assumption that tool metadata is harmless.
Practitioner guidance
- Classify MCP servers as governed access surfaces Map every MCP endpoint to an owning team, an access model, and a business justification.
- Remove anonymous tool catalogue access Require authentication before any internal tool listing is returned, and restrict catalog visibility to approved service identities or administrators.
- Run continuous external exposure checks Add routine internet-facing discovery against MCP namespaces, subdomains, and known ports so new exposures are found before they are indexed or scanned by outsiders.
What's in the full article
Knostic's full article covers the operational detail this post intentionally leaves for the source:
- The exact Shodan query strategy used to enumerate internet-exposed MCP servers
- The manual verification approach used to confirm unauthenticated access to internal tool listings
- The development workflow for the discovery and validation scripts used in the research
- The technical methodology behind the mcp_scanner.py and mcp_func_checker.py tooling
👉 Read Knostic's research on exposed MCP servers and AI-assisted discovery →
MCP server exposure: what it means for AI and IAM teams?
Explore further
09/07/2026 12:43 pm
Exposed MCP servers are an unmanaged identity boundary, not a peripheral developer detail. When an AI-facing protocol exposes internal tools without authentication, it is functioning as a privileged access surface. That changes the governance problem from service hardening to identity control for machine-mediated execution. The practitioner conclusion is straightforward: MCP endpoints must be governed like any other access layer that can reveal or invoke sensitive capabilities.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should be accountable for exposed MCP endpoints in production?
A: Accountability should sit with the team that owns the protocol exposure, not only the infrastructure host. That usually means platform, application, and identity stakeholders all share responsibility for access scope, authentication, and external discoverability. If no owner can answer who can see the tools, governance has already failed.
👉 Read our full editorial: MCP server exposure shows how AI-assisted discovery scales risk
