When the web talks back

AI browsers and prompt injection: when the page gives the orders

An agentic browser reads pages on your behalf and acts on what it reads: it fills forms, follows links, logs in and buys things. That makes every page it visits a potential instruction and every logged-in session a potential victim. Two of the largest vendors in the space have now said in public that the problem cannot be fully solved. This guide explains what they found, what they changed, and how to use such a browser without handing it your accounts.

Published 5 September 2026
By the Prompt Injection Scanner editorial team (Mothership Engineering)
Every claim traces to the primary references listed at the foot of the page

What an agentic browser does, and why that is the problem

A conventional browser shows you a page and waits. An agentic browser reads the page, decides what to do next and does it, across many pages, often inside sessions where you are already signed in. Seen through Simon Willison’s lethal trifecta, it is the trifecta by construction: the page is untrusted content, the signed-in session is private data, and navigation, form submission and messaging are the exit. Nothing has to be added for an attack to be possible; something has to be removed for it not to be.

The page is the input field. Anyone who can put text on a page the agent might read, in a comment, a review, a forum post, a listing or a document, can address the agent directly. And unlike a phishing email, the text does not need to persuade a person of anything; it only needs to read like an instruction.

Comet: from a hidden comment to a leaked login code

Brave discovered the problem in Perplexity’s Comet browser on 25 July 2025 and published its analysis on 20 August. The attacker’s text was hidden in ordinary page content, white on a white background or inside a collapsed spoiler on a forum post. When the user asked Comet to summarise the page, the agent read the hidden text as part of the request. Brave’s description of the failure is the whole problem in one sentence: the browser could not distinguish the user’s summarisation task from instructions embedded in the content, so it treated everything as a user request.

The proof of concept then walked through the trifecta step by step. The agent opened the user’s account page to read their email address, navigated to a look-alike domain that differed from the real one by a trailing dot, triggered a one-time login code, opened the user’s Gmail to read the code, and posted both the address and the code back to the forum where the attacker could collect them. No exploit of the browser’s code was involved; the agent did what it was built to do, for the wrong party.

Atlas: the vendor’s own verdict

On 22 December 2025 OpenAI described its work on hardening the ChatGPT Atlas browser. The company built an automated attacker, trained with reinforcement learning, that searches for injections across long, multi-step workflows, and used what it found to train the model and tighten safeguards. Its demonstration case had the attacker seed a user’s inbox with an email; when the user later asked the agent for an out-of-office reply, the unpatched agent followed the planted instruction and sent a resignation letter instead.

OpenAI’s framing was unusually plain for a vendor: prompt injection, like scams and social engineering on the web, is unlikely ever to be fully solved. Its advice matched that view. Require confirmation before the agent sends a message or makes a payment, and do not grant an agent broad access to an inbox or account without a specific reason, because the more it can see and do, the more an injected page can make it see and do.

Why the vendors say it cannot be solved outright

The UK National Cyber Security Centre gave the structural reason in December 2025. SQL injection was fixed by parameterised queries, which enforce a separation between instructions and data at the interface. A language model has no such interface; inside it there is only the next token, so hostile text cannot be kept apart from the request by construction. The centre’s guidance is to stop hoping to filter the text and instead to constrain the system’s actions with deterministic, non-model safeguards, and to drop the system’s privileges to those of whichever party supplied the content it is reading.

Brave’s four recommendations for browser vendors are that principle applied. Treat page content as untrusted, always. Check the model’s proposed actions independently against what the user actually asked. Require explicit confirmation for security-sensitive tasks. And make agentic browsing a distinct mode that a user cannot wander into by accident, so that ordinary browsing never carries the agent’s risk.

Using an AI browser without handing it your accounts

Run agent tasks in a separate browser profile with no signed-in sessions, so there is nothing for an injected page to reach. Never let the agent act inside email, banking or anything that receives one-time codes; those are the accounts the Comet attack went for first. Read the agent’s plan before it runs and confirm every form submission and every move to a new domain, watching for look-alike addresses. Treat a summary that contains an instruction, a link you did not ask for or a request to sign in somewhere as a sign that the page was talking to the agent, and stop.

For pages and documents you intend to paste into an assistant yourself, the scanner on this site reads the HTML without rendering it, separates visible text from hidden elements, comments, attributes and link destinations, and reports instruction-shaped passages with their location. It does not fetch URLs, so it cannot review a live page the agent will visit, and it cannot see what your browser is signed in to. A clean scan of a page’s text is useful; a separate profile and a confirmation step are what actually keep the session yours.

Primary references

These sources describe the external risks or standards discussed above. The property’s detector claims remain limited to its versioned policy and recorded evidence.

Browse every guide

Result boundary: Findings are indicators for review. Detection cannot certify a source, and a no-indicator result does not replace downstream isolation, validation, least privilege or approval.