The fix Perplexity shipped for its Comet browser was meant to be final: a hard boundary on file:// paths, out of reach of the agent no matter what the prompt said. Zenity Labs titled the account of what happened next Breaking the Patch, and the title is the finding. Blocking a disclosed path is not the same as closing the vulnerability. After Perplexity shipped a hard boundary blocking agent access to file:// paths, Zenity Labs bypassed it twice: first through view-source:file:// URLs, then by appending a #.pdf or #.html suffix that slipped past the filter.
What the boundary was holding back is worth stating plainly. A weaponized calendar invite reaches the agent; hidden instructions redirect it to an attacker-controlled page with zero clicks; the agent reads local files and moves them out as an ordinary page load, then abuses the unlocked 1Password extension to take over the vault — all while the task the user asked for appears to finish normally. Both exploit paths stem from what the field calls indirect prompt injection — untrusted content treated as instructions — and Zenity’s own summary of the patch cycle is the cleanest statement of the problem: “Each fix closed the exact route disclosed and missed the behavior underneath. Even the hard boundaries built to contain these agents are difficult to hold; as long as the agent follows untrusted instructions, there is almost always another way to the same destination.”
What a patch certifies
Roughly two and a half months have passed since Zenity presented the full scope of PleaseFix at Black Hat USA on August 5. Enterprises that spent that window putting agentic browsers in front of real work now have a worked example of what a vendor fix certifies: that one disclosed route is obstructed — not that the behavior underneath it has been mitigated.
The verification problem shows up immediately. When Gemini in Chrome and Edge tried to block their agents from opening localhost pages, Zenity records that those blocks “were quickly bypassed” — and localhost is where a browser-based attack stops being a browser problem. An agent that reaches it can turn the user’s own tools into the weapon: Comet opened a reverse shell through a local Ollama and Open WebUI setup, Gemini did the same through a Jupyter notebook, and Edge corrupted an SQL database through pgAdmin. A changelog line saying a path is blocked is a claim. The question a deployment has to answer is who tested it from the other side.
Enterprises also run this as a fleet, and the fleet does not share a floor. As Forkast recorded in August, when PleaseFix was disclosed, some platforms acknowledged the findings and committed to mitigation; others characterized the behavior as intended functionality — the natural consequence of giving an AI agent browser-level access. A mixed estate is therefore running some agents constrained by vendor-side fixes and others exposed by design, and no internal policy document makes those the same risk.
The pattern is older than browsers. Forkast’s October analysis of CVE-2026-102764 found the same structure in a remote support appliance: an authentication boundary existed, but the component trusted the origin of messages without verifying them, and the exploit walked through it. Our line on the agent layer still holds: “An agent operating through a compromised BeyondTrust appliance would inherit the actor’s elevated permissions without any independent authentication check.” A boundary that exists but does not verify is the same failure whether it wraps a browser or an appliance.
Two limits belong on the record. This is the discovering vendor’s account of its own research, published on its own pages, and Zenity sells the tooling that finds problems like this. The affected platforms also never spoke with one voice — the split above is exactly why one vendor’s patch note cannot stand in for a security posture. Neither point changes the sequence at the center: boundary, bypass, second bypass.
Michael Bargury, Zenity’s co-founder and CTO, put the framing in the March disclosure: “This is not a bug. It is an inherent vulnerability in agentic systems… Attackers can push untrusted data into AI browsers and hijack the agent itself, inheriting whatever access it has been granted. This is an agent trust failure that exposes data, credentials and workflows in ways existing security controls were never designed to see.”
For enterprises two and a half months into this deployment, the practical reading is narrow and unglamorous: the unit of assurance is the behavior the agent may follow, not the route someone blocked last month. The industry still has not settled whether cross-origin agent capability is a feature or a vulnerability, which means every deployment is running on a vendor’s current answer. The boundaries are difficult to hold even when their builders know exactly where the first test will come. As Bargury told Forkast in August: “Agentic browsers are trading away decades of hard-won security engineering for convenience. Browsers rely on SOP to isolate any random website you visit from using your logged in banking account. Agentic browsers dismantle that security boundary.” Put plainly, the same-origin policy is the rule that keeps one site from reaching into another site’s session — the rule agentic browsers relax to be useful.