Comet and the agentic browser problem

What Brave found

On August 20 Artem Chaikin and Shivan Kaul Sahib of Brave's security team published a proof of concept against Comet, Perplexity's browser with a built-in assistant that can browse and complete tasks on a user's behalf. The attack needs no exploit in the usual sense. It needs a web page with some text on it and a user who clicks the button that says summarise this page.

Their demonstration used a Reddit comment with the malicious instructions hidden inside a spoiler tag, so a person reading the thread would not see them. When the user asked Comet to summarise the page, the assistant fed the page content to its model along with the request. The model could not tell which words were the user's instruction and which were the page, and it followed the page. Brave's phrasing is that the assistant treats everything as user requests.

The instructions told Comet to open the user's Perplexity account settings and read their email address, then attempt a login on a spoofed domain that used a trailing dot to slip past authentication, then go to the user's Gmail inbox and read the one-time password that arrived, then post both the email and the code as a reply to the original Reddit comment. The attacker reads the reply. No further click from the user is needed. That is an account takeover initiated by a summarise button.

Why a browser is the worst case

Prompt injection through retrieved content has been known since the first chat assistants got web access. What makes Comet different is that all three ingredients of a damaging injection are present at once and by design. There is private data, because the browser is logged into everything the user is logged into. There is untrusted content, because the entire web is untrusted content. And there is the ability to act, because acting is the product. A browser agent is that combination with a consumer interface on it.

Compare this with a coding agent. A coding agent reads files in a repository and runs commands in a sandbox. The content is semi-trusted, the data is mostly the repository, and the actions are usually reversible. A browser agent reads arbitrary pages, has the user's sessions for their bank, their email and their employer, and performs irreversible actions like sending messages and submitting forms. There is no sandbox because the point is to act in the user's real world.

The Comet chain also shows why the usual web security model does not help. Same-origin policy stops a Reddit page from reading your Gmail. It does nothing to stop an assistant that has legitimate access to both from carrying text from one to the other. As Brave puts it, traditional web security assumptions do not hold for agentic AI. The browser's own defences were built against code, and the attack here is prose.

What the vendors tried

Brave reported the issue to Perplexity on July 25. Perplexity acknowledged it and shipped an initial fix on July 27. On July 28 Brave retested and found the fix incomplete. On August 11 Brave gave one week's notice of public disclosure. On August 13 further testing suggested the issue had been patched, and Brave published on the 20th. An update appended to the post says Perplexity had still not fully mitigated the attack. So the timeline is a patch, a bypass, a second patch, and a note that the second patch did not fully close it either.

That pattern, fix and bypass, is what you would expect if the mitigation is a filter on the model's input or output. Filters catch the instruction you tested and miss the paraphrase. The blog post does not say what Perplexity changed, and we are not going to speculate about their implementation. What it does say is what Brave thinks the mitigations should be, and that list is the useful part of the disclosure.

The four mitigations

First, separate user instructions from page content when building the request to the model, and treat page content as untrusted no matter where it came from. This is a structural change, since the model has to be given the two streams in a way that it reliably distinguishes, and current models are not reliable at that. It is still the right place to start, because it is the only mitigation that addresses the cause rather than the symptom.

Second, check the model's proposed actions against what the user actually asked. If the request was summarise this page and the plan involves visiting account settings and reading an inbox, something has gone wrong, and a separate check can catch it without understanding the injection. Third, require a user interaction before sensitive operations, meaning sending an email, reading credentials, or ignoring a certificate error. Fourth, isolate agentic browsing from ordinary browsing, so that the assistant does not have the user's full set of sessions unless the user has deliberately handed them over for a task.

The second and third of these are the ones we expect to see adopted first, because they can be bolted on. The first and fourth require rethinking what a browser assistant is allowed to touch by default, and that cuts against the product pitch, which is that the assistant can do anything you can do.

What we think happens next

We do not think this vulnerability class gets fixed in the model. Distinguishing instruction from data is exactly what language models are bad at, and a browser agent is exposed to more adversarial data than any other deployment. The fixes that will hold are the ones that limit what a compromised model can do, which means confirmation prompts for anything with side effects and a hard split between the assistant's session and the user's.

The experiment we would run is simple and we hope Brave or someone else runs it across the category. Take every shipping browser assistant, plant the same hidden instruction on a page, ask for a summary, and record which ones take the bait and which sensitive actions each one gets through before a confirmation. That table would tell users more than any vendor statement, and it would put a number on how far the category has to go before summarise this page is safe to click.