AI browser agents: what a website can verify

An AI browser agent is a browser that a model drives to finish a user's task: it opens pages, clicks, fills in forms and signs in. Vendors also call these products agentic browsers. What a website can learn about one depends on where the browser runs.

Three of the agents below run in the vendor's cloud. ChatGPT's cloud browser and Google-Agent publish a check, either a signed request or a list of IP ranges. The Manus pages we read describe neither. The other four run inside the user's own browser: Perplexity Comet, Claude in Chrome, Gemini in Chrome and the Manus browser extension. Their requests carry the user's IP address, cookies and browser, and the pages we read describe no signal a website can check. Gemini is a partial exception, because it can move a task to a remote browser.

Agent	Where the browser runs	What the site receives	Published check
ChatGPT cloud browser (ChatGPT Work)	OpenAI's cloud	Requests signed with Web Bot Auth as `https://chatgpt.com`	Verify the signature against OpenAI's key directory
Google-Agent	Google infrastructure	A `Google-Agent` user agent; some requests signed as `https://agent.bot.goog`	Google's `user-triggered-agents.json` ranges, and the signature when present
Manus Cloud Browser	Manus's cloud	Requests from data center IP addresses	None in the Manus pages we read
Perplexity Comet	The user's device	The user's browser, session and IP address	None described in the court opinion or Perplexity's post
Claude in Chrome	The user's Chrome	The user's tabs, sign-ins and IP address	None in the Anthropic pages we read
Gemini in Chrome (auto browse)	The user's Chrome, or a remote browser when the device is unavailable	A tab in the user's Chrome; the help page does not describe the remote browser's requests	None in the Google help page we read
Manus Browser Operator	The user's Chrome or Edge	The user's logins, sessions and local IP address	None in the Manus pages we read

Six rows were checked against the vendor's own documentation on October 11, 2026. The Comet row rests on a court's description of the product. OpenAI alone has withdrawn three agent products, so recheck a row before you build a rule on it.

Agents that run in the vendor's cloud

A cloud agent's browser sits on the vendor's computers. Requests reach you from the vendor's network, and the vendor can attach proof of where they came from.

ChatGPT's cloud browser

Two earlier OpenAI agents are gone. The help page for ChatGPT agent now says "ChatGPT agent is no longer available" and sends readers to ChatGPT Work. The same page says Operator was folded into agent mode: "The Operator website is no longer accessible."

The agent that browses for ChatGPT Work today is its cloud browser. OpenAI's cloud browser page says it "gives ChatGPT Work its own browser on a separate computer in the cloud." It keeps its own cookies and sessions and "does not use your personal browser's open tabs, browsing history, saved passwords, cookies, extensions, or existing sign-ins."

OpenAI's two pages disagree about sign-in. The cloud browser page describes a form that sends the user's password to the remote browser and a session that stays signed in for later tasks. The allowlisting page says "at launch, Cloud browser cannot sign in to websites or complete payments." We would plan for sign-ins. One would arrive from OpenAI's network, on a browser your site has not seen.

The allowlisting page names no user-agent token for the cloud browser. It identifies the traffic by signature: "ChatGPT Work's Cloud browser uses Web Bot Auth to sign outbound HTTP requests, allowing website operators to verify that requests genuinely originate from ChatGPT." Each request carries three headers:

Signature: ...
Signature-Input: ...
Signature-Agent: "https://chatgpt.com"

The public keys are at https://chatgpt.com/.well-known/http-message-signatures-directory. We fetched that address on October 11, 2026. It returned one Ed25519 key whose exp field was October 18, 2026, so a verifier has to refetch the directory and cannot pin the key. OpenAI's instruction for a CDN it does not list is to check that Signature-Agent matches "https://chatgpt.com" "including the quotation marks", verify the other two headers under RFC 9421, and allow the request only after the signature verifies.

Vendors still file this traffic under the retired names. OpenAI lists it as "ChatGPT Agent" in Akamai and HUMAN, as bot tag chatgpt-agent in Cloudflare (found by searching for "ChatGPT Operator"), and as chatgpt-operator in Vercel. A search for "cloud browser" in those consoles may find nothing.

When real cloud browser traffic is blocked, OpenAI's first troubleshooting step is to "confirm that intermediate proxies preserve" the three signature headers. A proxy that drops unknown headers turns a verifiable request into an anonymous one.

Google-Agent

Google lists Google-Agent among its user-triggered fetchers: it "is used by agents hosted on Google infrastructure to navigate the web and perform actions upon user request." The desktop user agent is:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko; compatible; Google-Agent; +https://developers.google.com/crawling/docs/crawlers-fetchers/google-agent) Chrome/W.X.Y.Z Safari/537.36

Google also lists a mobile string with the same Google-Agent token. The page says user-triggered fetchers "generally ignore robots.txt rules" and carries a caution: "The user agent string can be spoofed." So check the source address against the ranges in user-triggered-agents.json.

Google also signs part of this traffic. Its Web Bot Auth page calls the work experimental: "A subset of requests made by the Google-Agent are signed with Web Bot Auth," with Signature-Agent set to g="https://agent.bot.goog". Google tells sites to keep the address check as well, "as not all requests are signed."

OpenAI's page shows the header as a bare quoted string. Google's shows a labeled member, g="...". The IETF draft requires the labeled form from signers ("Signers MUST send the dictionary form"). Of the older string form it says that "deployments still send it" and that a verifier "MAY accept that form" as a dictionary with one member. To verify both vendors as their pages stand, a verifier has to parse both.

Manus Cloud Browser

Manus documents where its Cloud Browser connects from: it "operates from data center IP addresses, not residential IPs." The page tells users to expect more CAPTCHAs and security checks as a result. When one appears, Manus prompts the user to "Take Over" the browser, solve it, and hand control back. A site that challenges this browser should expect a person to solve the challenge and the agent to carry on.

Agents that run in the user's own browser

An in-browser agent has no network of its own. The user's browser loads each page and sends each request, so the site sees the customer's usual device, address and session cookie.

OpenAI shipped a browser of this kind, Atlas, in October 2025. The announcement now carries the note "Atlas has since been deprecated."

Perplexity Comet

A court opinion describes how Comet works. In Amazon.com Services v. Perplexity AI, decided on August 4, 2026, the Ninth Circuit described Comet as "a web browser that operates like Google Chrome, running locally on a user's machine and enabling the user to navigate the Internet." When a user sends the assistant to Amazon, it "takes screenshots of the browser view, sends those screenshots from the user's computer to Perplexity's servers," and gets instructions back.

On identification the opinion says: "At the core of the dispute was Perplexity's decision not to use a 'user-agent string,' a mechanism 'that would communicate that the user has activated an AI agent.'" A footnote adds that the parties dispute whether Perplexity "knowingly altered the Assistant's user-agent string" after Amazon first identified and blocked the Assistant. So the agent could be told apart at one point, and the opinion does not say whether it still can. Perplexity had stated its position in a blog post when the dispute began: "Your AI assistant must be indistinguishable from you."

The court vacated the preliminary injunction that Amazon had won and sent the case back to the district court. Its conclusion gives two reasons. Amazon "is unlikely to succeed on the merits of the 'access' prong of the CFAA and CDAFA analysis" (the federal and California computer-access statutes), and "the equitable factors do not otherwise strongly favor an injunction" either. On access the panel wrote, "It is the user who 'accesses' Amazon's computers, with the help of the Assistant to carry out specific acts on Amazon.com." It limited the holding to that question and that record: "We do not establish a new legal regime governing agentic AI." This article describes the ruling and gives no legal advice.

Claude in Chrome

Claude in Chrome is a browser extension. Anthropic's desktop documentation says it "lets Claude work in the user's own Google Chrome or Microsoft Edge, with the tabs and sign-ins the user already has there." The setup page names Chrome only and says other Chromium browsers are not supported. It lists the extension's permissions: the debugger permission "is what allows Claude to actually control your browser – clicking buttons, typing text, and taking screenshots – when you ask it to complete tasks for you."

The controls Anthropic documents belong to the user's side. Claude cannot open some site categories, it "asks for permission before accessing financial sites," and an organization's admin can set an allowlist or a blocklist of sites (safety page). None of the three pages describes a header, a user-agent token or an opt-out for the website being visited.

Gemini in Chrome

The auto browse help page describes a task that runs in a tab of the user's Chrome: "While Gemini in Chrome is performing the task, there's an auto browse icon on the tab that it's using." It tells the user: "You're responsible for Gemini's actions during a task, including mistakes and unexpected results like purchases."

The task does not always stay on the user's device. The same page says Gemini Spark, the agent that uses auto browse, "might also use a remote browser (which is a separate, new browser instance, not your local browser in the cloud)," for example when the user closes the device before the task is finished. The page names no user agent and no IP range for either mode, and it does not say whether the remote browser sends Google-Agent.

Manus Browser Operator

Manus ships the same idea as an extension for Chrome and Edge. Its Browser Operator page says the agent works in the user's browser "complete with your existing logins, sessions, and local IP address," and states the consequence for the site: "Because the activity appears legitimate to websites, it clears standard access barriers automatically and maintains active sessions." The Cloud Browser page lists "Website blocks data center IPs" among the reasons to switch to this mode.

What a signature proves

Web Bot Auth is HTTP Message Signatures (RFC 9421) applied to automated clients. The working-group draft dated September 1, 2026 defines the Signature-Agent header, a key directory in JWKS format and the well-known address that serves it. Its authors work at Cloudflare and Google, and its header gives the intended status as Standards Track. It is still a draft and expires on March 5, 2027.

The draft states the limit of a valid signature. It "proves that a holder of a key that URL publishes signed the covered message." It "says nothing about who operates the Agent, whether the Agent is benign, or whether the request is authorized. Those are origin policy." A signature under https://chatgpt.com shows that the request was signed with a key chatgpt.com publishes. Which user sent the agent, and whether that user may take the action, are questions your own login and permission checks have to answer.

Signing is voluntary, and the draft says so: "If an agent wishes not to identify itself, this is not the right choice of protocol for it." An unsigned request therefore tells you nothing about whether an agent sent it.

Few sites need to write the verifier themselves. OpenAI's page gives steps for Akamai, Cloudflare, HUMAN and Vercel. Google's page says: "Major bot-detection services, CDNs, and WAFs support Web Bot Auth." How to verify AI agents covers the address checks and the identity results to record.

Set policy by what you can verify

What arrives	What you can establish	A starting rule
A signed request that verifies, or a `Google-Agent` request from a published range	The vendor's signing domain or network	Apply the rule you chose for that vendor on that route. Login, checkout and account changes still go through normal authorization.
A `Google-Agent` user agent from another address with no valid signature, or a signature that fails	Nothing; the claim is unverified	Do not apply the vendor's allow rule. Before you call it a false claim, confirm that you compared the client's address and not your CDN's, that your copy of the range file is current, and that no proxy changed the signed headers.
A browser from a data center address with no identity	Only that the address is hosted. Corporate VPN and cloud desktop users match too.	Use your default policy for hosted automation.
A signed-in session that an agent may be driving	Only the customer	Apply the same rule to every session: per-account limits, and a confirmation step on purchases, exports and credential changes.

Evidence in the browser can sometimes show that software is driving a session, and How to detect browser automation covers what that evidence supports. It does not name the product, and blocking the session blocks a signed-in customer. Decide which actions you are willing to let software take for a customer, and enforce that at the action.

How to control AI agent access has the full policy model, and What is agentic traffic? explains how these sessions differ from crawlers and fetchers.

Check your own traffic

Three checks need only your edge logs.

Log the Signature-Agent request header and count requests by its value. In nginx a request header is a variable, here $http_signature_agent:

log_format agents '$remote_addr "$http_user_agent" '
'"$http_signature_agent" $status $request_uri';
access_log /var/log/nginx/agents.log agents;

Behind a CDN, $remote_addr is the CDN's address. Log the client address your CDN passes on instead. nginx escapes quotation marks in a logged value as \x22, so OpenAI's header appears as \x22https://chatgpt.com\x22. 2. Search the user agent field for Google-Agent and compare the client addresses with user-triggered-agents.json. 3. Send a request with test signature headers through your CDN and look for all three in the origin log. A CDN that verifies signatures may reject the test request, which also tells you who is checking:

curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/ \
-H 'Signature-Agent: "https://signer.example"' \
-H 'Signature-Input: sig1=("@authority" "signature-agent");created=1700000000;tag="web-bot-auth"' \
-H 'Signature: sig1=:AA==:'

If a bot management product sits in front of the site, look up its entries for the names in the ChatGPT section and see how each is set. OpenAI notes that on Vercel "no additional configuration is required to allow Cloud browser traffic," so the current setting may be one that nobody on your team chose.

Questions for a bot management vendor

Ask any vendor, Centinel included, three things about the agents on this page: which signed agents the product verifies, how it treats a request whose signature fails, and what it reports for a browser session whose vendor cannot be established. Centinel is bot management for websites and applications, and the bot management guide has the full evaluation checklist.

Declared crawlers are a separate question from browser agents. The bot directory lists what each crawler operator publishes, and the crawler IP checker tests one address against it.