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.
At a glance
What this is: Knostic mapped 1,862 internet-exposed MCP servers and verified unauthenticated access to tool listings across all 119 sampled servers.
Why it matters: IAM and platform teams need to treat MCP exposure as an access-control problem, because unauthenticated tool discovery can become a live path to sensitive data, credentials, and cloud actions.
Context
MCP is a protocol that lets AI applications discover tools and data sources, but the protocol does not become safe just because it is being used for enterprise automation. When server endpoints are exposed to the internet and the tool listing is reachable without authentication, the exposure is already an identity and access problem, not a simple network placement issue.
Knostic's findings show why traditional perimeter assumptions break down here. A server that advertises tools without access control turns protocol discovery into operational reach, which means governance has to start at identity, authorization, and tool inventory rather than at the application layer alone.
Key questions
Q: What breaks when MCP servers do not require authentication?
A: When MCP servers do not require authentication, the access boundary disappears. Attackers and scanners can enumerate tools directly, invoke exposed functions, and abuse those surfaces as if they were intended users. That turns an integration protocol into a public attack surface and makes later authorisation checks largely irrelevant.
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. If the server is compromised, those credentials can be reused outside the intended boundary. Runtime injection reduces that exposure by keeping secrets out of user space.
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. If a server accepts session-only state, relayed tokens, or vague consent prompts, authorization is functioning as a convenience layer rather than a control.
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.
Technical breakdown
How exposed MCP servers reveal tools before any trust decision
The first technical issue is discovery. MCP servers advertise themselves through protocol markers, endpoint paths, and JSON-RPC handshake behaviour, which makes them relatively easy to fingerprint when they are internet-facing. That is useful for defenders and attackers alike. Once a server answers a tools/list request without authentication, the protocol has already crossed a governance line: it is exposing capabilities before the caller has been identified, authorized, or constrained. In identity terms, tool discovery becomes a control plane event, not a passive banner.
Practical implication: inventory exposed MCP endpoints and require authenticated discovery before any tool catalogue is returned.
Why unauthenticated tool listings change the risk model
A tool listing is not harmless metadata. In MCP, the list often reveals what the server can touch, such as files, APIs, cloud functions, or internal workflows. If that list is accessible without authentication, an attacker can map the service's useful attack surface without needing to execute a single tool. That shifts the problem from hiding endpoints to controlling who can learn what the server can do. The article's sample showed this pattern consistently across verified servers, which is enough to treat unauthenticated tool enumeration as a material access flaw.
Practical implication: protect tool catalogs with explicit authorization and review them as sensitive exposure points.
How MCP authorization gaps create downstream identity risk
When MCP servers sit between a caller and downstream systems, they effectively inherit the rights of the underlying integrations. If the server can reach files, cloud accounts, or stored credentials, then weak authorization at the MCP layer becomes a gateway into those identities and resources. The danger is especially acute when the server relies on broad service credentials or loosely scoped tokens, because the protocol can become an over-permissioned broker rather than a governed interface. In other words, the exposure is not only the server itself but the chain of trust behind it.
Practical implication: scope the downstream credentials behind each MCP server and remove any standing access broader than the server's declared function.
Threat narrative
Attacker objective: The attacker wants to enumerate MCP tools and then use that visibility to reach sensitive files, secrets, or connected cloud resources.
- Entry begins with internet exposure of MCP servers that can be identified through protocol fingerprints, common paths, and handshake responses.
- Credential or authorization bypass occurs when the server returns internal tool listings without requiring authentication, giving an outsider a map of available functions.
- Impact follows when those functions expose files, secrets, or cloud actions that can be abused for data theft, credential theft, or expensive resource use.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Model Context Protocol creates a new identity boundary for machine access: MCP servers do not merely connect systems, they broker what a caller can discover and invoke. When that broker layer lacks authorization, the server becomes a de facto control plane for downstream NHIs, tokens, and APIs. Teams should stop thinking about MCP as a transport detail and treat it as governed identity infrastructure.
Secret-bearing integrations make MCP exposure materially worse: The article's examples around file access, OAuth tokens, API keys, and cloud spend show how one exposed server can become a pivot into several other identities. That means the real unit of risk is the trust chain behind the server, not the server alone. Practitioners need a clean inventory of which downstream credentials each MCP endpoint can reach.
OWASP-NHI NHI-04, NHI-05, and NHI-07 are all visible here: The pattern combines insecure authentication, overprivileged NHI behaviour, and the persistence of credentials that outlive their intended exposure window. Those failures are especially dangerous when the server itself is easy to discover. Security teams should evaluate MCP through the lens of machine identity lifecycle, not just API hardening.
Identity controls have to move closer to the tool boundary: If a server can reveal and expose tools without a trust decision, then the old assumption that network location equals safety is gone. That assumption no longer holds for internet-facing MCP deployments. The practical conclusion is that authorization, least privilege, and offboarding of downstream credentials must be designed into the protocol layer, not bolted on after deployment.
From our research library:
- 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.
- Read next: MCP Security Guide
What this signals
Tool discovery has become an access-control event: Once a protocol server reveals its tool catalogue without authentication, the attack surface is no longer theoretical. Teams need to review MCP as a governed identity boundary, because the point of failure is the moment capability metadata becomes visible to the wrong caller.
MCP exposure should be folded into NHI lifecycle governance: The real risk is not just the endpoint, but the service accounts, tokens, and cloud permissions that sit behind it. When those credentials are long-lived or over-scoped, the server becomes a reusable bridge into other systems rather than a bounded interface.
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: that figure shows how quickly protocol adoption can outpace secrets governance. The practical signal for practitioners is to control where MCP configuration lives, who can read it, and how quickly exposed credentials are rotated.
For practitioners
- 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.
- Separate discovery from execution Make tool catalog access and tool invocation distinct authorization events so that seeing a tool does not imply permission to use it.
- Treat MCP exposure as an offboarding problem Revoke or rotate the credentials and integrations behind any MCP server that is retired, repurposed, or no longer intended to expose tools.
Key takeaways
- Exposed MCP servers can turn protocol discovery into an access problem when tool listings are available before authentication.
- The article's sample of 119 servers showed that unauthenticated tool visibility is not an edge case, so governance has to start at the protocol boundary.
- The control that matters most is authenticated discovery combined with tight scoping of the credentials behind each MCP server.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Unauthenticated tool listings are the core exposure in this MCP article. |
| NHI-05 — Overprivileged NHI | Exposed servers often sit in front of broader downstream permissions than they need. | |
| NHI-07 — Long-Lived Secrets | MCP deployments inherit risk when tokens and API keys stay valid too long. | |
| Recommendation — Require authenticated discovery before any MCP tool catalogue is returned. Scope each MCP server to the minimum downstream access its function requires. Rotate MCP backing credentials aggressively and remove any long-lived secrets. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is central to the exposed-server risk described here. |
| Recommendation — Apply authenticator lifecycle controls to the credentials behind every MCP server. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about missing authorization at the tool boundary. |
| Recommendation — Enforce entitlement checks before exposing MCP tools or resources. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes how exposed tools can lead to credential theft and data loss. |
| Recommendation — Map exposed MCP endpoints to credential-access and exfiltration detection use cases. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | MCP exposure is an IAM problem when servers broker access to cloud resources. |
| Recommendation — Apply cloud IAM governance to the identities behind each MCP deployment. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- Tool Listing: The catalogue of actions, resources, or functions an MCP server exposes to a caller. If this catalogue is visible without authentication, it becomes sensitive capability metadata because it tells an attacker what the system can reach or control.
- Protocol Boundary Validation: Protocol boundary validation is the process of checking identity assertions when traffic crosses a trust boundary between systems, networks, or providers. It is the control that prevents a forged caller, packet, or message from being accepted simply because it arrived through a familiar channel.
- Downstream Credentials: Downstream credentials are the secrets, tokens, keys, and delegated permissions that an identity uses to operate beyond its own directory record. They matter because they often define the real blast radius of an AI agent or service account, especially when the visible identity layer looks well managed.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org