Author: Mohit Kumar
Part of The Agentic Attack Surface series on securing AI systems, agentic workflows, and the AI software supply chain.
In 1995, Netscape shipped a rule so boring that most working developers can state it but few have ever had to think about it: code loaded from one origin cannot read data from another origin.
That single rule is why a malicious ad on a news site cannot read your bank balance in the next tab. It is the load-bearing wall of the web security model. Every technique you learn in a web security course, CSRF, XS-Leaks, clickjacking, CORS misconfiguration, cookie scoping, exists because attackers have spent thirty years trying to get around that one rule.
Agentic browsers removed it. On purpose. As a feature.
What Zenity actually demonstrated
At Black Hat USA 2026, Michael Bargury and Stav Cohen from Zenity Labs presented a vulnerability class they named PleaseFix, building on their March 2026 disclosure involving Perplexity Comet.
The finding, as Dark Reading summarized it: agentic browsers fundamentally break the same-origin rule, because an AI agent's entire job is to combine and act on content from different websites rather than keeping them isolated. PleaseFix exploits that trust model by placing malicious instructions inside content the agent encounters, an email, a calendar invite, a web page.
The exploit chains they showed run from credential theft through account takeover to remote control of the victim's machine. In one chain, an ordinary "summarize my email" request kicked off an attack that exfiltrated Gmail data, silently shared the victim's Drive with the attacker, and enabled takeover of Slack and X accounts.
Zero clicks. No approval dialog. No malicious download.
Why this is a web security problem, not an AI problem
Here is where most coverage goes wrong. It files this under "prompt injection," notes that OWASP ranks prompt injection first, and moves on.
That's true and insufficient. Prompt injection describes the delivery. The reason the delivery is catastrophic is a set of very old web security properties that agentic browsers inherit and then break:
The agent runs inside your authenticated session. Not a sandbox. Not a fresh profile. Your cookies, your SSO tokens, your logged-in state across email, files, calendar, and every SaaS app you've touched today. Everything CSRF protections were invented to defend has just been handed a legitimate driver.
The agent has no origin. Classic browser security works because every piece of executing code carries a provenance label, this script came from origin-a, so it may only touch origin-a data. When an agent reads a page, the instructions it extracts arrive stripped of that label. Text from an attacker's blog post and text from the user's own prompt enter the same reasoning context as equally authoritative tokens.
That second property is the whole vulnerability class in one sentence. The web solved instruction/data confusion at the origin boundary. Agents reintroduced it at the token boundary.
The delivery surface is anything the agent reads. Research on this class points to the shared root cause across related attacks: agentic browsers inherit the user's authenticated session and process untrusted content, emails, calendar invites, documents, pages, with no validated boundary separating legitimate user intent from injected instruction.
And because injection is text, the payload can hide anywhere text can hide. White text on white backgrounds. Zero-opacity overlays. CSS-hidden elements. Techniques a web pentester learned in their first month, now weaponized against a reasoning engine instead of a rendering engine.
The vendor response is the actual story
Zenity reported these findings to the affected vendors. The responses split.
Some acknowledged the research and committed to mitigation. Others characterized the behavior as intended functionality, the natural consequence of granting an AI agent browser-level access.
Sit with that for a second. Half the industry classified cross-origin agent capability as a vulnerability. The other half classified the identical behavior as a feature.
That disagreement is not a PR problem. It's a signal that there is currently no shared threat model for this product category. When two vendors can't agree whether a given behavior is a bug, no CVE process, no bug bounty scope, and no procurement security questionnaire can function correctly.
The uncomfortable version: the vendors calling it a feature are not obviously wrong. The entire value proposition of an agentic browser is that the agent can reach everything you can reach. Remove cross-origin capability and you don't have a hardened agentic browser, you have a chatbot in a sidebar. The sandbox escape is not external to the product. It is the product.
What a real defense would look like
There is no shipped answer yet. But the shape of the answer is visible, and it maps cleanly onto things web security already knows how to do.
Origin tags on context. Every token entering the model's context carries a provenance label, and the policy engine enforces that content from an untrusted origin can never authorize a tool call. This is the same-origin policy, rebuilt one layer up. It's the correct fix and it's hard, because it requires the model layer to respect a label it currently has no representation for.
Dual-model review. A separate model inspects proposed actions for anomalies before execution. Cheap to bolt on, useful in practice, and defeatable by anything that can inject into both models.
Intent binding. The agent's action set is constrained to what the user's original stated intent could plausibly require. "Summarize my inbox" should not have Drive sharing in its reachable action space, ever.
To my knowledge none of these are robustly deployed in production at scale. That's the honest state of the field.
If you're building on these
Three things I'd insist on before an agentic browser or browser-using agent goes anywhere near an enterprise session:
- Test indirect prompt injection against every authorized integration scope, individually. Not "does the agent resist injection", that's unfalsifiable marketing. Ask: for each connected service, can injected content from an unrelated origin cause an action in that service? Every integration you add is a new origin pair to test.
- Enumerate the reachable action set, not the permission list. Permissions tell you what the agent may do. The reachable action set tells you what a single malicious page can make it do. Those are different documents and only one of them is a threat model.
- Treat the agent as a non-human identity with the union of every permission it holds. Because that's what it is, and that's the blast radius.
The web spent thirty years building isolation between origins, and the answer to "what if we removed that" turned out to be exactly what you'd expect. The interesting question now isn't whether it was a mistake. It's whether anyone can put it back without destroying the reason the product exists.
Part 2 of The Agentic Attack Surface.
I write weekly on AI security, cloud security, and security architecture. LinkedIn · GitHub
Top comments (0)