Browserbase

Browserbase runs hosted headless browsers for developers' AI agents, along with tools on top such as the Stagehand framework and Director, a no-code product for web tasks. The company was founded in Jan 2024 by Paul Klein IV, launched its platform that year, and raised a $40M Series B led by Notable Capital in Jun 2025. Its homepage says 10,000+ companies build on it, which is a vendor figure, and it is also the browser host underneath many other agents, from Hermes Agent users to demos of the big computer-use models.

Browserbase has also become one of the more visible voices on agent identity. Cloudflare named it in its first cohort of signed agents on Aug 28, 2025, and Cloudflare Radar lists it as a verified agent with an HTTP message signatures directory. On Apr 6, 2026 it launched Agent Identity and Verified sessions with Cloudflare and 1Password, the latter giving agents stored credentials. That makes it one of the few hosted browsers whose traffic can prove where it came from.

Site owners care because Browserbase traffic reaches logged-in flows, ecommerce orders and form-heavy pages, often on behalf of a customer the site has never heard of. Knowing that a session came from Browserbase is useful, while knowing which of its customers sent it is not something any check can tell you. The Perplexity dispute in Aug 2025 showed the problem: after Cloudflare reported that Perplexity was using an undeclared crawler posing as Chrome on macOS, Perplexity said much of that traffic came from Browserbase, which shows how hard unsigned hosted sessions are to attribute.

How Browserbase shows up on your site

Browserbase sessions are Chromium browsers in Browserbase's cloud, driven over the DevTools Protocol by Playwright, Puppeteer or Stagehand. Standard sessions run on Linux, while Verified sessions use a purpose-built Chromium with real fingerprints that defaults to Windows, and customers can add residential or datacenter proxies. Hermes Agent's browser docs describe Browserbase's basic stealth, with random fingerprints and CAPTCHA solving, as always on.

Browserbase's Agent Identity docs describe Web Bot Auth signing as a beta that customers request, even though Cloudflare already treats Browserbase as a signed agent, which means Cloudflare customers can allow or block it by name in their bot settings. A signed request carries Signature-Agent, Signature-Input and Signature headers, and under the IETF Web Bot Auth draft you verify it against the public keys at the signer's /.well-known/http-message-signatures-directory.

Why Browserbase is easy to verify but hard to catch

A signed session is the easiest case on this whole list, because a valid signature is cryptographic proof the request came from Browserbase. The catch is that signing is opt-in, so a missing signature tells you nothing, and most sessions are probably unsigned, signed-agent status or not.

Unsigned sessions are built to blend in, with random fingerprints, CAPTCHA solving and optional residential proxies, so they look like ordinary Chrome. A Linux Chrome whose fingerprint shifts between visits and arrives through proxy IPs is a hint, though not proof. Even when a signature verifies, it identifies the host and covers every Browserbase customer at once, so it tells you nothing about the operator or their intent.

How Verisoul detects Browserbase

Verisoul names Browserbase when the session is signed. We verify the Web Bot Auth signature cryptographically against Browserbase's published key, and we check that the rest of the session agrees: traffic from the provider's cloud data centers, headless or automated browser markers in the device fingerprint, and scripted navigation with no human input. Unsigned Browserbase sessions are flagged through bot score without the Browserbase name.

"agent": {
  "id": "browserbase",
  "name": "Browserbase",
  "provider": "Browserbase",
  "type": "headless_automation",
  "detection_method": "signed",
  "detection_signals": [
    "cryptographic",
    "device",
    "behavioral"
  ]
}

• id is browserbase, the stable key for rules on signed Browserbase sessions
• type is headless_automation, a hosted scripted browser rather than a person
• detection_method is signed, meaning the identity was proven cryptographically, which is the strongest method Verisoul reports
• detection_signals lists cryptographic, network, device and behavioral, so the signature and the session's own evidence line up

See Browserbase in Agent Atlas for the signals, and the AI agent detection docs for the full response.

How to detect Browserbase step by step

1. Add the Verisoul SDK to the flows you care about, following the Verisoul docs
2. Treat browserbase with detection_method signed as verified hosted automation and give it its own rule
3. Send unnamed sessions with a high bot score to your automation policy, since unsigned Browserbase traffic lands there
4. Review signed sessions at sign-up and payouts, because the signature proves the host and not the customer

Should you block Browserbase?

Signed sessions are worth allowing on public pages and on partner integrations you trust, because the operator chose to be identifiable. At sign-up and payouts treat them as automation, and send them to review or block, since one signature covers many unrelated end users.

Ecommerce checkout sits in between. If you sell to businesses that order through agents, a signed session can be a reasonable path to allow, while limited-inventory drops call for the same strictness as sign-up.