Exposed MCP servers reveal a growing identity and access risk

At a glance

What this is: This is a technical deep dive into exposed MCP servers, showing that unauthenticated tool discovery is still common and that insecure deployments can expose internal tools to anyone on the internet.

Why it matters: It matters because MCP sits directly in the path between AI systems, tools, and data, so identity, access scoping, and secrets governance now need to cover another non-human control plane.

By the numbers:

• Knostic discovered a total of 1,862 MCP servers exposed to the internet.
• From 119 servers sampled for manual verification, all 119 allowed access to internal tool listings without authentication.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Knostic's analysis of exposed MCP servers and unauthenticated tool access

Context

MCP server exposure creates an identity and access problem before it becomes a technical one. If an MCP listener is reachable on the internet and its tools can be enumerated without authentication, the server is effectively publishing an execution surface without a governance boundary. That is a weak starting point for any programme trying to treat AI tool access as controlled enterprise access.

The article shows how quickly simple discovery can turn into confirmable exposure when protocol fingerprints, endpoint paths, and JSON-RPC handshakes are left visible. For IAM, PAM, and NHI teams, the issue is not only whether a server exists, but whether its tool inventory, credentials, and downstream actions are constrained by the same discipline applied to other privileged identities.

Key questions

Q: How should security teams secure exposed MCP servers without breaking AI workflows?

A: Start by authenticating every MCP endpoint before any tool catalog is revealed, then limit each server to the smallest tool set and secret scope it needs. Separate discovery, invocation, and secret access in logs so you can see abuse early. If a service is internet-facing, treat it like a privileged non-human identity, not a convenience endpoint.

Q: Why do unauthenticated MCP tool listings create identity risk?

A: Because a tool listing is a capability map. If anyone can enumerate the tools, they can identify where sensitive data, credentials, or expensive actions may live, even before any command is issued. That breaks least privilege at the visibility layer and gives attackers the information needed to target the most valuable paths first.

Q: What breaks when MCP servers are exposed without access scoping?

A: The server becomes a publicly reachable control point with no meaningful boundary between discovery and use. Attackers can find the service, confirm its protocol, inspect its tools, and then target any embedded secrets or downstream integrations. That turns a workflow component into an identity bridge with excessive blast radius.

Q: What should IAM teams prioritise when MCP is part of the stack?

A: Prioritise ownership, authentication, secret hygiene, and lifecycle control for every MCP server exactly as you would for a privileged workload. The service should have a named owner, scoped credentials, rotation rules, and a decommissioning path. Without those controls, the protocol becomes another unmanaged non-human identity surface.

Technical breakdown

How MCP servers are fingerprinted on the public internet

MCP discovery starts with protocol artefacts that are easy to search at scale. Signals such as the literal string Model Context Protocol, JSON-RPC fields like "jsonrpc": "2.0", SSE content type headers, and common paths such as /mcp or /api/mcp make servers visible to scanners long before any authentication challenge appears. Once those markers are indexed, a server can be identified through its banner, transport, and endpoint behaviour even if the operator assumed it was obscure. This is classic exposure by implementation detail, not by sophisticated exploitation.

Practical implication: inventory externally reachable MCP endpoints and remove protocol fingerprints that make unauthenticated discovery trivial.

Why unauthenticated tool listings are an access control failure

In MCP, tools/list is the read-only equivalent of asking what a server can do. If that request works without authentication, the server is advertising operational capability to anyone who finds it. That is not yet command execution, but it is a meaningful breach of least-privilege assumptions because the tool catalog often reveals which APIs, data sources, and workflows are available. For identity teams, the control failure is that the front door and the capability boundary are not the same thing, so exposure can occur even when deeper actions are not yet invoked.

Practical implication: require authentication before tool enumeration and scope tool visibility separately from tool execution.

How exposed MCP servers turn into data and credential risk

Once an attacker can enumerate tools, the next step is usually not guesswork. The article describes realistic outcomes such as file reads, cloud cost abuse, OAuth token theft, API key extraction, and database credential exposure. Those are all non-human identity failures because the server often sits behind machine credentials that were granted for normal operations but were never constrained for hostile use. The practical danger is that an exposed MCP server becomes a privileged bridge into the rest of the AI and application stack, especially when secrets are stored locally or passed through the tool layer.

Practical implication: treat MCP servers as privileged NHI workloads and bind their secrets, network reach, and tool scopes to explicit trust boundaries.

Threat narrative

Attacker objective: The attacker wants to turn an exposed MCP listener into an entry point for credential theft, tool abuse, data access, or cloud cost manipulation.

1. Entry occurs through public internet discovery of an MCP server using protocol fingerprints, common paths, and indexed banners that reveal the service to scanners.
2. Escalation begins when unauthenticated tools/list access exposes the server’s tool catalog, making downstream capabilities and potential secret-bearing workflows visible.
3. Impact follows when exposed tools are used to read files, extract credentials, abuse cloud APIs, or trigger expensive operations that drain resources and extend access.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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 create a new identity boundary, not just a new attack surface: The problem is not that MCP exists, but that its tool layer is often reachable before any meaningful access decision is made. Once tool discovery is public, the server has already crossed from software endpoint into privileged identity surface. Practitioners should treat internet-facing MCP exposure as an identity governance issue, not a purely network one.

Tool enumeration is the governance gap that turns discovery into risk: Internal tool listings are operational intelligence, even when the underlying actions have not yet been called. If an unauthenticated user can see available tools, the environment has already disclosed what can be reached, what data may exist, and where secret-bearing workflows might live. The implication is that visibility and authorization must be coupled, not sequentially assumed.

Least privilege for MCP cannot be defined at deployment time if the tool set is externally discoverable: The article shows that protocol-compliant handshakes and common endpoint paths make the service easy to identify and validate. That means the trust model is not based on obscurity but on explicit control of enumeration, authentication, and tool scoping. The practical conclusion is that MCP governance has to start before the first tool is listed.

Standing secret exposure is the real blast-radius multiplier in exposed MCP deployments: The article’s risk examples are all downstream of credentials and tokens already being available to the service. That is a classic NHI failure mode, where a non-human identity can be discovered, queried, and then used as a bridge to other systems. Practitioners should assume that any exposed MCP server with embedded or reachable secrets can extend compromise far beyond the server itself.

Model Context Protocol governance is now an NHI control problem: This is the kind of surface where OWASP-NHI, Zero Trust, and identity lifecycle controls converge. A server that can expose tools without authentication is functionally an unmanaged non-human identity, even if it was built for legitimate AI workflows. Security teams should align MCP governance with the same lifecycle discipline used for service accounts, API keys, and privileged workloads.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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, according to AI Agents: The New Attack Surface report.
• For a broader framework on non-human identity exposure, see 52 NHI Breaches Analysis and compare how exposed control surfaces become breach pathways.

What this signals

Exposed MCP will behave like a workload identity problem before it behaves like a platform problem: as AI systems accumulate more tool access, the governance burden moves from model behaviour to identity boundaries, secret scope, and service ownership. Teams that already use the OWASP Non-Human Identity Top 10 should treat MCP listeners as privileged NHI workloads with the same lifecycle scrutiny as service accounts.

With 80% of organisations already seeing AI agents act beyond intended scope, per AI Agents: The New Attack Surface report, MCP exposure should be read as an acceleration factor rather than an isolated misconfiguration. Once tool discovery is public, the next governance failure is usually not the endpoint itself but the secrets, permissions, and downstream systems it can reach. That means identity teams need visibility into how AI-facing services are provisioned, owned, and retired.

The control conversation now needs to include how quickly exposed AI tool surfaces can be detected and scoped back into a Zero Trust model. The NIST SP 800-53 Rev 5 Security and Privacy Controls catalogue remains relevant here because access control, identification, and audit families all apply to MCP as a privileged service layer.

For practitioners

• Inventory every externally reachable MCP endpoint Map internet-facing listeners, common paths, and protocol fingerprints so you know which MCP services are discoverable before they become exploitable. Include reverse proxies, developer sandboxes, and AI integration hosts in the same inventory.
• Require authentication before tool enumeration Block anonymous tools/list responses and make tool visibility part of the authorisation decision, not a public discovery function. If a server can be identified externally, it should not reveal its capability set without a verified identity.
• Scope MCP permissions as privileged NHI access Bind each server to the minimum tools, data sources, and downstream actions required for its role. Review embedded credentials, OAuth tokens, and API keys as privileged secrets rather than generic configuration.
• Separate discovery from execution controls Instrument logging so that tool catalog access, tool invocation, and secret access are distinct events with distinct alerts. That separation is what lets security teams spot abuse before the server is used as a bridge into other systems.

Key takeaways

• Exposed MCP servers are an identity governance problem because unauthenticated tool discovery creates a privileged surface before any action is taken.
• Knostic verified 1,862 internet-facing MCP servers and found that all 119 sampled servers exposed internal tool listings without authentication.
• The fix is not just network filtering. Teams need authenticated discovery, scoped tool visibility, secret hygiene, and lifecycle ownership for every MCP service.

Key terms

• MCP server: An MCP server is the runtime endpoint that exposes tools, resources, or prompts to AI clients through the Model Context Protocol. In identity terms, it is a non-human access surface that can become privileged if it can reach internal systems or secrets without strong authentication and scoping.
• Tool enumeration: Tool enumeration is the ability to list or discover what actions a service can perform before any action is executed. For MCP, that matters because the tool catalog can reveal sensitive capabilities, data paths, and secret-bearing workflows even when the underlying tools are not yet invoked.
• Model Context Protocol: Model Context Protocol is an open protocol for connecting AI systems to tools and data sources. In practice, it creates a control boundary that must be governed like any other non-human identity surface, because exposure, scoping, and secrets handling determine whether the integration stays safe.
• Non-human identity surface: A non-human identity surface is any machine or software endpoint that can authenticate, access tools, or reach data on behalf of a system. MCP servers fit this pattern when they operate with privileged credentials, because access management, ownership, and lifecycle controls become security requirements.

What's in the full report

Knostic's full research covers the operational detail this post intentionally leaves for the source:

• Shodan filter logic and the custom fingerprinting approach used to identify MCP servers in the wild.
• The full validation workflow for confirming a true MCP server, including protocol-compliant handshake checks and endpoint probing.
• Safe, read-only verification techniques such as tools/list that distinguish exposure from active tool execution.
• Knostic's recommendations for securing MCP environments beyond discovery, including the operational controls it discusses on its blog.

👉 Knostic's full post covers the discovery workflow, validation methods, and MCP security recommendations 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 building or maturing identity security across human and non-human systems, it is worth exploring.