What jumps out to me is how boring the attacker’s foothold is compared with the payoff. A malicious extension is hardly exotic. But once a browser starts delegating real work to an AI assistant, that “just an extension” foothold stops being minor and starts looking like a control plane.
That’s the uncomfortable bit here. The extension doesn’t need to “hack the model” in any dramatic sense. It just has to sit where the browser already trusts it, then bend the agent’s inputs and outputs enough to make the browser do the embarrassing thing for you. I think that’s the right mental model for this class of bugs: not prompt injection in the usual sense, but privilege injection through the browser’s plumbing.
The phrase “Prompt Forcing” is useful, if a little flashy. It captures the real problem: the agent isn’t being tricked into reading bad text, it’s being handed instructions plus the ability to act on them. Once you have that combination, the security story gets muddy fast. The final harmful action may look like it came from legitimate software, which is exactly the kind of thing that tends to confuse endpoint controls and human reviewers alike.
I’m also struck by how uneven the targets are. Chrome, Edge, Opera Neon, Comet, Claude in Chrome — same broad idea, different failure surfaces. That suggests the issue is not one vendor’s sloppy implementation so much as a category problem. If you build an AI assistant into a browser and then let extensions meddle with network requests, page content, or embedded app flows, you’re asking for this kind of cross-boundary abuse.
The Comet and Edge examples sound especially messy because the agents can act, not just read. Reading local files or browsing history is bad enough. Having the agent summarize emails and send them elsewhere is a much more vivid abuse case, because it shows how quickly “helpful assistant” becomes “automated exfiltration tool” when the prompt path is compromised. That’s the part I’d spend time red-teaming if I were building one of these products: not whether the model can be nudged, but whether the browser can be made to carry out an instruction chain that never should have existed.
I do think the article is fair to point out that this needs the extension to be installed first. That matters. It’s not a remote drive-by by itself. But that qualifier can lull people into underestimating it. Extensions are already a common trust boundary break in browsers, and here the blast radius is much bigger because the agent has more authority than a normal tab.
If I were defending this stack, I’d be suspicious of any design that lets an extension influence agent state indirectly through network rewriting or synthetic events. The whole point of these assistants is that they can act “on behalf of the user.” That makes authentication and intent validation much harder, and the usual browser security model doesn’t seem ready for it yet. Maybe the answer is tighter isolation. Maybe it’s provenance checks for every agent instruction source. Perhaps it’s simpler: fewer ambient permissions, less magic.
Reference: BragJack attacks hijack AI browser agents through malicious extensions
