MCP auth failures are turning agent connectors into backdoors

At a glance

What this is: The article argues that Model Context Protocol has become a security liability when servers are exposed without authentication, scoped access, or auditability.

Why it matters: It matters because MCP now sits in the same control path as cloud consoles, filesystems, email, and databases, so identity teams must treat agent connector access as production-grade privilege.

By the numbers:

• Security researchers scanning the public internet have found roughly 1,862–2,000 internet-reachable MCP servers exposed with no authentication.
• CVE-2025-6514 in mcp-remote affected over 437,000 downloads.
• The September 2025 npm phishing campaign compromised 18 popular packages.

👉 Read WorkOS's analysis of MCP authentication and security exposure

Context

Model Context Protocol is a standard that lets AI agents connect to tools, data, services, and local apps. The security gap is that many deployments are treating those connectors like convenience layers instead of privileged access paths, which creates exposed control points across NHI and agentic AI programmes.

The primary issue is not MCP itself but the assumption that tool bridges can stay trusted once they touch real systems. In practice, unauthenticated servers, weak scoping, and supply-chain exposure turn integration plumbing into an identity governance problem for service-level and agent-level access.

Key questions

Q: What breaks when an MCP server is exposed without authentication?

A: Without authentication, an MCP server becomes ambient authority. Anyone who can reach it may enumerate tools, invoke actions, or trigger downstream systems with the server’s permissions. That breaks the identity assumption that access is granted to a known subject and time-bound context. In practice, unauthenticated exposure turns a connector into an open control surface.

Q: Why do MCP connectors create more risk for NHI governance than ordinary APIs?

A: MCP connectors often sit between AI agents and privileged tools, so a single endpoint can expose files, cloud actions, email, and databases at once. That concentrates NHI risk into one delegation path. The governance challenge is not just authentication but scope, revocation, and audit across a connector that can translate model intent into real operations.

Q: How do security teams know if an MCP deployment is outside its intended boundary?

A: Look for any server that is reachable beyond its expected network scope, accepts tool calls without strong identity proof, or can act on systems it was not explicitly scoped to touch. Strong warning signs include localhost servers accessible from the browser, public endpoints with no auth, and tool catalogs that exceed the intended use case.

Q: Who is accountable when an MCP server is abused through a malicious package or proxy?

A: Accountability should rest with the team that approved the connector, the package source, and the access model, because MCP supply-chain compromise is an identity governance failure as well as a software risk. If the component can execute or delegate privileges, it belongs in the same governance chain as other production access paths.

Technical breakdown

Why unauthenticated MCP servers become ambient authority

MCP servers often expose a tool catalog and action endpoints over HTTP or localhost, but optional authentication means the server may accept requests from anyone who can reach it. Once a server can read files, query data, or invoke commands, the connector inherits the permissions of the wrapped system. That creates ambient authority, where reachability becomes the de facto access model instead of identity or policy. In agentic environments, this is especially dangerous because the tool boundary sits between model prompts and real operations, so a permissive server effectively collapses the distinction between suggestion and execution.

Practical implication: require authentication on every MCP server that touches real systems before the connector is allowed into production.

How supply-chain compromise amplifies MCP risk

MCP ecosystems depend on packages, proxies, and plugins that sit close to the agent control path. If one of those components is compromised, the attacker can affect both the application and the agent toolbelt, not just a single library call. CVE-2025-6514 in mcp-remote showed how an OAuth proxy can become a credential and execution risk, while the npm phishing campaign demonstrated how malicious updates can cascade through transitive dependencies. The technical lesson is that MCP components should be evaluated as control-plane dependencies, not ordinary utilities.

Practical implication: put MCP packages under the same security review, pinning, and update controls you use for privileged infrastructure components.

Why localhost MCP is still a real attack surface

Local MCP deployments rely on the assumption that a server bound to localhost is isolated from remote abuse. Drive-by attacks break that assumption by using a browser page or another local trigger to hit a permissive local server and force tool calls. If the server lacks origin checks, request validation, or user confirmation gates, local convenience becomes an ambient execution surface. This pattern matters because it shows that physical locality does not equal trust. A machine can be locally reachable and still be externally steerable through a web session or malicious page load.

Practical implication: treat localhost MCP as exposed infrastructure and add origin validation, request filtering, and explicit user confirmation for sensitive actions.

Threat narrative

Attacker objective: The attacker wants to turn a trusted AI connector into a high-leverage control path for data theft, command execution, or unauthorized system changes.

1. Entry occurs when an attacker reaches an internet-exposed MCP server or abuses a permissive localhost connector that accepts unauthenticated requests.
2. Escalation follows when the server exposes tools with cloud, file, email, or deployment permissions, allowing the attacker to invoke privileged actions through the connector.
3. Impact is achieved when the attacker uses the MCP tool path to steal data, execute commands, or alter systems with the authority of the wrapped service.

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

Identity does not become safer when tool access is hidden inside protocol convenience. MCP makes integration easier, but ease of integration is not a security control. When an agent connector can reach files, email, databases, or cloud consoles, the connector becomes a privilege boundary that must be governed like any other production access path.

Ambient authority is the named concept this category now has to own. MCP deployments that rely on reachability, local binding, or friendly defaults are creating a control model where the ability to connect is mistaken for the right to act. That model fails because identity governance cannot distinguish between a benign test bridge and a privileged operational path once the same tool endpoint serves both.

Optional authentication was designed for small trusted circles. That assumption fails when MCP servers are internet-reachable and distributed through package ecosystems that attackers already probe. The implication is not merely that controls were missing, but that the original trust envelope no longer matches deployment reality.

The 52 NHI breaches Report remains relevant because tool connectors now behave like high-value NHI endpoints. The article’s core pattern matches the broader NHI breach record: exposed secrets, over-broad access, and weak lifecycle control turn convenience layers into compromise paths. Practitioners should read MCP governance through the same lens they use for service accounts and workload identities.

MCP security is converging with workload identity governance. Once agents depend on scoped, revocable, auditable tokens, the problem stops being “agent tooling” and becomes identity lifecycle discipline. The field is moving toward policy-enforced connector access, and teams that still treat MCP as a developer-only concern will inherit the blast radius later.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
• For the broader risk pattern, see The 52 NHI breaches Report for how exposed credentials and weak lifecycle control expand blast radius.

What this signals

Ambient authority is now the practical test for MCP governance. If a connector can execute actions without a strong identity layer, the environment has already moved beyond developer convenience and into production privilege. Teams should align MCP controls with least-privilege token design, lifecycle revocation, and auditability using the same discipline they apply to other NHI access paths.

A useful planning concept here is connector blast radius: the amount of downstream damage a single MCP server can cause if its credentials, package chain, or local exposure is abused. The more tools a server wraps, the more identity governance must focus on scoping and revocation rather than simple installation approval.

For practitioners

• Require authentication on every MCP server Block any server that can touch production data, run commands, or enumerate tools unless access is mediated through authenticated identity and revocable tokens.
• Scope tool permissions to least privilege Map each MCP tool to a narrow role or entitlement set and remove broad delegation paths that let one connector inherit unrelated system permissions.
• Treat MCP packages as control-plane dependencies Pin versions, review transitive dependencies, and place MCP proxies and plugins under the same approval and monitoring process used for privileged infrastructure.
• Harden localhost deployments against drive-by abuse Validate origin, add explicit user confirmation for sensitive actions, and stop assuming that localhost reachability is a substitute for trust.
• Log every tool call with identity context Capture who initiated the request, which MCP server handled it, what tool executed, and which downstream resource changed so incident response has a clear audit trail.

Key takeaways

• MCP becomes a security liability when connectors are exposed without authentication, scoping, or audit controls.
• The evidence points to an ecosystem where credential exposure, malicious packages, and permissive local servers can all turn a bridge into a backdoor.
• Practitioners should govern MCP like production identity infrastructure, with authentication, least privilege, dependency review, and full tool-call logging.

Key terms

• Model Context Protocol: A standard that lets AI agents connect to tools, services, data sources, and local apps through a common interface. In security terms, it creates a new identity boundary because the connector can turn model output into real system actions if authentication and scoping are weak.
• Ambient Authority: Access that exists because a system is reachable, not because a specific subject has been verified and authorised. In MCP environments, ambient authority appears when a connector accepts requests from anyone who can reach it, turning connectivity into unintended privilege.
• Connector Blast Radius: The total downstream damage a single tool bridge can cause if its credentials, packages, or permissions are abused. For MCP, blast radius depends on the systems wrapped by the connector, the scope of its token, and whether actions are logged and revocable.
• Revocable Delegated Token: A time-bound credential that allows a connector or agent to act only within a defined scope and can be withdrawn without replacing the underlying application. This is the core control pattern for keeping MCP access aligned with least privilege and lifecycle governance.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by WorkOS: MCP auth: The difference between a bridge and a backdoor. Read the original.