In June 2026, University of Washington researchers demonstrated that agentic AI browsers can undermine the same-origin policy — the browser security model that is supposed to keep one website's content from reading another's — through prompt injection and memory poisoning, enabling cross-site data exfiltration. OpenAI has separately shipped a ChatGPT Atlas security update addressing a related class of prompt-injection findings surfaced by its own internal red-teaming. This post is a companion update to Securing browser-use agents, which covers the general risk shape of browser-driving agents in depth; here the scope is narrower and newer — the specific same-origin-policy finding and what OpenAI changed in Atlas in response.
If you have not read the general explainer, start there first — it covers session design, DOM injection surfaces, and domain allow-listing that still apply regardless of the finding below. This post assumes that foundation and focuses on one newer failure mode: browser agents do not respect a boundary the same-origin policy assumes they will, and the Atlas update is the first concrete vendor response worth examining in detail.
What the UW researchers demonstrated
University of Washington researchers showed, in June 2026, that agentic AI browsers can be manipulated into moving data across site boundaries the same-origin policy exists to keep separate. Their finding used prompt injection and memory poisoning as the mechanism: content on one site, processed by the agent, altered how the agent behaved when it subsequently interacted with a different site — effectively letting information flow across an origin boundary that a conventional browser tab would never permit content to cross.
The significance is not that prompt injection can move data — that risk is already covered in the threat model for indirect prompt injection. It is specifically that the same-origin policy, the browser platform's most load-bearing isolation control, does not do the job for an agent that it does for a human browsing session. That is a structural finding about agentic browsers as a category, not a bug in one product.
Why the same-origin policy does not bind an agent the way it binds a browser tab
The same-origin policy is enforced by the browser engine's separation of document contexts — scripts on one origin cannot read the DOM or storage of another origin — and that enforcement has nothing to do with what an agent does with information after the browser hands it over. An agentic browser typically extracts page content, screenshots, or accessibility-tree data and feeds it into the model's working context so the agent can reason about what it is looking at and decide what to do next. That working context is not origin-scoped. If the agent visits site A, reads its content into context, then navigates to site B, nothing in the same-origin policy prevents the agent's own reasoning from carrying information from A into whatever action it takes on B — because the policy governs what a page's script can read from another page, not what the agent's own accumulated context can act on across pages it has visited in sequence.
This is why the finding is described as undermining, rather than technically bypassing, the same-origin policy: the control is intact at the browser-engine layer and irrelevant at the agent-reasoning layer, which is where the actual cross-site data flow now happens.
What OpenAI shipped for Atlas after internal red-teaming
OpenAI shipped a ChatGPT Atlas security update after its own internal automated red-teaming surfaced a new class of prompt-injection attacks against the product. The update added an adversarially trained model together with strengthened safeguards, according to OpenAI's own account of the change. That is the level of detail OpenAI has made public about the fix; this post does not speculate beyond it, and any account of the update that describes more specific technical mechanics than "adversarially trained model plus strengthened safeguards" is going beyond what has been confirmed.
What is notable about the update, independent of its technical content, is the process it reveals: OpenAI's own internal red-teaming — not external disclosure — is what surfaced this particular attack class, and the response shipped as a defense-in-depth measure rather than a claim of having closed the underlying issue. That framing matters for the next section.
"May never be solved" — reading OpenAI's preparedness position honestly
OpenAI's head of preparedness has stated publicly that prompt injection may never be fully "solved" for browser agents like Atlas — a position worth reading exactly as stated, not softened and not exaggerated. Read honestly, it is not a claim that Atlas is unsafe to deploy, and it is not a dismissal of the UW finding or the internal red-teaming result as unimportant. It is an acknowledgment that browser-agent prompt injection is a persistent risk category to be managed continuously, the way phishing and social engineering are managed rather than a category with a final patch that ends the problem.
That framing has a direct operational consequence: any deployment decision premised on "this will eventually be fixed" is premised on something OpenAI's own preparedness leadership has explicitly said may not happen. The correct planning assumption is that browser agents will keep needing compensating controls indefinitely, not that origin isolation or prompt-injection defenses will eventually make those controls unnecessary.
What this changes for browser-agent deployment decisions
The UW finding and OpenAI's own framing together mean that same-origin isolation cannot be treated as a control you can rely on when deciding whether and how to deploy a browser-driving agent. Before this finding, a reasonable if implicit assumption was that even an agent exposed to untrusted multi-site content had some structural containment from the browser platform itself. That assumption no longer holds at the agent-reasoning layer, regardless of how solid the underlying browser engine's origin enforcement remains.
The practical shift is in what deployment questions get asked before greenlighting a browser-agent use case: not just "is the target site trusted," but "what other sites or content sources will this agent's context accumulate across a single session, and what happens if information from one bleeds into an action on another." Any use case where an agent moves between an untrusted content source — search results, embedded ads, user-generated content, email — and a sensitive destination, such as an authenticated account or a payment flow, now carries this risk by default, not as an edge case.
This also changes how a deployment decision should weigh session scope. An agent given a single, narrow task against a single trusted site inherits little of this risk, because there is no second site for information to bleed toward. An agent given open-ended, multi-site tasks — "research this and act on what you find," general web browsing, or anything that chains an untrusted read with a later authenticated write — inherits the full risk this finding describes, and should be evaluated and monitored accordingly rather than treated the same as the narrow case.
Guardrails when you cannot rely on origin isolation
Since origin isolation cannot be the control, the guardrails that matter are the ones that constrain the agent's context and actions directly, several of which the general browser-use agent security post already covers in depth: isolated, purpose-scoped sessions instead of a shared human profile; domain allow-listing to bound which sites an agent's session can reach in the first place; and action gating on state-changing operations so that even a manipulated agent cannot complete a sensitive action without a separate check.
Layered on top of those, this finding specifically argues for monitoring cross-site data movement within a single agent session as its own signal, independent of whether any individual page looks malicious — how to detect prompt injection covers detection patterns that extend naturally to this case. It also argues for treating any browser-agent session that touches both untrusted and sensitive destinations as a data-exfiltration risk by default, which data exfiltration risks in agentic AI covers as a standalone control category. The AI agent security guide is the right place to see how these pieces — session isolation, allow-listing, action gating, and exfiltration monitoring — fit into a full program rather than a checklist applied once per agent.
Praesidia provides guardrail and monitoring controls that apply to browser-driving agents specifically, including cross-session action gating and exfiltration monitoring of the kind this finding argues for. None of that changes the honest bottom line from OpenAI's own preparedness position: this is a risk category to manage on an ongoing basis, not one a single patch — Atlas's or anyone else's — closes for good.