Internet-exposed MCP servers are broadcasting tools without auth

At a glance

What this is: Knostic's research shows that internet-exposed MCP servers are revealing internal tool capabilities without authentication, creating a direct access-control gap around model context protocol deployments.

Why it matters: IAM, NHI, and AI platform teams need to treat MCP servers as identity-bearing services because unauthenticated tool discovery turns runtime integrations into an exposed control plane.

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.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Knostic's research on exposed MCP servers and unauthenticated tool access

Context

Model Context Protocol, or MCP, is becoming the connective tissue between AI systems and the tools they can use. The problem exposed here is straightforward: if the server advertises tools before it verifies identity, the access boundary is already broken. That makes MCP not just an integration pattern, but a governance problem for model context protocol deployments.

This is an NHI issue as much as an AI issue because the exposed endpoint behaves like a machine identity with tool authority. When those servers sit on the internet and return capabilities to unauthenticated requests, the organisation has effectively published an internal control surface to anyone who can speak the protocol.

The article's findings suggest an early-stage market where security is still being bolted on after exposure has already happened. That is a typical adoption pattern for new identity-adjacent infrastructure, but it is a poor starting point for any programme that expects identity-bound authorisation to be present by default.

Key questions

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. The first control is to prevent capability enumeration without verified identity, then bring the server into normal inventory, ownership, and review processes. That makes exposure measurable and remediable instead of invisible.

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. IAM and NHI programmes must therefore govern the server itself, not just the credentials behind it. Otherwise, the protocol becomes a discovery surface for privileged operations.

Q: What breaks when tool listings are visible without authentication?

A: What breaks is the assumption that capability disclosure is harmless until execution begins. If an unauthenticated requester can enumerate tools, an attacker can map the service, prioritise targets, and infer where valuable data or actions sit. That reduces the effort needed for abuse and weakens any downstream control plan.

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.

Technical breakdown

How MCP server discovery works on exposed endpoints

MCP servers can be fingerprinted by protocol markers, transport signals, endpoint paths, and technology headers. In practice, that means strings such as JSON-RPC initialisation fields, Server-Sent Events content types, and common paths like /mcp or /messages can reveal a server's presence to passive scanners. Once a server answers a protocol-compliant handshake, it has already disclosed enough structure to be enumerated. Practical implication: treat protocol banners and endpoint discovery as part of attack surface management, not just developer convenience.

Practical implication: inventory and suppress protocol fingerprints that make MCP services trivially discoverable.

Why unauthenticated tools/list responses are an identity failure

The tools/list request is an MCP read-only query that asks a server what actions it can perform. If the response is available without authentication, the server is exposing its tool catalog before it has established who is asking. That is an identity control failure, not merely a documentation issue, because the tool inventory itself often reveals sensitive operational reach. Practical implication: gate tool enumeration behind strong identity checks and scoped authorisation.

Practical implication: require authentication before any capability enumeration is allowed.

What early MCP maturity means for access governance

The article points to instability, insecure defaults, and a technology curve where security is not yet consistently built into deployments. That combination usually produces broad visibility gaps, inconsistent hardening, and weak lifecycle ownership across the services that wrap new protocols. For IAM and NHI teams, the key lesson is that emerging platforms often outpace governance models that assume mature control primitives. Practical implication: classify MCP servers as governed identities and bring them into lifecycle, review, and access-scoping processes early.

Practical implication: place MCP services inside the same governance cadence you use for other non-human identities.

Threat narrative

Attacker objective: The objective is to map internal tool access and identify exposed MCP services that can be abused as a path into connected data and actions.

1. Entry occurs through internet exposure and protocol-compliant handshake responses that let scanners identify an MCP service without authentication.
2. Escalation is achieved when a successful tools/list request reveals internal tool inventory and functional capability to an unauthorised requester.
3. Impact follows when exposed capability data becomes a roadmap for tool abuse, lateral access, or further targeting of connected systems.

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

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.

Model Context Protocol creates a new kind of NHI surface: a discoverable tool authority. Once an MCP server can be fingerprinted, enumerated, and queried without auth, it becomes a non-human identity with broadcast privileges. That matters because access controls built around trusted application boundaries do not hold when the protocol itself advertises what the service can do. The implication is that MCP servers must be managed as identity-bearing assets with explicit authorization boundaries, not as passive middleware.

Early MCP adoption is producing governance debt faster than security maturity. The article's finding that many exposed servers are unstable and insecure suggests the market is still normalising insecure defaults. That usually leads to a long tail of exposed services, inconsistent ownership, and weak review discipline. The practitioner conclusion is simple: do not wait for protocol maturity before putting MCP into identity inventory, access review, and service-account governance.

Access scoping is the named concept this category now needs. If a server can reveal tools without scoping who may see them, then the organisation has no useful least-privilege boundary at the protocol layer. This is the same failure pattern seen in other machine identity sprawl problems, where visibility arrives before control. Practitioners should treat access scoping for MCP as a baseline governance requirement, not an advanced feature.

Identity policy must now extend beyond secrets to protocol exposure. Traditional NHI programmes focus on credential rotation, token hygiene, and offboarding, but exposed MCP servers show that discovery itself can be the breach precursor. When a service reveals its tool list to anyone, the risk is not just credential theft, it is over-disclosure of capability. Teams should broaden NHI governance to include protocol-level authorisation and service discovery controls.

From our research:

• 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.
• For a broader control lens, NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding disciplines can be extended to service-facing AI infrastructure.

What this signals

Access scoping for MCP will become a practical baseline, not a nice-to-have. When servers expose tools before authentication, teams lose the ability to distinguish harmless discovery from privilege-bearing access. The governance response is to fold MCP into the same identity inventory and review cycle used for service accounts and other non-human identities, using the Ultimate Guide to NHIs , Key Challenges and Risks as the starting point for control design.

Exposure is the new early warning signal. If a protocol can be fingerprinted, enumerated, and queried without auth, then discovery itself should be treated as a measurable risk indicator. The programme question is no longer whether an MCP server exists, but whether it can be identified and scoped before it broadcasts its capabilities.

Service-account governance now has to absorb AI adjacency. As AI platforms increasingly depend on machine-facing endpoints, the boundary between workload identity and agentic tool use will keep narrowing. Teams that already struggle with service-account visibility will find that exposed MCP servers amplify the same control debt, only with a new protocol wrapper.

For practitioners

• Inventory MCP endpoints as governed identities Add MCP servers to the same inventory used for service accounts, API keys, and workload identities. Track owner, environment, exposed transport, and whether any unauthenticated requests return capability data.
• Block unauthenticated capability enumeration Require authentication before tools/list or equivalent discovery calls can return any internal tool metadata. If a server must be publicly reachable, ensure it returns no actionable capability details until identity is verified.
• Reduce protocol fingerprintability Remove obvious endpoint paths, standard banners, and unnecessary protocol markers from public exposure where possible. Use network placement and policy controls so discovery tooling cannot trivially map the service surface.
• Add access scoping to MCP governance Define which identities may see which tools, and review those scopes the same way you review other privileged non-human access. Where scoping is missing, treat the deployment as overexposed until the control exists.

Key takeaways

• Internet-exposed MCP servers are already disclosing internal tools without authentication, which turns discovery into a governance failure.
• The scale is material, with 1,862 exposed servers identified and 119 manually verified as returning internal tool listings without auth.
• The control gap is identity-bound access scoping, because protocol-level visibility must be restricted before capability enumeration begins.

Key terms

• Model Context Protocol: Model Context Protocol is an open interface that lets AI systems connect to tools and data sources through a standard request pattern. In security terms, it defines a control surface that must be authenticated, authorised, and monitored like any other privileged service integration.
• Tool Enumeration: Tool enumeration is the act of listing the actions, functions, or capabilities a service exposes before those actions are invoked. For MCP and other machine-facing services, enumeration can itself create risk because it reveals attack paths, privilege scope, and connected systems.
• Access Scoping: Access scoping is the practice of limiting what an identity can see or do to only the permissions required for a task. For MCP services, scoping must apply not just to execution, but to capability discovery and tool listing as well.
• Capability Disclosure: Capability disclosure happens when a service reveals what it can do, often through banners, metadata, or unauthenticated discovery calls. In identity security, disclosure matters because it gives attackers a map of the control plane before any command is executed.

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.

👉 Knostic's full post covers the fingerprinting method, verification steps, and exposure findings in more 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 capabilities, it is worth exploring.