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.
NHIMG editorial — based on content published by LayerX Security: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
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.
- The issue affected Claude for Chrome version 1.0.69, released on April 22, 2026.
Questions worth separating out
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 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.
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.
Practitioner guidance
- 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.
What's in the full article
LayerX Security's full report covers the operational detail this post intentionally leaves for the source:
- Step-by-step proof-of-concept behaviour showing how a zero-permission extension reached Claude's message path
- The exact approval-looping pattern used to satisfy confirmation flows
- The DOM manipulation method that changed Claude's perception of sensitive browser actions
- The reported mitigation gaps in the updated extension and why privileged mode remained exploitable
👉 Read LayerX Security's analysis of the Claude in Chrome trust-boundary flaw →
Claude in Chrome and the confused deputy problem for AI tools?
Explore further
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