Agentic Browsers Under Fire: Comet, Atlas, and the Prompt Injection Problem

A conventional browser renders whatever a page contains and waits for a human to read it and decide what to do next. A chatbot answers questions inside a context window that, in the ordinary case, holds only what the user typed or pasted in. An agentic browser like Comet or Atlas is neither. It is given a goal in natural language, summarize this page, find me the cheapest flight and book it, check my inbox for anything urgent, and it then autonomously fetches web content, reads it, and takes actions: clicking links, filling out forms, submitting purchases, reading authenticated email, inside the same session a human is logged into.

The security-relevant difference is where the agent's next instruction comes from. In a chatbot, the only text competing for the model's attention is what the user supplied. In an agentic browser, the model's context window holds the user's original request and the full text of whatever page the agent just fetched, side by side, with no reliable architectural boundary telling the model which one is the trusted command and which one is just page content it was asked to describe. That is the structural opening the entire category of attack below depends on.

Direct prompt injection is the classic case: the attacker is the user, typing a jailbreak or an adversarial instruction straight into the model to get it to ignore its own guardrails. It is a real risk, but it is a known one, and it is the same risk a chatbot already carries.

Indirect prompt injection is the mechanism specific to a browsing agent, and it is what both the Comet and Atlas disclosures below are built on. The attacker never talks to the model directly. Instead, they plant an instruction inside content the agent will eventually read on the user's behalf: invisible text on a webpage, a comment hidden in a shared document, text disguised inside a URL the agent's address bar parses. When the agent later processes that page as part of an innocuous task like summarizing it, the model has no reliable way to tell that the instruction it just read (forward the contents of this inbox to this address) came from an attacker's page rather than from the user who asked for the summary. It just sees text sitting in its context window and, in enough documented cases, acts on it.

This is meaningfully different from a classic web attack like cross-site scripting. XSS needs an actual code-execution flaw in the target site. Indirect prompt injection needs no code-execution vulnerability at all; it only needs the agent to read the wrong page while it happens to be sitting on top of a live, authenticated session. The vulnerability lives in the agent's judgment, not in the site being visited, which is exactly why it isn't caught by the web security controls a site owner already runs.

This is not a hypothetical. Security researchers at Brave found and disclosed a working indirect prompt injection against Perplexity's Comet browser in mid-2025. When a user asked Comet to summarize a webpage, Comet fed part of that page directly to its underlying model without separating the user's instruction from the page's own content. Brave demonstrated that an attacker could hide instructions in text a human would never notice, light text on a matching background, or content buried in HTML comments, and have Comet execute the hidden command as if the user had asked for it, including retrieving one-time passcodes from an authenticated email account and reaching into banking sessions.

Brave reported the flaw to Perplexity on July 25, 2025. Perplexity acknowledged it and shipped a fix two days later, but Brave's retesting on July 28 found the fix incomplete. Brave gave a further one-week disclosure notice on August 11, and by the time it published full details on August 20, its own note on that post says renewed testing found Perplexity still had not fully mitigated the underlying issue. Two months later, on October 21, 2025, Brave published a follow-up showing the same category of flaw was not unique to Comet: instructions rendered in colors calibrated to be unreadable to a human eye but legible to the vision model reading a screenshot worked against multiple AI browsers, which Brave characterized as a systemic problem across the category rather than a single vendor's bug.

OpenAI's ChatGPT Atlas ran into the same category of problem within hours of its October 2025 launch, when researchers showed that carefully worded content inside a shared Google Doc could steer the agent's behavior. Days later, a separate security firm reported a flaw in how Atlas's own address bar interpreted disguised URL-like text as executable instructions. OpenAI subsequently shipped a security update built on an adversarially trained model and what it described as strengthened safeguards, following its own internal automated red-teaming. Its chief information security officer put the honest version of the finding directly, describing prompt injection as a frontier and unsolved security problem.

Neither vendor claims to have solved the underlying problem, and the mitigations that have shipped are best read as harm reduction around an unresolved architectural issue, not a fix to it.

OpenAI's public mitigations for Atlas center on limiting what an agent can reach and forcing a human back into the loop at the moments that matter most. A logged-out mode keeps the agent from carrying an authenticated session into a browsing task that doesn't need one. A watch-style mode requires the user to keep the relevant tab active while the agent operates on a site OpenAI considers sensitive, and pauses the agent if the user looks away. Confirmation prompts are meant to interrupt the agent before it completes a consequential action, such as a purchase or sending an email, rather than letting it complete the action silently. OpenAI has paired those user-facing controls with an adversarially trained model and continuous red-teaming aimed at catching new injection patterns before they reach production.

Perplexity's response to the Comet disclosure was iterative patching rather than a published mitigation framework: acknowledge, patch, get retested, patch again. Brave's own account of that process, that its retesting kept finding the fix incomplete across multiple rounds, is the clearest public evidence that this specific class of flaw is genuinely hard to close with a single patch, since the underlying cause, that the model can't reliably tell trusted instructions from untrusted page content, is not something one fix removes.

Neither of these tools was withdrawn from the market over these findings, and neither vendor has said the problem is closed. That combination, real documented exploitation, real vendor-shipped mitigations, and an honest admission the mitigations aren't a full fix, is the actual state a security posture has to work from.

The mechanics described above are not fixed by any patch shipped as of this writing. Brave's own findings show a boundary between trusted instructions and untrusted page content that isn't reliably drawn inside the model's context window today, and the same category of flaw reappeared in different agentic browsers after the first disclosure went public. OpenAI has said as much itself, comparing prompt injection to scams and social engineering: a persistent, human-facing risk that gets mitigated and managed rather than eliminated outright.

That means the honest practitioner answer isn't that logged-out mode makes you safe. It's that agentic browsing is a genuinely new attack surface with partial, evolving mitigations, and any deployment decision, personal or enterprise, should be made on that basis rather than on the assumption that a confirmation prompt or an adversarially trained model has closed the gap.