Chrome’s Auto Browse: What Google’s Agentic AI Browsing Mode Actually Sees and Shares

Google began rolling out Auto Browse to Chrome on January 29, 2026, as a preview for paid AI Pro and AI Ultra subscribers. The demos are about capability — fill this form, compare these listings, plan this itinerary. The question that determines whether you should turn it on is narrower and much less discussed: when the agent is driving, what leaves your machine, where does it go, and how long does it stay there?

What Auto Browse Is, Precisely

Auto Browse is built on Gemini 3 models, with an architecture descended from Google’s earlier Project Mariner work. When you start a task, Chrome spawns dedicated tabs marked with an animated AI indicator. Inside those tabs the agent navigates, follows links, and interacts with form fields using simulated keyboard and mouse input — it is driving a real browser session, not calling an API behind the scenes.

Usage is metered. Reporting at launch put AI Pro at up to 20 browsing tasks per day and AI Ultra at 200 daily sessions. Users can also switch to a higher-fidelity Gemini Pro path for visually complex tasks.

That “driving a real browser session” detail is the whole privacy story in one sentence. An agent that operates your browser operates it with your browser’s state — your cookies, your logged-in sessions, whatever a page renders once you are authenticated to it.

The Data Path: Nothing Runs Locally

Auto Browse is cloud-dependent. The reasoning does not happen on your device; content from the AI-operated tabs is processed on Google’s servers, and interactions are streamed there.

For anyone evaluating this against a privacy threat model, that is the load-bearing fact. If the agent opens a tab, the contents of that tab are being sent off-device. That includes pages you reached because you were already signed in — a banking dashboard, a patient portal, an HR system, a document in a corporate drive. The agent does not distinguish “page the user considers sensitive” from “page the user considers routine.” It sends what it needs to see in order to act.

This is a different exposure profile from the one most users have internalized about Chrome. Ordinary browsing sends page requests to the sites you visit and, depending on your settings, sends URLs and telemetry to Google. Agentic browsing sends page content from authenticated sessions to a model provider for processing. Those are not the same transaction, and a user’s existing comfort with the first does not transfer to the second.

What Gets Retained, and the Question Google Hasn’t Answered

Page content encountered during agent sessions may be temporarily logged to the user’s account and retained in Gemini Apps Activity, subject to that account’s privacy settings. Google’s general position is that data is encrypted in transit and at rest and is not sold to third parties.

What has not been confirmed is whether content accessed during Auto Browse sessions is used to train future models. That is the question most worth asking, because it is the difference between a transient processing step and a durable corpus. Until it is answered explicitly, the conservative reading is the correct one for any content you would not paste into a chat window.

Practical consequence: if you use Auto Browse, your Gemini Apps Activity settings are now a browsing-privacy control, not just a chat-history control. That is an unintuitive place for it to live, and it is worth checking rather than assuming a default.

The Confirmation Gate Is Narrower Than It Sounds

Auto Browse pauses for explicit user confirmation on high-stakes steps — logins, checkout, subscription changes — and reporting at launch indicated it stops before final checkout and will not submit payment information without confirmation.

This is a real safeguard and it addresses a real class of harm. It also addresses a narrow one. The gate covers transactional actions: spending money, changing an account. It does not gate reading. An agent that never submits a single form has already transmitted everything it read on the way there. If your concern is unauthorized purchases, the gate is well-placed. If your concern is data exposure, the gate is upstream of nothing that matters.

The Same-Origin Problem

In June 2026, University of Washington researchers published findings from a study of seven agentic AI browsers. Four of them — including Chrome with Gemini, Claude for Chrome, Perplexity Comet, and ChatGPT Atlas — created conditions that undermine the same-origin policy, the rule that has kept one site from reading another’s data since 1995. The work was presented in April at the Agents in the Wild Workshop in Rio de Janeiro.

The mechanism is prompt injection. A malicious page can carry instructions — potentially hidden in markup rather than visible text — aimed at the agent rather than the user. The researchers demonstrated a working proof of concept against ChatGPT Atlas in which an embedded site extracted information from the page embedding it, the rough equivalent of an ad on a webmail page reading the mail.

The reason the same-origin policy does not stop this is structural, not a bug in any one product. Same-origin isolates code running in one origin from data in another. The agent is not code running in an origin; it is a privileged reader sitting above all of them, holding the union of everything the user can see. Instructions that reach it from any page can, in principle, act on data from any other. David Kohlbrenner, one of the study’s senior authors, put the conclusion bluntly: browser agents are not ready for the public. His colleague Franziska Roesner characterized the situation as a significant regression after three decades of browser-security progress.

The browsers that granted their agents fewer permissions generally fared better — which is the actionable finding. Permission scope, not vendor, is the variable that moved the outcome.

Where This Nets Out

Threat models differ, so the recommendation should too.

If you are using Auto Browse on public, unauthenticated pages — comparing product specs, gathering listings, reading documentation — the exposure is mostly the content of pages anyone could fetch, and the convenience trade is defensible. Keep it there.

If you are signed into anything you would not forward to a third party, do not hand that session to the agent. Not because Google is acting in bad faith, but because the architecture sends page content off-device by design, the retention question is unresolved, and the current research says a hostile page can address the agent directly. Running agent tasks in a separate browser profile with no sensitive logins is the cheap structural mitigation, and it is more reliable than remembering to be careful.

For enterprise and regulated environments, the assessment is simpler: an authenticated-session reader that streams page content to a third-party model with unconfirmed training use is a data-processing decision, not a browser-feature decision, and it belongs in front of whoever owns that call.