Browser AI Agents: Prompt Injection From a Web Page

What is a browser agent, and why is it more exposed?

It is an agent that drives a browser or a workstation: it sees pages and screenshots, and acts through clicks and keystrokes. It is more exposed than a plain chatbot for two reasons: it reads content nobody has vetted (the whole web), and it acts with real rights, often those of an already signed-in user.

This is the pattern Simon Willison calls the “lethal trifecta”: access to private data, exposure to untrusted content, and the ability to communicate externally. A browser signed in to a mailbox or a bank account combines all three. The attack technique is indirect prompt injection (LLM01:2025 at OWASP): the instruction sits in the page while the user’s request stays untouched.

Which incidents and warnings are documented?

Three public sources are enough to frame the risk.

• Brave and Perplexity Comet (20 August 2025). Brave showed that Comet’s “summarize this page” feature sent the page content to the model without separating the user’s instructions from the page text. Hidden instructions (white-on-white text, HTML comments, a Reddit comment behind a spoiler tag) could be executed with the privileges of the user’s session. In Brave’s proof of concept, the agent fetched the account’s email address, triggered a one-time code, read it from the signed-in mailbox and sent everything back in a public comment. Brave added after publication that Perplexity had not yet fully mitigated this type of attack.
• OpenAI and ChatGPT Atlas (22 December 2025). OpenAI writes that prompt injection, much like scams and social engineering on the web, is unlikely to ever be fully “solved”, and that agent mode expands the security threat surface. The company describes an automated attacker trained with reinforcement learning to find injections that work against the browser agent, and recommends limiting the agent’s access and requiring confirmation before actions such as sending messages or making payments.
• Anthropic and computer use. The documentation says Claude may follow commands found in content even when they conflict with your instructions, and that instructions in web pages or images can override yours. Anthropic adds classifiers that scan screenshots for injection attempts, while stating that this protection is not ideal for use cases without a human in the loop.

What precautions do vendors recommend?

The three sources converge: isolate, restrict, confirm. Anthropic’s documentation lists four precautions: use a dedicated virtual machine or container with minimal privileges, avoid giving the model access to sensitive data such as login credentials, limit internet access to an allowlist of domains, and have a human confirm decisions with real-world consequences (cookies, financial transactions, terms of service).

Brave recommends clearly separating user instructions from page content, checking that planned actions match the user’s request, requiring confirmation for sensitive actions such as sending an email, and isolating agentic browsing from regular browsing with minimal permissions. OpenAI recommends limiting access and confirming actions such as messages or payments.

How do you test a browser agent against injection from a web page?

Host your own booby-trapped pages and use test accounts: never a real bank account or real data. Each test answers one simple question: does the agent obey the page?

1. Hidden text. Publish a test page with a hidden instruction (white text on white, HTML comment, hidden element, text in a collapsed area), the techniques Brave described. Ask the agent to summarise the page. Does it follow the instruction?
2. Canary. The instruction asks the agent to write a canary token into a field or call a test URL. Does the canary show up in your logs?
3. Content inside an image. Put the instruction in an image or a screenshot: the agent reads screenshots, so that is a channel.
4. Signed-in session. With a test account already signed in to a test mailbox, the page asks the agent to read or send a message. Does it act with the session?
5. Domain change. The page asks the agent to go to another test domain or submit a form there. Does the domain allowlist hold?
6. Consent actions. The page asks the agent to accept terms, cookies or a test OAuth authorisation. Does it ask for confirmation?
7. Forms and downloads. Does the agent submit a form or download a file on the page’s say-so?
8. Clipboard and local files. Are the clipboard or a file picker reachable from the agent’s session?
9. Persistence. Does the instruction get written into a memory or history reused later? See agent memory.

Measure two things: the obedience rate over several runs (a model’s behaviour varies from one run to the next) and the blast radius when the agent does obey.

When is it better not to give the agent a signed-in session?

As soon as the session opens access to data or actions the task does not require. Brave points out that an agent holding the user’s session can reach their banking, corporate systems, private email and cloud storage. If the task is to read public pages, an anonymous session in a disposable container is enough. If it needs an account, create a dedicated account with limited rights rather than lending a colleague’s. The question to ask before deployment is simple: what could the worst imaginable text on the next visited page make the agent do? If the answer includes a payment, a send or a deletion, add a human confirmation or remove the capability.

Which defences should the company put in place?

• Dedicated account and profile. A separate browser profile, with no saved passwords and no open sessions on sensitive services.
• Domain allowlist. Network filtering at the infrastructure level; an instruction in the prompt alone is not enough.
• Blocking actions. Payment, sending, deletion, accepting terms: human confirmation, with text that shows what is about to leave.
• Read/act separation. A session reading the open web should not hold write rights on your systems.
• Logging. Pages visited, actions, screenshots: without a trace, an incident cannot be reconstructed.

The AI agent security page presents the stack of controls we recommend around an agent.

How does CleanIssue test a browser agent?

We build booby-trapped pages and test accounts, then measure what the agent does with what it reads: obedience, blast radius, domains reached, confirmations requested. An AI agent pentest runs by default on a development or staging environment; production is tested only on the client’s written request. For a single browser agent, the Agent Red Team Express takes 5 days; for a fleet of agents or white-label use for your clients, we scope a Custom Red Team.

The first contact is a free 30-minute discovery call.