The same behaviour is a vulnerability in one product and a feature in another — nobody has defined what a bug is for agentic browsers

Zenity showed a zero-click attack class against five agentic browsers at Black Hat. They disclosed to all five vendors; some shipped fixes, some argued the behaviour was intended. That split is the actual story.

Bu yazının Türkçesi: Türkçe sürüm.

I use an agentic browser: open the page, read the console, take a screenshot. It works, and I am not planning to stop. This is not a "don't use it" post.

But research presented in August convinced me that the thing I use has a more fundamental limit than I had assumed. And the interesting part is not the vulnerability. It is the answers the vendors gave.

What they found

On 6 August 2026 at Black Hat USA, the Israeli firm Zenity Labs presented a class of flaws they call "PleaseFix". The affected list is not a product, it is a category: Claude in Chrome, Gemini in Chrome, Perplexity Comet, ChatGPT Atlas and Microsoft's Copilot Edge.

The defining property is that it takes no click at all. The victim does not follow a bad link, download a file, or approve anything. The agent reads a page, text on that page functions as instructions, and the agent acts with the user's authority: data exfiltration, account takeover, access to connected services. In some products the attack escapes the browser entirely and reaches local developer tooling and internal services (CTech's report).

That last part is not abstract for anyone who writes software. There is almost always something running locally right next to the browser — dev servers, internal tooling, admin dashboards. "Reaching local services" describes exactly that.

The real news: the answers differed

Zenity disclosed to all five vendors before publishing. The outcome sits in a single sentence of the coverage, and I think it is one of the more important security sentences of the year: some shipped fixes, and some argued that the behaviour reflected intended functionality.

I have to be honest about a limit here: the reporting does not say which vendor gave which answer, and I am not going to guess. But that opacity is itself the point. At least two different verdicts were reached about the same behaviour by five companies, and from the outside nobody can tell who concluded what.

This does not happen in ordinary software security. An authentication bypass is not "a bug at vendor A and a feature at vendor B". It gets an ID, a score, and a patch. For agentic browsers the industry has no shared definition of what counts as a vulnerability.

There is also a transparency dimension. In classic disclosure a vendor is free to say "we won't fix this" — but it says so in writing, with reasoning, and users adjust. In the agent world that exchange is mostly invisible. What I want as a user is simple: do you consider this a flaw or not? "Not" is a workable answer; I can draw my own boundary around it. No answer leaves me nothing to draw.

Why there is no shared definition

Michael Bargury of Zenity put the problem well:

"This is not a bug we can patch away. Agentic browsers dismantle the security boundary that browsers have relied on for decades."

Browser security rests on origin isolation. Site A cannot read site B's data. That rule has held for thirty years because the browser treats page content as data: a page cannot issue orders to the browser.

An agent erases that distinction, by design. Its whole job is to read the page and decide what to do. Page content is therefore an input that shapes behaviour. There is no mechanism separating "data" from "instruction", because in natural language they are the same substance.

You cannot patch that. Filter one pattern and the attacker writes another. The boundary is not in the code; it is in the design.

The counter-example: what happens when it is called a vulnerability

It is worth looking at a case where the same class of problem was accepted as a flaw, because it shows how arbitrary the split is.

On 7 May 2026 Microsoft published two vulnerabilities in its own agent framework, Semantic Kernel (MSRC's writeup):

Both are the same story as PleaseFix at heart: text produced by a model was treated as trusted input. The difference is that here it got a CVE, a score and a patch (Python SDK 1.39.4+, .NET SDK 1.71.0+), fixed with a four-layer allowlist around what the interpreter will accept.

So "this kind of thing cannot be patched" is not quite true. It can be, at the framework boundary. What cannot be patched is the case where reading a page and deciding what to do is the product. And with no agreement about where the line sits, the same behaviour ends up as CVE-2026-26030 in one place and "working as intended" in another.

Microsoft's own summary of the lesson is a sentence I expect to repeat on this blog: your LLM is not a security boundary.

So what do you actually do

"Stop using them" is useless advice to me, because the tool genuinely earns its place. Instead I set rules that constrain the agent's authority, rather than trying to predict its behaviour:

Concretely:

1. The agent runs in its own browser profile. A daily profile has email, admin panels and consoles logged in. There is no reason for an agent to sit inside those cookies.
2. Page content is hostile input. When I point the agent at a page, I treat that page's text as unverified data, not as a message from me. I am not counting on the agent to resist it; I am arranging for it to matter little when it does not.
3. Shrink the local surface. The most uncomfortable finding was the reach into local services. Running fewer local dev servers while the agent is working is a free win that touches no code.
4. Never delegate the irreversible. Payments, deletions, releases, DNS. That was already my rule; this research hardened it.

The general lesson

When a new category appears, security has to define the terms before the products ship. Agentic browsing has no such definition yet: one company's bug is another's feature, and both positions can be internally consistent, because nobody has answered "what should an agent never do on the user's behalf" in a place everyone shares.

Until that settles, the only defence on my side is to limit what the agent can reach — not to trust that it will always be clever enough, but to know it cannot damage what it cannot touch.

← All posts