Should you let an AI agent drive your browser?

Not in the browser where you are logged into your mailbox, your bank and your internal tools, and the reason has nothing to do with the quality of the agent. An agent driving a browser does not inherit the page you show it, it inherits every session open in that profile, at the same time. And the page you asked it to read was written by somebody else.

That combination is the problem, and it is new. A human reader who lands on a booby-trapped page does not spontaneously open their mailbox to copy its contents elsewhere; an agent does, because it cannot tell what you asked for apart from what it read on the way. We describe the same mechanism elsewhere when a CV contains instructions aimed at the agent. The browser is the extended version: the hostile text no longer arrives in an attachment you can isolate, it arrives from any page on the web, and the rights it borrows are yours.

What exactly happened in the Comet case?

An instruction hidden in a Reddit comment pulled an authentication code out of a user’s mailbox, with the user having done nothing beyond clicking “summarise this page”.

The detail is worth reading, because it is more mundane than a classic security scenario. Brave published the demonstration on 20 August 2025, having reported it on 25 July. The instructions were folded behind a spoiler tag, the kind that hides a film’s ending: invisible to the reader, perfectly legible to the machine collecting the page text. On the summary request, the assistant read those instructions, took the user’s email address from their account details, visited a spoofed domain, opened the mailbox already logged in inside the same browser, retrieved the one-time code that arrived there, then published both the address and the code as a reply to the original comment.

No technical flaw anywhere in that chain. No malware, no stolen password, no privilege escalation. Every step was an action the agent was entitled to take, which is precisely why no filter placed on the text it read would have held. Brave concludes that the web’s usual security assumptions no longer apply, and recommends isolating agentic browsing from ordinary browsing.

Is the web really filling up with these traps?

Yes, and at a rate that has only recently become measurable. The Cloud Security Alliance reports a 32% relative rise in content carrying indirect prompt injection between November 2025 and February 2026, across two to three billion pages crawled each month. This is no longer a lab demonstration, it is a population.

How those payloads hide is instructive, because it explains why human review catches nothing. Of the cases catalogued by Palo Alto Networks Unit 42, 37.8% are text perfectly legible to the machine and invisible on screen, 19.8% go through an HTML attribute, and 16.9% through a style rule that suppresses display. The rest use encoding or assembly at runtime. And 85.2% of cases adopt a social-engineering frame, meaning they address the model politely rather than ordering it about.

Documented objectives range from forced transfers to recursive file deletion, and one of them is worth flagging here: biased recruitment screening. A page instructing the agent to treat a profile favourably is a payload like any other, and a harder one to spot than the rest, because its result looks like an opinion.

Why the useful boundary is the session, not the page

Because it is the only line that holds without knowing the attack in advance.

The usual reflex is to control what the agent reads: an allowlist of sites, a filter on suspicious instructions, a check on content before it reaches the model. We tried that approach elsewhere, on the tool descriptions of an MCP server, and we removed it after a few weeks. It catches the crude attempts, lets the rest through, and mostly manufactures the sense of safety that makes people relax where it mattered.

What holds is duller and more effective: deciding what the agent can reach if it is turned. A dedicated browsing profile, with no mailbox, no bank and no internal tool logged in inside it, reduces the worst case to “it read a public page and talked nonsense”. That is a quality incident rather than a security incident, and the difference between the two is the whole question.

The same logic applies to what the agent may do from that profile. Read, and nothing else. Posting a comment, filling a form, sending a message are outbound actions, and nothing outbound leaves without a person releasing it. In the Comet case, that single rule would have broken the chain at the last step, the one where the code was published.

It is worth saying what that separation leaves intact, or the position reads as a refusal. An agentic browser in an empty profile is an excellent tool, and we use one: reading public documentation, comparing the pricing pages of three suppliers, checking that a company exists and what its site looks like. Those are reads whose result you can check at a glance, on pages with no particular reason to target you, where the worst case is a wrong answer. The rule does not forbid the browser, it forbids the browser with your sessions in it.

What about sourcing, then?

That is the use case behind the question in our industry, and the answer is no, for two reasons that do not overlap.

The first is contractual and not at all new: the terms of the large professional platforms forbid automation from a personal account, and we have written before about why we refuse to let an agent act under a recruiter’s identity. The suspension risk falls on one person, the decision that took it was collective, and that asymmetry settles it.

The second is the subject of this article, and it is broader. A profile page, a job posting, a comment thread under an advert are all text written by a third party. An agent reading them in a session carrying your rights is in exactly the Comet situation, with an added economic incentive for whoever wrote the page, since influencing a candidate shortlist has immediate value.

What remains possible, and what we do, is to read those sources through access designed for it, with a credential that belongs to nobody in particular and a scope reduced to reading. It is not the same capability, it is narrower, and I would rather say so than sell the narrowness as a feature.

What would make an agentic browser acceptable?

Three properties, none of which depends on the quality of the model.

A strict separation between the agent’s browsing profile and the person’s, so that no sensitive session is reachable from the same window. A visible distinction, in the interface, between what the user asked for and what the agent read along the way, so the trace of an incident is legible afterwards. And human approval on any action that writes outward, whatever trust is placed in the page it came from.

All three are product decisions rather than instructions, and that is what makes them hold. A rule written in natural language is worked around by another sentence in natural language, which is where everything above starts, and the reason a limit that holds is a right never granted rather than a well-drafted instruction.

That leaves the question that comes immediately after, and arises as soon as you plug in anything other than a browser: every integration you add holds credentials and feeds text to the model, which makes it a supplier rather than a connector.