Extenshiextenshi.io/blog
Back to articles
extension-securityai-extensionsagentic-aichrome-extensionsclaudeistrustedpermissions

The click nobody made: how to check which extensions can drive your AI assistant

Researchers say a rogue extension can fake a click and make Claude for Chrome read your Gmail. How extension-to-extension attacks work, and how to check yours.

Maxim Kosterin
9 min read

Almost every safety control in an AI browser extension bottoms out in the same sentence: and then the user clicks to confirm. That click is the last thing standing between an agent with access to your mailbox and an agent doing something with it. So it's worth asking what the extension actually checks when the click arrives — because in a browser, a click is just an event, and events can be manufactured.

That's the finding at the centre of research published by Manifold Security in July 2026, covered by BleepingComputer and SecurityWeek. According to the researchers, another extension in your browser could fake the click that launches Claude for Chrome's built-in tasks — and reach the Gmail, Docs and Calendar access you granted the AI, not the access it was granted itself.

What Manifold found in Claude for Chrome

Claude for Chrome ships with a set of predefined tasks — nine of them, according to the reporting — that the extension can run on your behalf. Three of those reach connected Google services: read your Gmail, pull your most recent Google Doc along with its comments, or read your Google Calendar.

The extension decides you asked for one of these by listening for a click on a specific page element. According to Manifold Security's write-up, that handler never checked whether the click came from an actual person.

The browser hands you that check for free. Every DOM event carries a read-only isTrusted flag: true when the browser generated it from real user input, false when a script dispatched it. A click created with dispatchEvent() — or with element.click() — arrives with isTrusted: false stamped on it. The flag is there precisely so that code can tell "a human pressed this" apart from "some JavaScript said so."

Manifold's demo, as reported, was six lines pasted into the claude.ai console: inject an element carrying one of the supported task identifiers, dispatch a click at it, watch the workflow run. The researchers said the console logs showed isTrusted: false on the event that was honoured. Their proposed fix is a single line at the top of the handler — return early if the event isn't trusted.

Pasting into your own console is a demo, not an attack. The attack version is an extension that can inject a content script into claude.ai. That's an ordinary, unremarkable capability — any extension with host access to a site can run code in that page, and thousands of perfectly normal extensions hold access to every site you visit. The attacker's extension doesn't need connectors, doesn't need Google OAuth, doesn't need to convince you of anything. It needs to be installed, and it needs the AI extension to be sitting next to it.

The second finding, and the response

Manifold reported a second issue in the same disclosure: a skipPermissions=true parameter on the side panel URL that, per the researchers, brings the panel up in a privileged state without a consent prompt. Manifold's own framing is the honest one here — on its own it isn't a working exploit, because something else has to control that URL first. Anthropic classified it as informational, according to the reporting.

On the synthetic-click finding, the reporting says Manifold disclosed both issues through Anthropic's bug bounty programme on 21 May 2026 and got an acknowledgement the next day, and that Anthropic closed the synthetic-click report as already tracked under a broader issue. Manifold retested on 7 July against version 1.0.80 and said it still reproduced, eight releases after the report. In the researchers' words: "Eight Claude for Chrome releases later, the bypass is still six lines of JavaScript."

Two things to keep straight. Anthropic did engage — through a bounty programme, with acknowledgement, and with a stated position on severity, which is more than a lot of vendors offer. And I could find no public statement from either side since mid-July confirming a fix or withdrawing the finding, so treat the status as unresolved-as-far-as-anyone-has-said rather than as confirmed-broken-today. CyberScoop and Malwarebytes covered the same disclosure independently if you want to compare accounts.

The part that isn't about Claude at all

Strip out the product name and you're left with something that should worry you more.

Every mental model we use for extension safety reasons about one extension at a time. The install prompt lists what this extension wants. Store review looks at this extension's code. My own permission write-ups, and Extenshi's scoring, mostly answer "what can this thing reach?" None of that describes what an extension can reach through the extension sitting next to it.

Agentic extensions break that model badly, because they hold something no ordinary extension holds: long-lived, pre-authorised access to services outside the browser. You connected Gmail once. You approved Calendar once. From then on, the AI extension is a permanent, logged-in doorway into accounts whose passwords never touched the attacker's code. A neighbour extension that can merely inject a script into one domain gets to knock on that door — and if the door only checks that somebody knocked, it opens.

I've written about the two other shapes this takes. ClaudeBleed, disclosed by LayerX in May, abused externally_connectable — a trusted origin, not a trusted sender. Man-in-the-prompt attacks go through the DOM to rewrite what you typed before the model sees it. Manifold's own post is titled "ClaudeBleed Reopened," which tells you how the researchers see the lineage. Three different mechanisms, one boundary: the browser gives co-resident extensions far more reach into each other than any permission dialog admits.

That boundary is not going to be fixed by a store policy. It has to be fixed in each extension that holds something worth stealing.

How to check your own setup

Five things, in the order I'd actually do them. None of them require trusting that a specific bug got patched.

1. Find out who else is on the page. Open chrome://extensions, click Details on each extension, and look at Site access. Anything set to "On all sites" can run code on claude.ai, on your Gmail, on your bank. Switch what you can to On click — most extensions work fine that way and simply stop having standing access. This one change removes the precondition for the whole attack class.

2. Count your AI extension's connectors, not its permissions. The install prompt for an AI assistant looks tame; the blast radius comes from what you attached afterwards. Open its settings and disconnect Gmail, Drive, Calendar, Salesforce or anything else you're not actively using. Reconnecting takes 30 seconds. Leaving it connected is a standing grant.

3. Turn the approval mode down. Claude in Chrome offers manual approval, automatic approval, and a skip-everything mode, plus per-site "always allow" grants — Anthropic documents all of it in its permissions guide. Skip-all is where an unattended agent does the most damage with the least noise. Use manual on anything touching mail or documents, and review the sites you've already blanket-approved.

4. Stop sharing a profile. This is the structural fix and the one people skip. Run your AI agent extension in a browser profile with nothing else installed. Not "nothing suspicious" — nothing. Extension-to-extension attacks need co-residency, and a separate profile removes it entirely, which no amount of vetting can.

5. Re-check what's actually installed. Not what you meant to install. Extensions change hands, and a clean extension can ship a payload in an update — I covered malware that arrives in the update, not the install a couple of weeks ago. Walk the list, uninstall what you don't recognise or don't use, and pay attention to anything that quietly holds all-sites access.

If you build extensions, this is a one-liner

The developer lesson generalises well past AI, so it's worth saying plainly: a click event is not consent. If your extension gates a privileged action behind a button, check the flag.

element.addEventListener("click", (event) => {
	if (!event.isTrusted) return;
	runPrivilegedThing();
});

That's it. isTrusted is false for anything a script dispatched, which is exactly the case you want to reject. It's not a complete defence — a co-resident extension has other routes into a page — but "any neighbour can press the button" shouldn't be one of them, and closing it costs a line.

How Extenshi helps

The reason I keep pushing on "who else is on this page" is that the answer is genuinely hard to see. Chrome shows you permissions one extension at a time, at install, in language designed not to alarm you.

Extenshi catalogues extensions across Chrome, Firefox and Edge with their declared permissions, publisher details and scan results, so you can check what an extension asks for and who ships it before it ends up next to your AI assistant.

And if you'd rather start from the browser you already have than from a store page, npx @extenshi/guard scan reads the extensions installed across your browsers and flags the risky ones, with disable-and-undo built in. No account needed for the scan.

Scan your extensions →

Sources

This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If any entity referenced in this article believes information is inaccurate, contact [email protected] and we will review and update.

Related Articles