The Web Was Built to Keep Websites Apart. AI Agents Are Breaking That Wall

Your email, bank and shopping accounts may all be open in the same browser, but websites are normally prevented from reading one another. AI browser agents are built to move across those boundaries for you. That convenience is useful, but it also creates a new route to private data and logged-in accounts.

7 browser-agent systems
The researchers compared seven products and found major differences in how much web content their agents could access and control.

The wall that keeps websites apart

The web feels like one continuous place, but the browser treats each website as a separate and potentially untrusted environment. A foundational rule called the same-origin policy normally prevents code on one site from reading or changing sensitive content belonging to another.

If a malicious page is open while your email or bank is open elsewhere, it should not be able to inspect those accounts merely because they share a browser. Site isolation, sandboxes and cookie controls add further protection.

This separation is one of the quiet engineering achievements behind the modern web. Browser agents challenge it because their usefulness depends on collecting information from one service and acting on another.

How an AI agent changes the risk

A browser agent can understand an instruction, read pages, navigate, click buttons and fill forms. Some implementations work through powerful extensions, and many operate inside a browser profile where the user is already signed in.

Imagine asking an agent to summarise a page and add its recommended products to a shopping cart. The agent must interpret untrusted web content and then take actions elsewhere. If hidden or malicious text is mistaken for a new instruction, the agent can be redirected away from the user's goal.

This is called indirect prompt injection. The hostile instruction can appear in a webpage, advertisement, document, review or embedded frame. The AI is supposed to treat it as content, but may instead follow it as a command.

What the researchers demonstrated

Franziska Roesner and David Kohlbrenner at the University of Washington examined Brave Leo AI, ChatGPT Atlas, Chrome with Gemini, Claude for Chrome, Microsoft Edge with Copilot, Firefox AI Mode and Perplexity Comet.

In a full proof-of-concept attack against ChatGPT Atlas in Agent Mode, malicious instructions on one page caused the agent to include information from a different embedded website in a summary, then return the combined text through a form controlled by the attacker. The agent effectively became a bridge across a boundary that ordinary webpage code could not cross.

The researchers also reported important attack preconditions in Chrome with Gemini, Claude for Chrome and Perplexity Comet if prompt injection succeeded. They identified related risks such as forged actions on another site, access to masked input and poisoned chat memory.

Separate work from Manifold Security focused on the software surrounding Claude for Chrome. The company reported that extension behaviour and permission handling could expose workflows involving Gmail, Google Docs and other services. These were researchers' findings about particular versions and configurations, not evidence that every Claude session or AI browser was compromised.

Why a smarter model is not enough

Language models are designed to interpret language, which makes it difficult to separate a trusted instruction from hostile text with perfect reliability. Training, filters and attack detectors can reduce failures, but a consequential action should not depend entirely on the model making the correct judgement every time.

The more important security question is: if the model becomes confused, what is it technically allowed to read, change or send?

Google has described a layered approach for agentic Chrome features. It includes a separate model that reviews proposed actions without seeing raw untrusted content, task-specific lists of permitted websites, detection of suspicious instructions and confirmation before sensitive actions such as payments or messages.

This moves part of the defence into browser architecture. The difficult trade-off remains: narrow permissions can make an agent frustrating, while broad permissions make it useful but increase the damage possible after a mistake.

How safer browser agents should work

• Access only what the task requires: Each job should receive a limited list of readable and actionable websites, with permission removed afterward.
• Preserve where data came from: Sensitive information from one site should not flow into an unrelated destination.
• Require confirmation: Payments, messages, account changes, downloads and data exports should stop at a browser-enforced checkpoint.
• Keep visible records: Users should be able to review what the agent read, attempted and changed.
• Expire task memory: Content from an untrusted page should not silently influence future sessions.

People experimenting with browser agents should consider a separate browser profile that is not used for banking, health records or administrative work. Auto-execution should remain disabled where possible, and unexpected attempts to move information between unrelated sites should be treated as warning signs.

AI agents can connect fragmented services and remove repetitive work. The challenge is not to stop them crossing boundaries, but to make every crossing limited, visible and reversible. The safest agent will not be the one that can go everywhere. It will be the one that can prove why it needs access before it acts.