TL;DR: MCP’s rapid adoption has produced thousands of internet-reachable servers with no authentication, while researchers have also documented supply-chain compromise, malicious servers, and localhost abuse, according to WorkOS and cited security reports. The governance problem is no longer theoretical: MCP turns tool access into ambient authority unless identity, scope, and audit controls are enforced.
At a glance
What this is: WorkOS examines how MCP authentication gaps, exposed servers, supply-chain compromise and localhost abuse are converting agent connectors into backdoors.
Why it matters: For IAM and NHI teams, MCP changes tool access from a narrow integration problem into a governed identity problem covering authentication, delegated scope and auditability.
By the numbers:
- Security researchers scanning the public internet found roughly 1,862 to 2,000 internet-reachable MCP servers exposed with no authentication.
Context
MCP is a protocol for connecting AI agents to tools, services and local applications. In this article, WorkOS argues that the protocol’s appeal has outpaced the identity controls needed to keep those tool connections from becoming ambient authority.
The governance gap is straightforward: when a connector can query files, databases, cloud consoles or email without strong authentication and scope limits, the control plane shifts from the agent’s intent to whoever can reach the server. That matters because MCP is now being used against real production systems, not just experimental sandboxes.
The article is therefore not about MCP as a concept, but about what happens when a tool-connection standard becomes internet-reachable infrastructure before identity, delegation and audit discipline are in place. The starting position in the ecosystem is atypical because many deployments still treat the connector as internal plumbing rather than governed access.
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 unauthenticated MCP management endpoints create such a high-risk exposure?
A: They create risk because registration often triggers execution or trust assignment immediately. If a management API accepts a request before authentication and then spawns a process, loads a plugin, or records a new client, the attacker bypasses the normal identity flow entirely. The danger comes from privileged HTTP handling, not from the protocol layer the endpoint happens to support.
Q: How do security teams know whether MCP server governance is working?
A: They should be able to answer four questions at any time: what servers exist, which are official, what credentials they can use, and what systems they contact. If those answers are unclear, governance is not working. The signal is not just fewer alerts, but clear attribution and scoped access across the fleet.
Q: What should teams do after a malicious or vulnerable MCP server is discovered in their stack?
A: Teams should assume any connected agent, token, or tool path may be affected and respond as if trust has been broken. Remove the server from active workflows, rotate related credentials, inspect prompts and logs for abuse, and review downstream systems for lateral movement or data access. Revalidate the integration before restoring it to production.
Technical breakdown
Why optional MCP authentication becomes a control-plane failure
MCP servers sit between an agent and a target system, so the server becomes part of the trust boundary, not just an integration helper. If authentication is optional or skipped, the server cannot distinguish a legitimate agent session from a drive-by request, and every tool it exposes inherits that ambiguity. The result is not merely weaker login hygiene. It is a control-plane failure where the connector itself becomes an access path to the underlying system.
Practical implication: require explicit authentication on every MCP server that can reach production data or actions.
How supply-chain compromise changes the risk model for MCP tooling
MCP tooling is often delivered through packages, proxies and connector wrappers that sit close to the permissions they broker. That means a compromised dependency can affect both the application and the tool channel the agent uses to act. The article’s CVE and phishing examples show why this matters: the connector layer is not a harmless adapter, it is leverage. If that layer is abused, attackers can inherit the same reach the agent was meant to have under policy.
Practical implication: treat MCP packages and proxies as privileged dependencies and review them like control-plane components.
Why localhost and exposed servers create ambient authority
Local MCP deployments are often presented as a convenience layer, but localhost does not equal trust. If a local server accepts unauthenticated tool calls, a malicious webpage or nearby process can trigger actions through the open loop between browser, local service and agent tooling. That is ambient authority: access granted by location or assumption rather than identity and scope. Once that happens, the browser becomes a delivery mechanism for tool abuse.
Practical implication: bind local MCP services tightly, verify callers, and do not rely on localhost as an access control boundary.
Threat narrative
Attacker objective: Use a trusted MCP connector to gain unauthorized access to the systems, data and operations it brokers.
- Entry occurs when an attacker reaches an internet-exposed or localhost MCP server that has no authentication or permissive defaults.
- Credential abuse follows when the server allows tool execution or token-forwarding without validating the caller’s identity or scope.
- Escalation happens as the attacker uses the connector’s inherited access to query files, email, databases or operational systems.
- Impact is unauthorized tool execution, data exposure or control-plane misuse through the trusted agent pathway.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MCP auth gaps create an identity problem, not just an exposure problem. The article shows that many MCP servers were reachable without authentication, which means the connector itself became the access boundary. That shifts governance from application integration to non-human identity control, because the server is now brokering action on behalf of an agent. Practitioners should treat every MCP endpoint as a privileged identity surface.
Least privilege for MCP only works when scope is enforced at issuance and at tool call time. The article’s examples make clear that agents expand from read-only use into higher-risk actions as soon as the connector is trusted. That means static assumptions about intent are fragile. The discipline is not merely issuing tokens, but binding those tokens to narrow delegated scope that matches the specific tool path.
Connector trust debt: MCP deployments accumulate risk when teams treat the connector as internal plumbing and delay identity, audit and revocation controls until after adoption. This is the same failure pattern seen in other non-human identity rollouts: convenience outruns governance, then the blast radius becomes visible only after exposure. The implication is that lifecycle and access ownership must be explicit from day one.
Tool-access governance now has to account for hostile extensions and hostile proximity. The malicious server example and localhost abuse show that the threat is no longer limited to compromised code under your control. Any connector that can impersonate a service, forward tokens or trigger actions through a local listener can collapse the assumption that only authorised integrations will call your tools. Practitioners should re-evaluate how they trust MCP endpoints, not just what they connect to.
Auditability becomes the minimum viable control once MCP reaches production. When an agent can call tools across files, cloud consoles, email and databases, the only way to separate normal automation from abuse is to preserve a clear record of what was called, by whom and on which server. Identity governance is no longer complete if it cannot answer those questions after the fact. The programme implication is simple: no audit trail, no governed 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.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Connector trust debt: MCP adoption often moves faster than the governance model built around it. Once a connector can reach cloud consoles, databases or email, the organisation is no longer managing a simple integration, it is managing delegated non-human access with real operational blast radius.
MCP deployments should now be assessed like any other privileged access path. The right question is not whether the standard is useful, but whether the server, the token and the tool scope are all bounded tightly enough to survive hostile callers, malicious extensions and accidental exposure.
The exposure data around MCP matters because it shows how quickly protocol convenience can become identity debt. In 2025 alone, 24,008 unique secrets were exposed in MCP configuration files, according to the State of Secrets Sprawl 2026, which is a sign that inventory, authentication and secret handling are being treated as separate problems when they are the same control surface.
For practitioners
- Require authentication on every MCP server Place real identity checks in front of each MCP server that can touch production systems, user data or operational tools. Do not rely on internal network placement or local installation as a substitute for caller verification.
- Scope agent tokens to specific tools and actions Map OAuth scopes and delegated permissions to the narrowest tool set the agent actually needs, then make those permissions revocable and time-bound. If the connector can create, delete or execute, the token should not be broad enough to do all three.
- Harden MCP packages and proxies as privileged dependencies Review connector packages, proxies and transitive dependencies with the same discipline you would apply to production control-plane software. A compromised wrapper can extend attacker reach into both the agent and the systems behind it.
- Treat localhost as a convenience, not a trust boundary Bind local MCP services to the smallest feasible interface, validate callers and avoid exposing local listeners that can be reached by a browser or another process without explicit authorisation.
- Log every tool call with identity context Capture what was called, which MCP server handled it, which identity or token authorised it, and when it happened. Without that trail, abuse, misconfiguration and malicious server behaviour become difficult to separate after the fact.
Key takeaways
- MCP connectors become high-risk the moment they can act on behalf of an agent without strong caller authentication and narrow delegated scope.
- The article ties this risk to real exposure patterns, including unauthenticated servers, compromised packages, malicious integrations and localhost abuse.
- Governed MCP use depends on identity, auditability and revocation discipline, not on the protocol alone.
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP servers without auth let anyone reach privileged tool functions. |
| NHI-05 — Overprivileged NHI | Agent connectors inherit excessive reach when scopes are broader than the task. | |
| NHI-02 — Secret Leakage | The article links MCP exposure to secret handling failures in configs and proxies. | |
| Recommendation — Enforce authenticated access on every MCP endpoint that can touch real systems. Bind MCP tokens to the narrowest delegated permissions required for the tool path. Scan MCP configs and wrappers for exposed secrets and revoke any leaked credentials immediately. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP servers authenticate services and agents, not human users. |
| Recommendation — Apply IA-9 to verify service-to-service and agent-to-server authentication for MCP traffic. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is whether MCP tool access is scoped and authorised correctly. |
| Recommendation — Review MCP entitlements so tool permissions match the minimum required scope. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article’s supply-chain and malicious-server cases show credential theft and data leakage paths. |
| Recommendation — Map exposed MCP paths to credential-access and exfiltration detections in your monitoring. | ||
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.
- Ambient authority: Access that exists because the surrounding environment already has permissions, rather than because the actor was explicitly granted them. In swarm systems, ambient authority hides who is truly acting and makes revocation, attribution, and containment much harder.
- Delegated Scope: Delegated scope is the set of actions and resources a receiving agent is allowed to use on behalf of the originating actor. Effective scope should be narrower than the agent's raw capability and must be checked at every handoff, not just at session start.
- Integration Trust Debt: The accumulated risk created by long-lived, over-scoped, or forgotten SaaS connections that remain active after their original purpose fades. The debt grows when teams treat integration setup as a one-time task instead of a lifecycle-managed identity relationship.
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 June 12, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org