Claude in Chrome exposes a confused deputy risk for agentic tools

At a glance

What this is: LayerX Security reports a trust-boundary flaw in Claude in Chrome that lets even a zero-permission extension control the assistant and drive cross-site actions.

Why it matters: This matters because IAM teams now have to treat browser-embedded AI assistants as privilege-bearing non-human identities whose approvals, sender validation, and execution context need governance.

By the numbers:

• Anthropic updated the extension to version 1.0.70 on May 6, 2026, after the issue was reported on April 27, 2026.
• 1.0.69, sue affected Claude for Chrome version 1.0.69, released on April 22, 2026.

👉 Read LayerX Security's analysis of the Claude in Chrome trust-boundary flaw

Context

Claude in Chrome is a browser-embedded AI assistant, which means its security model depends on knowing who is allowed to send instructions and under what context. The flaw LayerX Security described breaks that assumption: the extension trusted the claude.ai origin, not the actual script sender, so another extension could inject commands and make Claude act on the user’s behalf.

For IAM and NHI practitioners, the important detail is not that a browser extension was involved, but that a privileged assistant became a control point for cross-site actions. Once the assistant can send mail, access Drive, or touch GitHub, it behaves like a non-human identity with delegated access, not a passive interface.

The case is not an isolated pattern. It is a clean example of how AI-assisted browsers inherit trust from the surrounding session, then amplify a small sender-validation failure into a broad privilege problem.

Key questions

Q: What breaks when a browser AI assistant trusts origin context instead of the real sender?

A: The assistant can be turned into a confused deputy. A zero-permission extension may inject instructions through a trusted origin and make the assistant perform actions as if they were authorised. That breaks sender validation, weakens consent, and lets a low-privilege caller borrow the assistant's higher privileges across Gmail, Drive, or GitHub.

Q: Why do browser-embedded AI assistants need NHI governance?

A: Because once an assistant can send mail, share files, or touch repositories, it is no longer just an interface. It is a non-human executor with delegated access, approval states, and revocation needs. IAM teams should govern it like a privileged workload identity, with explicit sender validation, lifecycle control, and auditability.

Q: How do security teams stop repeated approval prompts from becoming false consent?

A: They should bind consent to a single action, not to a reusable yes-or-no state. The approval should be tied to a specific request, a one-time token, and a non-replayable execution path. Otherwise, an attacker can loop confirmations until the assistant accepts the request and performs the action.

Q: Who is accountable when an AI assistant performs a sensitive action after DOM manipulation?

A: Accountability sits with the organisation that allowed the assistant to make security decisions from attacker-controlled UI signals. If the model relies on page labels or screenshots to decide whether to click, share, or send, then the trust model is flawed. The control owner must treat the UI as untrusted and the action path as privileged.

Technical breakdown

Origin-based trust in browser extensions

Chrome extensions use messaging boundaries to decide which scripts can talk to which privileged components. In this case, the Claude extension accepted messages because they appeared to come from the trusted claude.ai origin, but it did not validate the execution context behind that origin. That means any script injected into the page, including one from another extension, could reach the assistant. This is a classic confused deputy pattern: the deputy has privilege, the caller does not, and the deputy cannot tell the difference. The security failure is not the prompt content alone, but the missing authentication on the sender.

Practical implication: validate message senders with authenticated, least-privilege extension-to-extension controls rather than origin trust alone.

Approval looping and weak consent binding

The assistant’s confirmation flow treated repeated approval text as sufficient evidence of user intent. That is a state-based model, not an action-bound one, because it checks whether a confirmation phrase appears rather than whether the approval is cryptographically linked to one specific task. Attackers can exploit that gap by repeatedly supplying the expected response until the assistant proceeds. In identity terms, this is consent without binding. The system believes it has consent, but it lacks durable proof that the consent belongs to the action being executed.

Practical implication: bind approvals to one-time, non-replayable tokens and a specific action object, not to a generic yes/no state.

Perception manipulation through DOM control

The assistant relied on browser-visible text, DOM structure, and screenshot interpretation to decide what to click or share. If an attacker can alter labels such as 'Share' to 'Request feedback', the model is making a decision against a manipulated interface. That means policy enforcement is only as strong as the assistant’s perception layer. Once the UI becomes attacker-controlled, the model can be induced to perform high-risk actions while believing they are harmless. The root issue is that decision inputs are not isolated from the attacker’s influence.

Practical implication: separate action authorization from UI perception and treat browser-rendered prompts as untrusted input.

Threat narrative

Attacker objective: The attacker wants to turn a trusted browser AI assistant into an execution proxy that exfiltrates data and performs user-authorised actions without meaningful consent.

1. Entry: a zero-permission extension injected script into the claude.ai page context and reached the assistant through externally connectable messaging.
2. Credential access: the attacker did not steal a password, but leveraged trusted assistant context to issue prompts that could access Gmail, Drive, and GitHub content.
3. Escalation: approval looping and privileged mode bypassed consent checks, then DOM manipulation altered the assistant's perception of what it was approving.
4. Impact: Claude executed attacker-controlled cross-site actions, including sharing files, sending mail, and extracting source code on behalf of the user.

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

Origin trust is the wrong security primitive for agentic browser assistants. The flaw worked because Claude trusted claude.ai as an origin, not the sender actually executing inside that origin. That is not a narrow implementation bug, it is a category mistake for any assistant that can act across services. When an AI assistant can send mail, open files, or trigger sharing, sender identity must be authenticated at the message layer. Practitioners should treat origin-based trust as insufficient for privileged non-human execution.

Confused deputy behaviour is now a governance problem, not just an application flaw. Claude in Chrome acted with the user's privileges while receiving instructions from an untrusted extension. That means the control failure sits at the boundary between browser identity, assistant identity, and delegated action. The implication for identity programmes is that browser-embedded AI must be governed as a privileged executor, not as a simple productivity add-on.

Permission prompts that are not bound to a specific action are not real consent. The approval looping described here shows a consent model that can be satisfied by repetition rather than by intent. That breaks the governance assumption that user approval is meaningful if the system can be persuaded to reuse it across steps. The field needs to recognise this as a weak-consent failure mode, where acknowledgement exists but accountability does not.

Perception-based security is too brittle for AI assistants operating across web apps. If the assistant reasons from visible text and DOM labels, attackers can rewrite the environment the model is using to make decisions. That means the trust boundary extends beyond API calls into what the model can see and infer. For IAM and NHI governance, this is a reminder that access control can fail even when permissions look constrained, because the decision path itself is attacker-shaped.

Protected browser assistants need the same lifecycle discipline as other high-privilege NHIs. Once an AI assistant can initiate actions, interact with external systems, and persist across sessions, its access path needs governance around provisioning, mode changes, approval state, and revocation. The lesson for practitioners is that runtime capability must be tied to lifecycle control, or the assistant becomes a durable privileged identity with no reliable offboarding point.

From our research:

• A minimal extension with zero declared permissions was enough to control Claude's behaviour through the browser trust boundary, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• For a broader view of how identity governance failures show up in real incidents, see 52 NHI Breaches Analysis for the recurring breach patterns that follow weak trust boundaries.

What this signals

Confused deputy governance is now part of AI identity design. If an assistant can act across SaaS and developer tools, the programme must distinguish between the assistant's runtime context and the caller that initiated it. The relevant control gap is sender authentication, not model intelligence. Teams should map any browser-embedded assistant against privileged workflow patterns and review whether the approval path can be replayed, spoofed, or inherited from the wrong context.

Weak-consent failures will become more visible as assistants gain more surface area. The more a browser assistant can see and do, the more likely attackers are to manipulate either the interface or the approval process. That makes capability scope a governance issue, not just a product setting. Teams tracking AI assistants should align this problem with OWASP Agentic AI Top 10 and validate that the assistant cannot act on attacker-shaped inputs.

We should treat browser AI assistants as privileged identities with mode-based risk. The practical question is not whether the assistant can do useful work, but whether any mode exists that bypasses normal approval controls without explicit lifecycle governance. If that mode can be enabled silently, the programme has a standing-privilege problem disguised as productivity. For a deeper identity model, review the Top 10 NHI Issues and map assistants to the same control expectations as other high-risk NHIs.

For practitioners

• Harden sender validation for browser AI assistants Require authenticated extension-to-extension messaging and reject origin-only trust for any assistant that can execute privileged actions across web apps.
• Bind approvals to a single action Use one-time, non-replayable approval tokens tied to a specific request so repeated confirmation text cannot satisfy a later action.
• Treat assistant perception as untrusted input Assume DOM labels, page text, and rendered UI can be manipulated before the assistant reads them, and separate decision logic from browser-visible content.
• Review privileged-mode governance Inventory any assistant mode that bypasses normal approval flows and require explicit lifecycle controls for enabling, auditing, and revoking that mode.

Key takeaways

• Claude in Chrome illustrates a confused deputy failure where a trusted assistant can be driven by an untrusted extension.
• The evidence is concrete: LayerX showed zero-permission control paths that could send mail, share files, and extract repository data.
• The control lesson is specific: authenticate the sender, bind consent to one action, and govern assistant modes as privileged NHI access.

Key terms

• Confused Deputy: A confused deputy is a privileged system that performs actions on behalf of an untrusted caller because it cannot tell who really initiated the request. In AI-assisted identity contexts, this becomes dangerous when a browser assistant inherits user privileges but accepts instructions from a lower-trust extension or script.
• Weak Consent Binding: Weak consent binding occurs when approval is treated as a reusable state instead of a one-time decision tied to a single action. In browser AI assistants, that allows repeated yes responses, or similar prompts, to authorise actions the user never explicitly reviewed in context.
• Perception-Based Security: Perception-based security is a control model that relies on what an AI system can see in the interface, such as labels, DOM text, or screenshots, to decide whether an action is safe. If attackers can alter that view, the security decision becomes attacker-shaped rather than policy-shaped.
• Browser-Embedded NHI: A browser-embedded NHI is a non-human identity that operates inside the browser session and can act across web applications with delegated access. Once it can send mail, share files, or touch source code, it needs the same lifecycle, approval, and audit controls applied to other privileged machine identities.

Deepen your knowledge

Browser-embedded AI assistant governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to secure privileged assistants that act across web apps, it is worth exploring.

This post draws on content published by LayerX Security: LLMjacking: How Attackers Hijack AI Using Compromised NHIs. Read the original.