Claude in Chrome exposes a confused deputy risk for agentic tools

At a glance

What this is: LayerX Security shows that Claude in Chrome can be manipulated by a zero-permission extension because the extension trusts origin context rather than the actual sender of commands.

Why it matters: IAM and security teams should treat agentic browser tooling as a privilege boundary problem, because weak sender validation can let untrusted code act with the user's authority across multiple services.

Context

A confused deputy appears when a privileged component accepts instructions from an untrusted actor and then performs actions using its own authority. In this case, the problem is not a weak password or a stolen token. The issue is that the browser extension's trust model allows injected scripts to reach privileged Claude functionality without proving who issued the command.

For IAM and NHI practitioners, the important lesson is that agentic browser tooling creates a new delegation layer inside the user session. The browser extension, the page context, and the AI assistant are not interchangeable identities, yet this design treated them as if origin trust were enough. That is exactly where normal consent and authorization assumptions break down.

The starting position is atypical only in implementation detail, not in risk pattern. Many organisations now pilot AI assistants inside browsers, productivity suites, and developer workflows without first defining how the assistant should authenticate the message sender or bind approval to a specific action.

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 confirmation prompts fail when agentic tools can act across browser sessions?

A: Because generic confirmation is not the same as action-bound consent. If the system accepts repeated approval text or allows mode changes that bypass the original intent, an attacker can satisfy the workflow without proving that the user approved that exact action. Consent must be tied to a specific, non-replayable request.

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. A browser assistant that suddenly shares files, sends mail, or accesses code after minimal prompting is showing governance failure, not just an odd user journey.

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.

Technical breakdown

Why origin-based trust creates a confused deputy

Claude in Chrome exposed a privileged message interface through an externally_connectable-style browser path, which means page code could talk to the extension if it appeared to come from the trusted origin. The flaw is that origin is not identity. Any script executing inside that page context, including injected code from another extension, could send commands that the Claude extension accepted as legitimate. That turns the assistant into a confused deputy: a trusted component that acts on behalf of an attacker because it cannot distinguish page origin from actual instruction source.

Practical implication: validate the sender, not just the origin, before any browser assistant accepts commands.

How approval loops and UI perception can be abused

The article shows two different bypass patterns beyond the initial injection path. First, repeated approval prompts can be satisfied by mechanically sending confirmation text, which means consent is state-based rather than bound to the specific action. Second, the assistant relies on UI cues such as visible labels, DOM structure, and screenshot interpretation, so an attacker can rename buttons or hide sensitive context and alter what the assistant believes it is approving. This is not just prompt injection. It is delegation abuse through weak action binding and attacker-controlled perception.

Practical implication: bind approvals to a non-replayable action object, not to generic yes-or-no prompts.

Why privileged mode changes the risk boundary

The updated extension introduced extra checks for standard mode, but the article shows that privileged mode could still bypass those controls without user notification or consent. That matters because a tool that can silently switch operational modes is not just a safer or less safe version of the same workflow. It is a different trust boundary. Once the assistant can move from ask-before-acting to act-without-asking, any validation that depends on UI confirmation becomes conditional rather than foundational, and the original external message path can remain exploitable.

Practical implication: treat execution mode as a security state that must be explicitly governed and independently authorised.

Threat narrative

Attacker objective: The attacker wants the assistant to execute privileged browser actions and exfiltrate data while appearing to operate under normal user authority.

1. Entry occurs when a zero-permission extension injects code into the claude.ai page context and reaches the assistant's message interface through trusted origin handling.
2. Credential or authority abuse follows when Claude accepts the attacker-controlled messages as legitimate instructions and uses its own delegated browser privileges.
3. Escalation happens when confirmation flows are bypassed through approval looping and the assistant's UI perception is manipulated to disguise sensitive actions.
4. Impact is achieved when the assistant performs cross-site actions such as sharing files, sending email, and exposing private repository content on the user's behalf.

Breaches seen in the wild

• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Confused deputy risk becomes operationally important the moment an AI tool can act across services: email, Drive, and GitHub are not just integrations, they are delegated authority surfaces. Once an assistant can cross those boundaries, the question is no longer whether it can answer prompts, but whether it can be tricked into performing a valid action for the wrong principal. That changes the governance problem from chatbot safety to delegated access control.

Weak consent is a governance failure when the approval is not bound to the action: the article shows that repeated confirmation and mode switching can satisfy control logic without proving user intent. This is the same class of problem that identity teams see when session state is mistaken for authorisation state. The practitioner conclusion is that human approval, assistant approval, and execution approval must be separated.

Perception-driven automation creates a new identity security control surface: when an assistant makes decisions from DOM text, screenshots, and UI semantics, the interface itself becomes part of the trust model. That means attackers can target the assistant's perception rather than the underlying policy engine. For identity programmes, this broadens the scope from account governance to action integrity, especially in agentic browser workflows.

Browser-side agentic tooling should be treated as delegated privilege with lifecycle risk: once an AI assistant can be switched into act-without-asking mode, its effective privilege profile changes as part of runtime operation. The control question is no longer only who installed the extension, but who can move the assistant into a higher authority state. Practitioners should govern that state transition as they would any privileged access pathway.

What this signals

Action integrity is the control gap here: identity teams have long focused on whether a principal is authenticated, but this case shows that an authenticated session can still be misused if the action itself is not bound to the approved principal, destination, and mode. That pushes governance toward request signing, non-replayable consent, and explicit execution-state control.

Agentic browser workflows also create a new offboarding problem. If an extension, assistant mode, or delegated browser channel can persist beyond the user's expected interaction, the organisation needs a way to revoke the assistant's effective authority, not just the underlying account.

Confused deputy risk should now be part of browser-based AI governance reviews: any tool that can read the page, infer intent from the UI, and then perform external actions deserves the same scrutiny as other privileged delegation paths. The right question is not whether the assistant is clever enough to help, but whether it is constrained enough to prevent acting for the wrong principal.

For practitioners

• 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.
• Harden UI perception inputs Do not let assistant decisions depend on attacker-controlled labels, DOM text, or screenshots without independent policy checks.
• Instrument cross-site action trails Record which assistant, session, and mode initiated sensitive actions across Gmail, Drive, and GitHub so delegated activity can be reviewed after the fact.

Key takeaways

• The central problem is a confused deputy design in which an assistant trusts browser origin context instead of authenticating the real sender.
• The article demonstrates practical abuse through file sharing, email sending, and private GitHub code access, showing that the risk is not theoretical.
• Sender validation, action-bound consent, and governed execution modes are the controls most directly associated with limiting this failure mode.

Key terms

• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• Actor-bound consent: A delegation model in which the approved actor is named explicitly during authorization, not implied by the client or user session. In agentic systems, this preserves who was allowed to act and prevents delegated access from collapsing into anonymous application behaviour.
• Execution Mode: Execution mode is the operating state that determines whether an assistant must ask before acting or can proceed without repeated confirmation. In browser-based agentic systems, mode changes are security-relevant because they can expand delegated authority without a fresh authorisation step.
• Sender Authentication: Sender authentication is the process of verifying whether an email message really came from the claimed domain or system. Protocols such as SPF, DKIM and DMARC reduce spoofing, but they work best when paired with behaviour analysis and mailbox-level response.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.