Agentic Browsers Break the Same-Origin Policy
- Understand the same-origin policy — the boundary that has quietly protected you for 30 years — and why an AI agent sits above it
- See which of 7 agentic browsers were found vulnerable, and the architectural reason why
- Walk the cross-origin iframe exfiltration attack step by step
- Read vendor red-team numbers honestly: mitigations halve attack success, they don't eliminate it
- Apply a practical risk posture instead of a blanket ban
On 30 June 2026, University of Washington researchers published a result that reframes AI browsers: four of seven agentic browsers they tested let a malicious website reach data belonging to a different website. Not through a memory-safety bug. Through the agent working exactly as designed.
The boundary nobody thinks about
Open your bank in one tab and a random forum in another. The forum's JavaScript cannot read your bank's page, cookies, or session. That guarantee is the same-origin policy (SOP) — an origin being the triple (scheme, host, port). It is the reason, as UW's Franziska Roesner puts it, that browsing almost any site is safe today.
SOP is enforced by the browser, below the page. Nothing a page can say talks its way past it.
Now add an agent. In the most capable designs, the agent behaves like a human user of the browser: it sees the rendered page, reads the DOM, clicks, and types. A human looking at a screen is not bound by SOP — your eyes can read two tabs. Neither is an agent built to imitate one.
Here is the sentence worth keeping: the SOP does not weaken — it stops describing reality. The browser still enforces it correctly at the JavaScript layer. The agent simply operates above that layer. So a decades-old architectural guarantee silently degrades into a behavioral one: "we hope the model doesn't fall for prompt injection." Those are not the same class of promise, and only one of them holds against an attacker who gets unlimited retries.
What was tested, and what broke
Kohlbrenner and Roesner tested seven browsers in late January–February 2026 and presented at the Agents in the Wild workshop in Rio de Janeiro on 26 April 2026.
| Browser | Preconditions for SOP bypass? | Notes |
|---|---|---|
| ChatGPT Atlas (Agent Mode) | Yes — full PoC demonstrated | End-to-end cross-origin theft achieved |
| Chrome with Gemini | Yes | Preconditions present |
| Claude for Chrome | Yes | Extension architecture allows JS injection |
| Perplexity Comet | Yes | Preconditions present |
| Brave Leo AI | No | Narrower agent capabilities |
| Microsoft Edge with Copilot | No | Narrower agent capabilities |
| Firefox AI Mode (Claude) | No | Most restrictive of the seven |
The pattern is the finding, and it is uncomfortable: the browsers that were safest were the ones that could do the least. Brave, Edge and Firefox weren't safer because of better classifiers — they hand the agent a limited, predefined slice of the page instead of the whole browsing session. Security here is bought with capability, not with cleverness. Any vendor claiming both should be read carefully.
The attack, step by step
- evil.com embeds an iframe pointing at a sensitive origin the victim is logged into — a bank, a webmail, an internal dashboard. Ordinary JavaScript on evil.com cannot read a single character inside that iframe. This is normal, allowed web behavior.
- Text on the page — visually hidden, in an alt attribute, in a DOM field the user never sees — tells the agent to include the iframe's contents in whatever it produces. To the model this is just more page content, indistinguishable from the article it was asked to read.
- "Summarize this page." No dangerous permission is requested and no warning fires, because from the browser's perspective nothing unusual is happening.
- Because the agent perceives the fully rendered page, it reads the iframe content too. The same-origin policy is not violated — it was never consulted, because no cross-origin JavaScript call was ever made.
- The injected instruction directs the summary into a form field on evil.com. The agent is being helpful, following what it read.
- Cross-origin data lands on the attacker's server. The user saw a summary appear and nothing else.
Note what is absent: no exploit, no malware, no unpatched CVE. Every step uses a documented, intended feature. That is what makes this an architecture problem rather than a bug queue.
The researchers also name three siblings of this attack, worth knowing by name:
Memory poisoning is the one that should worry you most. The other three end when you close the tab. Memory poisoning turns a single bad page into a persistent implant in your assistant, and there is currently no equivalent of "clear cookies" that most users know to reach for.
Read the vendor numbers honestly
Anthropic published red-team results for Claude for Chrome — and to its credit, published the unflattering ones. Across 123 test cases spanning 29 attack scenarios:
- Autonomous-mode attack success: 23.6% before mitigations → 11.2% after
- On a challenge set of four browser-specific attack types: 35.7% → 0%
Mitigations include site-level permissions, confirmation prompts for high-risk actions, blocking whole site categories (financial services, adult, pirated content), injection classifiers on both incoming content and outgoing actions, and specific defenses for hidden DOM fields and URL/tab-title injection. Anthropic separately reports a configuration reaching under 0.08% against its internal combined-technique suite.
Sit with the middle number. 11.2% is not a small number for a security control. A door lock that opens for one in nine strangers is not a lock. The honest reading is that these are risk reducers on a boundary that no longer exists, not a replacement for it — which is precisely the researchers' point about needing architectural redesign rather than better filtering.
The extension delivery path has its own history: researchers reported that Claude for Chrome's per-site permissions could be bypassed by writing directly to the extension's on-disk LevelDB store, and follow-up work ("ClaudeBleed") found extension-to-extension paths that could still push the agent toward reading Gmail. Permissions enforced in client-side storage are advisory against anything already running as your user. As of v1.0.80 (7 July 2026) those extension-to-extension bypasses remain reproducible — see ClaudeBleed Reopened for the two-flaw walk-through and what to do now.
Vendor response to the UW disclosure (60+ days notice) also varies: Brave, Google and Microsoft engaged; OpenAI and Firefox declined the reports citing insufficient end-to-end proof; Anthropic had not replied by publication.
- Kohlbrenner's assessment is blunt: if these agents have access to a browser holding your credentials, don't treat them as ready. Treat agentic browsing as a capability you grant deliberately, not one you leave on.
A posture you can actually hold
"Never use an AI browser" is advice nobody follows. Use the shape of the attack instead — it needs untrusted page content plus an authenticated session plus an exfiltration path in the same agent context. Break any one leg.
- Run the agent in a browser profile that is not logged into anything valuable. Sessions are the asset; an agent with no cookies to steal is a far less interesting confused deputy. This is the single highest-leverage move on the list.
- Reading arbitrary attacker-authored content is the injection vector. Summarizing your own draft is low risk; summarizing a page a stranger linked you is the exact scenario in the PoC.
- Per-site access is the one control that maps to the actual boundary. Keep the allowlist short. Assume it is advisory rather than airtight, given the LevelDB finding.
- This is the only defense against memory poisoning that a user controls directly, and it costs nothing.
- The 23.6% figure is autonomous-mode. Confirmation prompts are weak, but they convert a silent compromise into one you might notice.
- The UW ranking is capability-ordered. If a narrow summarizer suffices, the extra agency you skip is attack surface you never had to defend.
For the closely-related risk on the coding side, see When Coding Agents Get Weaponized, the mechanics in Prompt Injection, and the capability trade-offs in Computer-Use Agents.
Quiz
Check yourself
0/5Sources & further reading
- Agentic Browsers and the Same-Origin Policy — Franziska Roesner & David Kohlbrenner, UW Allen School (primary source; per-browser findings, attack taxonomy, disclosure timeline)
- Some agentic AI browsers come with major cybersecurity risks, UW study finds — UW News, 30 June 2026
- Piloting Claude in Chrome — Anthropic (red-team figures: 23.6% → 11.2%, 35.7% → 0%, 123 test cases / 29 scenarios)
- Use Claude in Chrome safely and Claude in Chrome permissions guide — Anthropic Help Center
- Chrome extension site permissions can be bypassed via direct LevelDB write — anthropics/claude-code issue #26779
- ClaudeBleed Reopened: Browser Extensions Can Still Push Claude for Chrome to Read Your Gmail — Manifold Security
- Prompt injection still drives most agentic AI security failures in production — Help Net Security on the OWASP Top 10 for Agentic Applications