Perplexity’s Comet puts an AI agent inside the browser, and that changes the threat model

Perplexity has launched Comet, a Chromium-based browser that makes its AI search engine the default and adds a built-in agent called Comet Assistant. It’s rolling out first to invitees and subscribers on Perplexity’s $200-a-month Max plan.

The important part is where Perplexity puts the AI.

Comet folds search, page context, tab state, and app access into the browser itself. If Perplexity can make that reliable, it has something distinct from a browser with a chatbot bolted on. If not, Comet starts to look like an expensive demo with a long list of permissions.

Why it matters

Browsers have always had the best vantage point in consumer computing. They see where you go, what you read, what you click, and more and more of the work you do. Search companies know that. AI companies do too.

Google is weaving Gemini into Chrome. The Browser Company is pushing Dia. Apple is reportedly heading in a similar direction with Safari. Perplexity is taking a harder line than most. The product assumes people want an agent moving with them across the web, not a model waiting in a separate box.

That raises both the ambition and the engineering burden.

A browser-native agent can summarize the page you’re on, compare it with other tabs, pull details from your calendar, draft an email, and take action on a site. That’s a strong pitch. It also requires deep browser access and broad access to external services. The useful parts and the risky parts come from the same place.

Chromium plus an AI sidecar

Comet is built on Chromium, which is the sensible choice. Building a rendering engine from scratch in 2025 would be a waste of time and money. Chromium gives Perplexity site compatibility, a familiar extension model, and room to focus on the AI layer instead of layout bugs.

That AI layer is the interesting part.

According to the reference details, Comet adds browser hooks for AI-specific functions, including a cometAI.* namespace and a sidecar UI injected into pages through content scripts. That sidecar can capture DOM snapshots, inspect open tabs, and send context back to Perplexity’s backend so the assistant can answer questions or act on the user’s behalf.

The architecture is easy to understand, and expensive to run.

DOM capture plus server-side reasoning is the obvious way to make an assistant page-aware across arbitrary websites. It’s also messy in practice. Modern pages are bloated, dynamic, and full of junk the model doesn’t need. Client-side frameworks keep changing the DOM underneath you. If Comet is shipping large or frequent page snapshots back to the backend, bandwidth and latency will get ugly fast.

Anyone who has built browser agents has seen the same pipeline:

• grab page structure
• strip noise
• infer intent
• send compact context to a model
• hope the page doesn’t change before the action fires

The hard part is the open web. Demos on Gmail or a travel site are easy enough. Real reliability is harder.

Extending Perplexity’s search model into the browser

Comet’s default search experience is standard Perplexity: retrieval-heavy, summary-first, and designed to keep users inside an answer flow instead of bouncing across ten blue links. Put that inside the browser and Perplexity gets direct access to query intent and browsing behavior without waiting for people to visit perplexity.com.

That matters because search distribution has always mattered. Google paid to be the default for a reason. Defaults shape habits. Perplexity is trying to build its own default environment.

On the technical side, the search stack described here looks like familiar RAG. Web content gets chunked and embedded into a vector index. The model retrieves top results, mixes in structured facts, and generates a synthesized answer. None of that is unusual. The hard parts are latency, ranking, source handling, and whether the model knows when it should stop guessing.

The browser gives Perplexity one extra advantage: session context. If the assistant knows what pages you opened, what you searched a few minutes ago, and what task you’re working through, it can outperform stateless search. It can also get invasive pretty quickly.

Perplexity reportedly keeps an ephemeral backend session for browsing history and assistant interactions. “Ephemeral” sounds nice, but engineers will care about the details:

• how long is session data retained?
• what gets logged for debugging?
• what’s stored separately from model prompts?
• can enterprise users disable backend retention entirely?
• how is sensitive tab data segmented across accounts and devices?

If the browser becomes an AI execution layer, session handling is part of the security model.

Permissions are where the pitch gets shaky

Comet Assistant can summarize email, manage calendars, and complete tasks on websites. To do that, it asks for broad OAuth scopes, including access to Gmail and Google Calendar, plus page-level inspection and screen capture.

That changes the risk profile.

A regular browser already sees a lot. An AI browser that reads your inbox and edits your calendar moves into a different category. The risk is no longer just tracking or personalization. It includes unauthorized actions, accidental disclosure, prompt injection through web content, and users having a fuzzy idea of what the system can access at any given moment.

Perplexity says data is encrypted in transit with TLS 1.3 and at rest with AES-256. Fine. That’s baseline. It does not answer the harder question, which is whether the browser should have these permissions at all and how tightly they’re scoped.

For teams building similar systems, the checklist is pretty clear:

• split read and write access wherever possible
• use incremental auth instead of asking for everything up front
• require explicit confirmation for sensitive actions
• keep audit logs for actions taken by the agent
• expire tokens aggressively
• treat webpage content as hostile input

That last one matters because browser agents live in a constant prompt-injection environment. A malicious page can hide instructions in the DOM, manipulate visible text, or construct flows that push the model toward unsafe actions. If your agent can read the page and act in external systems, every site is part of your attack surface.

Strong idea, familiar failure modes

There’s a reason companies keep coming back to this category.

The browser is where search, apps, documents, and transactions all meet. A capable assistant there could save real time. Summarizing a long thread, checking dates across tabs, filling repetitive forms, pulling product specs from three vendor pages, drafting a response based on what’s already open. Those are solid use cases.

But AI agents still stumble on the last mile. They click the wrong button. They misread half-rendered interfaces. They get tripped up by anti-bot UI patterns. The wider the access, the more expensive those mistakes get.

That’s why the AI browser category feels promising and early at the same time. The capability is good enough that these products are worth shipping. Reliability still trails the pitch by a wide margin.

What developers and platform teams should watch

Comet is also a warning for web app teams.

If browser agents become common, apps will need cleaner surfaces for machines to read and act on. That probably means better semantic structure, more stable identifiers, and APIs that expose task-specific actions without forcing a model to scrape brittle interfaces and click through them.

There’s also a standards problem. If every browser invents its own agent bridge, developers get the same fragmentation they already deal with in extension ecosystems, except the stakes are higher. Some common model for agent-to-browser permissions and action APIs would help. W3C-style standardization is the obvious place for that, though standards usually arrive after vendors have already shipped incompatible systems.

For internal tooling teams, Comet is still a useful architecture sketch even if you’d never deploy it broadly:

• local preprocessing to reduce DOM payloads
• tiered retrieval so not every page hit goes to a cloud model
• short-lived session memory instead of indefinite chat history
• strict separation between observation and action modes

That distinction matters. A browser assistant that can read needs one set of controls. A browser assistant that can transact needs a much stricter one.

The browser is turning into an agent host

Comet doesn’t need to dent Chrome’s market share to matter. It only needs to show that enough people want a browser organized around AI mediation instead of tabs and search boxes. If that happens, incumbents will copy whatever works and quietly sand down the rest.

Perplexity is early. Maybe too early. The direction still looks plausible.

The hard part is trust. A browser that sees everything and can act on your behalf needs much better permission design than most AI products currently offer. Without that, the most interesting thing about Comet may also be the thing that keeps people from using it.