Claude Desktop extensions expose a zero-click MCP trust boundary

At a glance

What this is: Researchers say a zero-click vulnerability in Claude Desktop extensions can convert a malicious calendar item into local code execution through MCP-driven tool chaining.

Why it matters: For IAM and NHI teams, the issue shows how delegated tool access and local execution privileges can collapse into a single trust boundary that conventional controls do not model well.

By the numbers:

• Researchers disclosed a critical vulnerability affecting 50 Claude Desktop Extensions that allows remote code execution without user interaction.

👉 Read Anomali's analysis of the Claude Desktop zero-click MCP vulnerability

Context

Model Context Protocol, or MCP, is designed to let AI systems call external tools and data sources. In this case, the problem is not simple application bug hunting but the absence of a strong boundary between low-risk user input and high-risk local execution. Claude Desktop Extensions run with system-level privileges, so a malformed event payload can become a vehicle for command execution if the tool chain is trusted too broadly.

For identity and access teams, this is an AI governance problem with a clear identity angle because tool permissions, local credentials, and execution rights are all in play. The article shows a pattern that is becoming more common in agentic AI environments: delegated access is assumed to be safe because the model requested it, while the actual blast radius depends on what the connected tools can do once invoked.

Key questions

Q: What breaks when AI tools can execute local code through delegated access?

A: The boundary between data and action breaks first. A model that can turn an external input into a command inherits privileges it should not have, which means a harmless-looking prompt or event can become code execution, credential exposure, or system modification. The fix is not better language understanding. It is strict separation between interpretation, authorization, and execution.

Q: Why do AI connectors create identity risk when they have system privileges?

A: Because the connector behaves like a high-trust runtime principal rather than a simple plugin. If it can read files, access secrets, or invoke commands, it can be abused even when the model itself is not compromised. Identity teams should govern that connector as an NHI with least privilege, ownership, and revocation rules.

Q: How do security teams know whether an MCP tool is over-privileged?

A: Look for any tool that can access more directories, APIs, secrets, or commands than its immediate task requires. If the tool can reuse environment variables, read broad filesystem paths, or reach multiple systems without a clear business need, its runtime privilege exceeds its intended function.

Q: Should organisations disable AI desktop connectors until controls improve?

A: Where the connector can reach local code execution or sensitive credentials, yes. That does not mean every AI integration is unsafe, but it does mean high-trust desktop tooling should be treated as a temporary exception until sandboxing, policy enforcement, and credential isolation are in place. The decision should follow privilege exposure, not vendor assurances.

Technical breakdown

How MCP chaining turns a prompt into code execution

MCP lets an LLM orchestrate external tools in response to user intent, but orchestration is not the same as authorization. If the surrounding application does not enforce a hard security boundary, a vague request such as checking calendar events can be interpreted as permission to call local utilities. That is how an attacker can place malicious instructions in a seemingly ordinary data source and rely on the model to turn them into execution steps. The vulnerability is architectural: trust is inherited from the conversation flow instead of being re-established at each tool boundary.

Practical implication: separate tool invocation rights from model interpretation so that local execution cannot occur without explicit, policy-enforced approval.

Why full system privileges make AI connectors high risk

Claude Desktop Extensions reportedly run without sandboxing and with full system privileges, which means the connector inherits the operating system rights of the user or service context. Once code execution is achieved, the attacker can read files, access stored credentials, modify settings, and stage further actions without needing a second exploit. In identity terms, the extension behaves like a high-trust non-human identity with broad ambient privilege, not a narrowly scoped helper. That makes permission scope, not just software vulnerability, the core governance issue.

Practical implication: inventory every connector that can touch files, credentials, or shell execution and constrain each one to the minimum operating context.

Why sandboxing and permission boundaries matter more than model accuracy

The flaw is not about Claude misunderstanding text in the abstract. It is about a system design that lets external content influence execution in an environment that lacks sandboxing, guardrails, and privilege separation. Security teams should think of the model as a decision broker, not a trusted enforcement point. If the broker can trigger shell commands on the host, then the relevant control is runtime containment, not prompt quality. This is exactly the kind of failure that appears when AI tooling is integrated as if it were only a productivity layer.

Practical implication: apply container isolation, deny-by-default execution policies, and host-level controls to AI tools that can reach local resources.

Threat narrative

Attacker objective: The attacker wants arbitrary code execution on the victim host with access to local secrets and operating system controls.

1. Entry occurs when an attacker embeds malicious instructions in a calendar event or similar external data source that a vulnerable Claude Desktop extension will ingest.
2. Escalation happens when the model chains that content into a local command or repository action without a hard security boundary.
3. Impact follows when the executed code gains access to files, stored credentials, system settings, and additional execution paths on the host.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero-click AI exploitation is fundamentally an identity and privilege problem, not just a prompt-security problem. The article shows that once a model can call tools with system-level authority, the real control plane becomes the permission boundary around those tools. That is where identity governance must focus, because the model is effectively acting through delegated access rather than through user intent alone. Practitioners should treat every connected tool as a privileged runtime principal.

Model Context Protocol widens the attack surface when orchestration is allowed to outrun enforcement. MCP is useful precisely because it connects models to external capabilities, but that same design creates a security gap if local execution, file access, and credential access share the same trust context. This is a named trust boundary collapse: the system assumes the model can safely bridge data and action. In practice, that assumption fails unless the host, connector, and policy layers are separated. Practitioners should map every MCP path to a distinct control boundary.

Agentic AI governance now needs non-human identity controls that are closer to PAM than to application configuration. A connector that can execute code, read secrets, and modify settings is not a benign integration. It behaves like an elevated service identity with dynamic reach, which means entitlement scope, approval boundaries, and runtime containment all matter. The lesson for identity teams is that AI tooling cannot be governed as a flat productivity layer. Practitioners should align AI access with least privilege and step-up controls.

The new named concept here is trust boundary collapse in local AI tooling. The failure is not merely unsafe content, but the mistaken assumption that a model acting on local instructions is still constrained by the user's intent. Once that assumption disappears, traditional application allowlisting is too blunt and prompt filtering is too weak. For identity and security teams, the practical conclusion is to govern AI tools as privileged execution environments, not as passive assistants.

Security teams should expect the next wave of agentic AI issues to look like privilege design failures. The more a model can call tools, the more its risk profile converges with NHI governance, secrets management, and endpoint hardening. That makes AI security a shared responsibility across IAM, PAM, endpoint, and application owners. Practitioners should build governance around what the tool can do, not what the model appears to mean.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• See also Ultimate Guide to NHIs , Key Challenges and Risks for the visibility, sprawl, and over-privilege issues that make AI tool governance harder to operationalise.

What this signals

Trust boundary collapse is becoming the defining risk pattern in agentic tooling. As AI systems gain the ability to call external tools, the important question shifts from whether the model is accurate to whether the surrounding execution path is constrained. For practitioners, that means privilege design, host containment, and secrets isolation will matter more than incremental prompt hardening. For broader context, review the MITRE ATLAS adversarial AI threat matrix and the NIST SP 800-53 Rev 5 Security and Privacy Controls.

Enterprises should expect AI desktop integrations to be assessed like privileged software rather than consumer productivity tools. That creates direct implications for identity governance, because anything that can act on behalf of a user, read stored secrets, or invoke local commands starts to look like a governed non-human identity. The operational signal is simple: if you cannot explain the connector's authority in one sentence, the entitlement model is already too loose.

For practitioners

• Restrict MCP connectors to denied-by-default execution paths Block AI connectors from reaching local shells, package managers, and script runners unless a policy engine explicitly allows that action for a documented use case. Review every connector that can touch files, spawn processes, or reach stored credentials.
• Classify AI extensions as privileged non-human identities Treat each extension or connector as a governed identity with named ownership, scoped permissions, and revocation criteria. This is especially important where the extension can read credentials, modify system settings, or inherit user context.
• Isolate AI tooling from high-risk host functions Run AI desktop tooling in sandboxed environments or controlled containers where file access, command execution, and credential access are separated from the main user session. Remove full system privileges from connectors wherever possible.
• Audit tool permissions before enabling autonomous workflows Inventory which external sources can trigger actions, then map each one to the minimum set of permissions it actually needs. Pay particular attention to calendar, email, repository, and ticketing integrations that can carry injected instructions.

Key takeaways

• A zero-click MCP exploit shows that AI toolchains can turn external content into local execution when enforcement boundaries are weak.
• The exposure matters for identity teams because connectors with system privileges behave like high-trust non-human identities.
• The practical response is to separate model interpretation from host execution and to sandbox any AI tool that can reach secrets or commands.

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.
• Trust Boundary Drift: Trust boundary drift is the gradual shift of where users and systems decide something is legitimate. In fraud and identity environments, that boundary can move from checkout to search, ads, or account recovery, which creates new opportunities for impersonation and abuse.
• Agentic AI Identity: The complete set of credentials, permissions, and governance controls applied to an autonomous AI agent — covering authentication, authorisation, action logging, and access revocation. Distinct from traditional NHI because agent identities are often ephemeral, delegated, and multi-hop.

What's in the full analysis

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

• The specific extension and deployment conditions that made the Claude Desktop issue exploitable in practice
• The researcher observations behind the CVSS 10.0 rating and the affected user estimate
• The exact command chain used to convert a calendar item into host-level execution
• The analyst discussion of when disabling MCP connectors is justified in production environments

👉 The full Anomali post covers the attack chain, affected extension scope, and deployment guidance.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It helps security practitioners apply those controls to AI tooling, service accounts, and other delegated access paths.