Are AI browsers safe to use?

Two very different things are called an AI browser

Most of the confusion in this question comes from one word covering two capability levels with very different risk profiles.

The first is assistive: a sidebar or panel that reads the page you are on and answers questions, summarizes, or explains. The information flow is mostly one way, out of the page and into a model. The main concerns are ordinary ones - what gets sent to a server, what is retained, and what the vendor's data policy says.

The second is agentic: the browser acts. It navigates, clicks, types into forms, and completes multi-step tasks. Crucially, it does this inside the browser session you are already authenticated in, so it inherits your access to email, banking, work systems, and cloud storage. Everything difficult about this question lives in that second mode.

What researchers actually demonstrated

This is not a hypothetical concern, and it is worth stating precisely what was shown rather than paraphrasing headlines.

In August 2025, Brave's security team published an attack against Perplexity's Comet. Instructions were hidden in ordinary web content - white text on a white background, HTML comments, or a comment on a social platform the attacker did not control. When the user clicked summarize, the assistant read those hidden instructions and could not tell them apart from the user's request. The published proof of concept had the assistant read the user's account email, trigger a one-time password through a lookalike domain created by adding a trailing dot, retrieve that code from the user's already logged-in Gmail, and post both back as a public reply.

An October 2025 follow-up widened the picture: instructions hidden inside a screenshot as faint light blue text on yellow were recovered by text recognition and executed, and in another browser simply asking to visit a site was enough to send page content to the model without any explicit summarize request. A 2026 report extended the same failure to a cloud web-automation API and to a fully on-device macOS assistant, showing that running the model locally does not remove the exposure.

Why this is structural, not a bug queue

The reason these reports keep landing is that they all describe the same underlying failure rather than a series of independent mistakes.

An agent receives your instruction and the page's content in the same context window, as one flat stream of tokens. The model has no reliable way to tell which part came from you and which part came from a stranger's webpage, and its willingness to follow instructions is simultaneously the product feature and the attack surface. The obvious mitigation - separate the user's instructions from the page content and treat page content as untrusted - is correct in principle, but as Simon Willison points out, nobody has demonstrated a convincing general method for enforcing that boundary inside a language model.

The consequence is that long-standing web protections stop helping. Same-origin policy and CORS assume the danger is code from one site reaching another. Here the agent is operating with your full privileges across every authenticated session, and the instruction that starts the chain is plain natural language sitting in a comment.

How to decide what to let one do

The useful question is not whether AI browsers are safe in the abstract but what you are willing to hand a system that may follow a stranger's instructions.

The strongest recommendation coming out of this research is separation: agentic capability should be isolated from regular browsing, and you should never end up in agentic mode by accident. That principle translates into practical settings you control today.

• Keep agentic browsing in a separate browser or profile that is not signed into email, banking, health, or work accounts
• Do not invoke summarize or agent actions on pages carrying untrusted user-generated content when you are logged into anything sensitive
• Prefer modes that ask for confirmation before navigating off-site, submitting a form, or making a purchase, and read what is being confirmed
• Treat the assistant reading a page as the trigger, not just the moment you type a command - navigation alone has been enough in at least one tested browser
• Check what browsing memory the product retains and whether you can view, archive, or delete it
• Assume any AI-browser product may change or be discontinued: the ChatGPT Atlas announcement page now carries a deprecation notice

What this answer does not claim

RepoRadar has not tested any of these browsers hands-on, and nothing here is a hands-on result. Every attack described above is attributed to the published research that demonstrated it.

Vulnerability status changes. Vendors ship mitigations, researchers defeat some of them, and specific findings age. Several of the disclosures cited here record exactly that pattern, including fixes that were later bypassed. Do not read a dated disclosure as a statement about a product's current build.

Most of the public research in this area comes from a browser vendor that also builds an agentic feature of its own. The technical demonstrations are concrete and reproducible in their descriptions, but that commercial position is worth knowing when you read the recommendations. This answer also makes no claim about any product's pricing, and it names no vulnerability that a cited source did not publish.

A useful next action

If you already use an AI browser, spend two minutes finding out which mode you are actually in. Check whether the assistant can only read the page or can also navigate and act, and check whether it acts inside your main signed-in profile.

If it can act, create a second profile for it with nothing sensitive signed in, and move your agentic use there. That one change removes the entire class of attack that depends on borrowing your authenticated sessions, and it costs you nothing but a second window.