Chrome auto browse is the agent mode of Gemini in Chrome. Google launched it on Jan 28, 2026 as a preview in Chrome desktop for US Google AI Pro and Ultra subscribers, powered by Gemini 3, and brought it to Android in the US in late June 2026. It takes over the user's browser to finish multi-step tasks such as comparing products, building a cart, booking travel or filling an expense report, and it hands control back to the person to pay, accept terms or create an account.
Google caps usage at 20 tasks a day on AI Pro and 200 on Ultra, so each account sends a limited number of tasks, but it ships inside a browser that Google says has 3.8 billion users. In late July 2026 Google also connected its Gemini Spark agent to auto browse, which can use logged-in accounts and saved passwords with the user's permission. That combination of reach and access to real accounts is why fraud and risk teams want to know when it is on their site.
How Chrome auto browse shows up on your site
Auto browse mostly runs in the user's own signed-in Chrome on their desktop or Android phone, with their cookies and IP, and the device has to stay awake while it works. In that mode it sends no agent token and no signature, so a site sees a normal Chrome visit. Google's help page adds that Gemini may switch to a remote browser in the cloud when the device is unavailable, and those tasks pause at sign-in steps.
Google also runs a declared identity for agents on its own infrastructure, called Google-Agent, which it added to its crawler docs on Mar 20, 2026. It carries compatible; Google-Agent in the user agent, comes from IPs in Google's published user-triggered-agents.json list and is part of a Web Bot Auth experiment under the identity agent.bot.goog. Google has not said whether auto browse's cloud browser uses it, which is the most important open question on this page.
| Check | What Chrome auto browse does |
|---|---|
| User agent | Normal Chrome locally; Google-Agent for Google-hosted agents |
| Web Bot Auth signature | None locally; Google-Agent experiments as agent.bot.goog |
| IP ranges | User's own IP locally; Google-Agent list published |
| robots.txt | Google says user-triggered fetchers generally ignore it |
Why Chrome auto browse is hard to detect
In local mode, auto browse is the user's real Chrome on the user's real device, IP and account, so it blends into their own traffic. Nothing in the headers marks the moment Gemini takes over from the person, and no client-side marker has been published, which leaves behavior such as very even timing and a pointer that jumps straight to targets as the only clue.
The cloud path is easier because a declared identity with an IP list exists for it, though only if auto browse actually uses Google-Agent. Google's own design also helps a little, since payment, terms acceptance and account creation are handed back to the person, so those steps are usually human even inside an agent session.
How Verisoul detects Chrome auto browse
When a Google agent runs on Google's cloud, Verisoul names it from its self-declared Google-Agent user agent, then confirms the claim by checking that the source IP belongs to Google's own network and that the device and behavior match a cloud browser. The IP check is what stops a scraper from borrowing the user agent. Local auto browse sessions don't declare anything, so Verisoul flags them through bot score when the input is automated and leaves the agent field empty.
"agent": {
"id": "google_agent",
"name": "Google Agent",
"provider": "Google",
"type": "ai_agent",
"detection_method": "self_declared",
"detection_signals": [
"network",
"behavioral"
]
}idisgoogle_agent, the stable name for Gemini browsing and acting on a site from Google's infrastructuretypeisai_agent, meaning software acting for a persondetection_methodisself_declared, meaning the agent announced itself and Verisoul verified the claimdetection_signalslists a source IP confirmed as Google's own network, a cloud-hosted browser with a virtual machine device profile, and automated clicks, typing and page flow
Across sites that use Verisoul, google_agent made up about 1% of the personal-agent sessions we named between Oct 29 and Nov 1, 2026. That is small next to Meta Muse at 68%, which fits a design where most auto browse runs locally and unnamed. The Agent Atlas entry for Google Agent lists the signals, and the AI agent detection docs cover the response format.
Google Agent was 1% of the personal-agent sessions Verisoul named, Oct 29 to Nov 1, 2026
Share of sessions with a named personal agent on sites that use Verisoul, %. Oct 29 to Nov 1, 2026
How to detect Chrome auto browse step by step
- Add the Verisoul SDK to login, checkout and account pages, following the AI agent detection docs
- Tag sessions where
agent.idisgoogle_agentas verified Google agent traffic - Treat a high bot score with no agent name on a known Chrome user as a likely local agent session
- Review sensitive account changes such as payouts and saved payment methods when either pattern appears
Should you block Chrome auto browse?
Most teams shouldn't. Auto browse works for a paying Google subscriber, and Google requires the person to take over for payment, terms and account creation, so sign-up and checkout already have a human at the critical moment. Browsing and cart building can stay open.
Payouts and account changes are where to look harder, because Google lists mistakes such as buying without permission or wrong quantities, and Gemini Spark can use saved passwords with permission. A high bot score on a known customer at those steps calls for review rather than a block.