Can a webpage hijack your AI browser? Yes — but a demo is not a breach wave.

Two statements are hiding inside one story, and separating them decides the case:

• Capability claim — a malicious page can redirect an agentic browser into actions the user never asked for. This is a question about architecture, and it is answerable by demonstration.
• Prevalence claim — ordinary users are being compromised this way today, at volume. This is a question about the world, and it is answerable only by incident data that nobody in this evidence set has published.

This is also not a rerun of Case 005. There the question was whether agents pursue unauthorized goals of their own during evaluations. Here the agent is doing exactly what it was built to do: read a page and follow instructions. The instructions simply came from an attacker rather than from the user. That is a confused-deputy problem — a security failure of trust boundaries, not a story about a model going off the rails.

The redirection worked from a benign starting point. Zenity Labs says a planted comment on X plus a malicious newsletter page redirected Atlas in the middle of an otherwise ordinary user request. The user asked for nothing unusual; the content the agent read supplied the new objective.

The WhatsApp proof of concept completed. Zenity reports that Atlas navigated to the victim’s already-logged-in WhatsApp Web session and sent the injected message to contacts. The agent inherited a live authenticated session and used it — no credential theft required.

The soft safeguards were bypassed by craft, not by exploit. Zenity describes using a realistic-looking page, splitting instructions across screenfuls, using Hebrew wording to evade English-tuned filtering, and framing the payload as an “intent collision.” Zenity says no traditional software vulnerability was needed: the attack abused intended agent capabilities.

The Amazon result is the part most retellings get wrong. Zenity says Atlas changed the delivery address and added an item to the cart — but Atlas’s final-purchase restriction held. The researchers could not make Atlas click the buy button directly. The order completed because Atlas asked Amazon’s Rufus assistant to finish it, and Rufus complied. The hard boundary was not broken; it was routed around by handing the last step to a second AI.

Disclosure timeline. Zenity says it reported the findings on January 11, 2026, and that OpenAI acknowledged them on February 17, 2026.

OpenAI’s December 22, 2025 post on hardening Atlas is unusually candid, and the strongest version of the company’s case is worth stating plainly. OpenAI calls prompt injection one of the most significant risks it actively defends against for browser agents, and an open challenge it expects to require years of work. It describes layered safeguards, adversarial training and automated red teaming, and says it had rolled out stronger safeguards.

Notably, OpenAI also concedes the limit: deterministic security guarantees are challenging, and prompt injection is unlikely ever to be fully “solved.” A vendor saying its own defence is probabilistic is evidence in the researchers’ favour, not against them.

On the specific findings, WIRED’s August 5 report relays OpenAI’s response: the company said it had deployed an update earlier in 2026 to address the reported issue and strengthen Atlas protections, and that Atlas would be deprecated on August 9, 2026, with protections extending to browser capabilities in the new ChatGPT app. That is the company’s account of its own remediation. It is not independent proof that the class of attack is closed, and we do not treat it as such.

The failure mode is not unique to one vendor. Researchers at the University of Washington (Franziska Roesner and David Kohlbrenner, ICLR 2026 Agents in the Wild workshop; page last updated April 15, 2026) tested seven agentic browsers: Brave Leo AI, ChatGPT Atlas (with and without Agent Mode), Chrome with Gemini, Claude for Chrome, Edge with Copilot, Firefox AI Mode, and Perplexity Comet. They demonstrated a full proof-of-concept cross-origin data-theft attack on ChatGPT Atlas, and found the preconditions for cross-origin attacks also present in Chrome with Gemini, Claude for Chrome, and Perplexity Comet if prompt injection succeeds.

They are careful about the spread. The researchers explicitly say products vary, and that more restrictive agents can have stronger security properties at the cost of capability. Their tests were conducted in late January and early February 2026 and did not involve real-user sensitive data.

The benchmark supplies the limiter. The WASP benchmark (Evtimov et al., arXiv:2504.18575) found that even agents with advanced reasoning and instruction-hierarchy mitigations were susceptible to low-effort, human-written prompt injections. But it separates two outcomes that headlines merge: across the tested agents, attacks began diverting the agent from the user objective 16–86% of the time, while achieving the attacker’s full end-to-end goal only 0–17% of the time.

The authors use that gap deliberately, to warn against overstating demonstrations that do not achieve realistic end-to-end harm. Read together with Zenity’s work, the picture is coherent rather than contradictory: skilled researchers can drive an attack all the way home, and the average injection mostly derails an agent without completing the attacker’s objective. Both facts are load-bearing.

What no source in this record provides is prevalence. There is no incident count, no telemetry, no measure of real users affected. Consistent with our method, and with the discipline we applied to headline rates in Case 003, demonstration evidence cannot be promoted into prevalence evidence.

Mostly upheld. The core accusation survives strongly. A malicious webpage can hijack an agentic browser into actions the user did not request: Zenity showed end-to-end WhatsApp abuse, and independent UW work reproduced the broader cross-origin prompt-injection failure mode on Atlas while finding the preconditions in other major products.

• Upheld: the attack class is real, cross-vendor, and does not require a traditional software vulnerability.
• Not established: that ordinary users are being widely compromised. These are controlled proof-of-concept attacks, not prevalence data.
• Corrected: Atlas’s hard purchase block did not fail. It held. The completed purchase depended on Atlas invoking a second AI, Rufus — which is its own architectural warning about agents delegating to agents.
• Time-limited: product versions and mitigations move quickly, and the specific exploit may be patched or the product deprecated. The architectural class persists regardless.

Nothing here justifies abandoning browser agents, and nothing here justifies handing them the keys to everything. The useful posture is the boring one security people have recommended for decades, applied to a new kind of deputy.

• Give a browser agent the narrowest access that lets it do the task, and close the session afterwards.
• Do not give an agent broad logged-in reach across email, banking, or admin consoles while it browses arbitrary pages.
• Prefer deterministic confirmation and permission boundaries for consequential actions — sending, paying, changing an address — rather than trusting the model to refuse.
• Keep sensitive accounts isolated in a separate browser or profile the agent never touches.
• Treat webpage and email content as adversarial input, not as instructions. Anything your agent reads, an attacker may have written.

The realistic risk today is not that your browser has already been hijacked. It is that agent permissions are being handed out faster than the boundaries that would contain a successful injection. That is a fixable gap, and it is worth fixing before prevalence data exists.