The Bug Is a Missing Trust Check
The mechanics here are almost mundane, which is what makes them dangerous. Every browser event carries a property called Event.isTrusted. Clicks a human actually makes are marked true. Clicks that JavaScript generates programmatically are marked false. Ax Sharma of Manifold Security found that Claude for Chrome's content script and side-panel handlers never check that flag before executing one of the extension's predefined tasks. So a script can manufacture a click, dispatch it at Claude's interface elements, and the extension treats it as a genuine user request. There is no exotic exploit chain, no memory corruption, just a permission decision that trusts an input it should have validated.
Because the check is missing, a second extension installed in the same browser can drive Claude on the user's behalf. Sharma demonstrated abuse across nine built-in workflows: identifying and unsubscribing from Gmail promotions, reading Google Docs comments and feedback, finding Calendar availability and creating meetings, and modifying and converting Salesforce leads. Claude runs those tasks with the user's own authenticated sessions, so the malicious extension inherits Claude's reach into every connected service without ever holding those credentials itself. The AI becomes the confused deputy, acting with real authority on behalf of an attacker who never had that authority directly.
Why This Is Worse Than a Normal Extension Risk
Browser extensions have always been a soft spot, and security teams know a malicious one can read pages and steal cookies. What changes here is the leverage. Ordinarily a rogue extension has to do the work itself, scraping the DOM, parsing pages, and reconstructing sessions. With this flaw, it can instead delegate to an AI agent that already has structured, permissioned access to Gmail, Docs, Calendar, and a CRM, and that knows how to operate those apps. The attacker gets a capable operator that reads, summarizes, and takes actions, driven by nothing more than synthetic clicks aimed at a trusted assistant sitting in the same browser.
Manifold rated the exposure by mode. In default operation, where Claude still surfaces an approval, the finding lands as high severity because the attacker can coerce that approval flow. For users who enabled the Act without asking setting, the researchers put it in critical territory, because the extension can drive Claude silently with no prompt to tip off the victim. That gradient matters for enterprise policy. The convenience setting that removes friction for a busy employee is exactly the setting that removes the last visible signal that something is wrong, and most users will not connect those two facts on their own.
It Is Still Open in the Current Release
The uncomfortable part is the timeline. Manifold first reported these issues in May 2026. Anthropic responded to the earlier ClaudeBleed prompt-injection weakness by restricting the arbitrary-prompt path, boxing external callers into a fixed set of tasks rather than letting them ask Claude to do anything. That hardening narrowed the blast radius, but it did not close the synthetic-click gap. Manifold confirmed both findings remain reproducible in v1.0.80, the release that shipped July 7, 2026, which is eight versions after the ClaudeBleed fix. So the fixed set of tasks is still reachable by a script that fakes a user click, and the constraint that was supposed to contain the risk is doing less than it appears.
Anthropic acknowledged the synthetic-click report through its bug bounty program and said it was already monitoring the behavior as part of a broader issue, while a secondary finding involving an internal skipPermissions parameter was classified as informational. That is a reasonable posture, but reasonable is not the same as fixed. For a defender, the operative fact is that a current, downloadable version of a widely promoted AI browser extension exhibits the behavior today. Vendor intent to address something later does not reduce your exposure this week. The control you can act on is your own deployment policy, not Anthropic's backlog.
The Real Lesson Is About Agent Authority
Strip away the specific product and this is a preview of the whole browser-agent category. We are handing AI assistants standing, authenticated access to email, documents, calendars, and business systems, and then wiring them to act on ambient signals inside a shared, hostile execution environment. The browser was never designed as a trust boundary between an AI agent and every other piece of code running in the same tab. When the agent's trigger for taking a privileged action is an event that any script can forge, the agent's authority is only as strong as its weakest input validation. Here that validation was simply absent.
This is the confused-deputy problem that identity and platform teams have fought for decades, now wearing an AI face. The agent holds real permissions, and something with fewer permissions tricks it into exercising them. Every organization piloting browser-based AI assistants should assume more instances of this shape are coming, across vendors, because the underlying pattern is architectural. The question to put to any agent vendor is not whether they have a bug bounty. It is how the agent distinguishes a legitimate instruction from a forged one, and what stops a co-resident extension or a malicious page from being treated as the user.
What Security Teams Should Do This Week
Treat AI browser extensions as privileged software, because that is what they are. Inventory who has Claude for Chrome or comparable agents installed, and pair that with an inventory of every other extension in those same browsers, since the attack requires a second malicious extension to be present. Extension allowlisting through enterprise browser management is the highest-leverage control here, and most organizations still run permissive extension policies that would let this play out unimpeded. If you cannot enforce an allowlist, you cannot make confident claims about what is co-resident with your AI agents.
Then look hard at the convenience settings. The Act without asking mode should be disabled by policy in managed environments until this class of issue is resolved, because it removes the one prompt that could expose an attack in progress. Tighten the AI agent's connected-service scopes to the minimum each role needs, so that even a coerced action touches less. And feed this into procurement: your AI extension review needs a question about input trust and event validation, not just data handling and model provenance. The agents you deploy are now part of your attack surface, and they deserve the same scrutiny you give any tool that can read the CRM.
The Governance Gap This Exposes
Most enterprises approved AI assistants through a lens built for SaaS: data residency, retention, model training on customer data, contractual terms. Those questions still matter, but they miss the failure mode on display here, which is runtime abuse of a legitimately installed agent through the browser it lives in. A vendor can have flawless data handling and still ship an extension that a rogue neighbor can puppet. Governance that stops at the contract and never reaches the execution environment will keep missing this category, and browser agents are only going to accumulate more capability and more connected services over the next year.
The roadmap implication is to extend your AI governance down to the endpoint. That means owning the browser as managed infrastructure, enforcing extension policy centrally, and building a review step that evaluates how each agent authenticates its instructions. Claude for Chrome is a useful forcing function precisely because Anthropic is a serious vendor with a mature security program, and the gap still exists. If it can happen here, assume it can happen with the less rigorous agents your teams are already installing. The organizations that get ahead of this will be the ones that treated browser agents as a new tier of privileged access before an incident made the case for them.
