MCP server exposure shows how AI-assisted discovery scales risk

At a glance

What this is: Knostic’s research shows that internet-exposed MCP servers can leak internal tool listings without authentication, creating a broader discovery and abuse surface for AI-connected infrastructure.

Why it matters: IAM, NHI, and platform teams need to treat exposed MCP endpoints as identity-bearing systems because unauthenticated tool visibility can widen attack paths before any direct compromise occurs.

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.

👉 Read Knostic's research on exposed MCP servers and AI-assisted discovery

Context

MCP servers are becoming a new identity and access boundary for AI-connected tooling, because they expose tools, data sources, and execution paths that agents can reach at runtime. When those endpoints are published to the internet and left unauthenticated, the problem is not just service exposure. It is unmanaged access to the control surface that AI systems rely on.

This research is relevant to NHI governance because MCP servers behave like infrastructure identities with tool permissions, even when they are not managed that way. Once discovery is easy, adversaries do not need exotic techniques to map the environment. They only need enough visibility to identify where tools exist and how access is structured.

For IAM and platform teams, the key question is whether MCP is being treated as a governed access layer or as a developer convenience. The article’s findings suggest the latter is still common, which is typical for emerging AI infrastructure but not acceptable for environments exposing sensitive data or privileged workflows.

Key questions

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. They should also treat internet exposure as a governance issue, not just a hosting issue, because tool visibility itself can enable reconnaissance and follow-on abuse.

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. If the server reveals tools or accepts requests without proper identity checks, it becomes part of the NHI control surface. That means IAM teams must govern exposure, scoping, and accountability together rather than treating MCP as a standalone developer concern.

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: 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.

Technical breakdown

Why exposed MCP servers create an identity surface, not just a network surface

MCP servers sit between AI clients and enterprise tools, so they act as a runtime access broker for model-driven workflows. Even when the server itself is not a human login system, it still governs what tools are visible, selectable, and callable. If the server is reachable without authentication, the internal tool catalogue can become reconnaissance data for attackers. That makes MCP exposure an identity problem, because tool visibility often precedes tool abuse.

Practical implication: inventory MCP endpoints and classify them as identity-bearing services subject to access control review.

How unauthenticated tool listings expand attack planning

Internal tool listings reveal the structure of an AI-connected environment, including what actions are possible and which systems those actions may touch. That information helps an attacker plan more efficiently, because it reduces guesswork around tool names, capabilities, and likely downstream data access. In AI environments, that matters because the line between discovery and misuse is thin. If a tool is visible, it is often one prompt or one delegated action away from being exercised.

Practical implication: remove anonymous access to tool catalogs and restrict exposure to approved operators and service identities.

What asynchronous scanning changes for defenders

The article shows how AI-assisted scripting and concurrent API querying can accelerate large-scale reconnaissance. That does not make the attack autonomous in the strict sense, but it does compress the time required to find exposed services. Defenders should therefore assume that low-friction discovery is now the default. Slow, manual review cycles no longer match the speed at which exposed infrastructure can be enumerated and profiled.

Practical implication: reduce internet exposure and add continuous external discovery monitoring instead of relying on periodic manual checks.

Threat narrative

Attacker objective: The objective is to map and prioritise AI-connected tools and endpoints so that later abuse can be directed at the most valuable internal workflows.

1. Entry begins with internet exposure of MCP servers that can be discovered through broad external scanning and search queries.
2. Escalation occurs when an unauthenticated server reveals internal tool listings, giving attackers enough structure to plan tool abuse and target selection.
3. Impact follows when exposed tool visibility increases the chance of downstream misuse, including access to sensitive systems or data through AI-connected workflows.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Discovery is the first control failure in AI infrastructure exposure. Knostic’s sample shows that once an attacker can enumerate a tool surface, the environment has already lost part of its security posture. Tool catalogs provide enough metadata to support targeting, planning, and follow-on abuse. The practitioner conclusion is that external discoverability must be treated as a material exposure condition, not a cosmetic misconfiguration.

AI-assisted scanning compresses the reconnaissance window around emerging protocols. The research demonstrates that less programming-savvy operators can use language models to automate repetitive discovery work at scale. That does not require autonomous behaviour in the identity sense, but it does lower the barrier to finding exposed MCP endpoints. The practitioner conclusion is that new protocols need continuous exposure management from day one.

Policy controls have to start before the protocol becomes widely adopted. The article shows a common failure mode in new AI infrastructure: deployment arrives before governance. That gap is where internal tool listings, unscoped access, and weak authentication become default conditions. The practitioner conclusion is that protocol adoption plans need identity review, access scoping, and external visibility checks before production rollout.

From our research:

• 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.
• Use the OWASP Agentic Applications Top 10 to frame the control gaps that emerge when AI-connected tools outpace governance.

What this signals

The immediate programme risk is not just MCP exposure itself, but the speed at which AI-assisted discovery can turn one exposed server into many. With 96% of technology professionals identifying AI agents as a growing security threat and 66% calling the risk immediate, according to our AI agents research, identity teams should expect exposure management to move from periodic review to continuous control.

Tool-surface governance gap: exposed MCP environments reveal a broader pattern where AI-connected systems are published before their access model is mature. That gap will matter more as agentic workflows spread across search, development, and data access, because the attack surface grows through discoverability as much as through execution.

Teams should align protocol exposure review with OWASP Non-Human Identity Top 10 and the NIST SP 800-53 Rev 5 Security and Privacy Controls where identity, authentication, and auditability overlap.

For practitioners

• Classify MCP servers as governed access surfaces Map every MCP endpoint to an owning team, an access model, and a business justification. Treat public exposure, authentication state, and tool visibility as part of the same control set, not separate operational tasks.
• Remove anonymous tool catalogue access Require authentication before any internal tool listing is returned, and restrict catalog visibility to approved service identities or administrators. If a server can enumerate tools without identity checks, it is already overexposed.
• 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. Pair that with alerting on unexpected changes in tool surface visibility.
• Limit tool scope before deployment Apply allowlists for tools that AI clients can see and invoke, and review those scopes during change management. A broad tool catalog creates unnecessary reconnaissance value even when no exploit has occurred.

Key takeaways

• Exposed MCP servers turn AI tool catalogs into an identity and reconnaissance problem, not just a hosting issue.
• The research found 1,862 internet-exposed MCP servers and verified that all 119 sampled systems disclosed internal tool listings without authentication.
• The control priority is clear: authenticate tool visibility, scope exposed capabilities, and monitor external discoverability continuously.

Key terms

• Mcp Server: An MCP server is the service layer that exposes tools and data sources to AI clients through the Model Context Protocol. In identity terms, it becomes a control point for what an AI system can see and do, so exposure and authentication are governance issues, not just implementation details.
• Tool Catalogue: A tool catalogue is the list of actions, connectors, or capabilities an AI client can discover through an MCP server. When exposed without authentication, it can reveal internal structure, system names, and possible targets, giving attackers reconnaissance value before any direct compromise occurs.
• External Discoverability: External discoverability is the ease with which an internet-facing service can be found, indexed, or enumerated by outsiders. For AI infrastructure, it is a governance signal because broad discoverability shortens the path from exposure to abuse and reduces the defender’s response window.

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

👉 Knostic's full post covers the scanning method, verification workflow, and research tooling in detail

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.