TL;DR: Claude in Chrome trusted origin context rather than the true script sender, letting a zero-permission extension inject prompts, bypass confirmations, and trigger cross-site actions such as email, Drive, and GitHub access, according to LayerX Security. The flaw shows how agentic tooling can inherit user privileges when browser trust boundaries are too loose.
Editorial analysis by NHI Mgmt Group, based on content published by LayerX Security: “ClaudeBleed: A Flaw In Claude’s Browser Extension Allows Any Extension to Hijack It”.
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.
Q: Why do confirmation prompts fail when agentic tools can act across browser sessions?
A: Because generic confirmation is not the same as action-bound consent.
Q: How do security teams spot delegated browser actions that are being abused?
A: Look for unexpected execution mode changes, cross-site actions that were not initiated by the user, and repetitive approval patterns that do not match normal interaction.
Practitioner guidance
- Validate the true sender Require cryptographic or strongly authenticated message sender checks for any assistant that accepts commands from a browser page or extension channel.
- Bind approvals to specific actions Replace generic yes-or-no prompts with one-time, non-replayable approval objects tied to a single browser action, destination, and scope.
- Restrict privileged execution modes Treat act-without-asking mode as a governed security state that requires explicit authorisation, logging, and revocation controls.
Bottom line: The central problem is a confused deputy design in which an assistant trusts browser origin context instead of authenticating the real sender.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Claude in Chrome exposes a confused deputy risk for agentic tools
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Claude in Chrome exposes a confused deputy risk for agentic tools
Claude in Chrome exposes an assumption collapse, not just a bad permission check: the trust model assumed that page origin was a sufficient proxy for the true sender of a command. That assumption was designed for a browser environment where origin boundaries roughly track authority. It fails when another extension can inject script into the trusted page and reuse the same channel. The implication is that agentic browser assistants need sender authentication as a first-class governance control, not a cosmetic add-on.
A question worth separating out:
Q: Who is accountable when an agentic browser assistant can switch into privileged mode?
A: Accountability sits with whoever controls the execution state, not just the user who installed the extension. If a tool can move itself or be moved into act-without-asking mode without explicit authorisation, that state change must be owned, logged, and reviewable as a privileged access event.
👉 Read our full editorial: Claude in Chrome exposes a confused deputy risk for agentic tools