Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Claude in Chrome and the confused deputy problem for AI tools


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 3789
Topic starter  

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:

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

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 4 weeks ago
Posts: 2127
 

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 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



   
ReplyQuote
Share: