Hyperbrowser

Hyperbrowser is a San Francisco Y Combinator company, founded by Akshay Shekhawat and Shri Sukhani, that sells cloud browsers, sandboxes and web data APIs for AI agents. Developers use it to run their own scrapers and agents, or to host runs of HyperAgent, Browser Use or computer-use models in managed browsers. Its homepage says it has run 100M+ browser sessions, which is a vendor figure, and its YC profile lists a team of four.

It sells to the same developers as the other hosted browsers, with a free tier of 5,000 credits, a Startup plan at $30 a month, Scale at $100 a month and custom plans. The newest piece is identity. On Oct 14, 2026 Hyperbrowser added an opt-in Web Bot Auth option to its Node and Python SDKs, so customers can now sign their sessions. That puts it about a year behind Browserbase and Anchor, which Cloudflare named in its first cohort of signed agents in Aug 2025.

Site owners see Hyperbrowser on scraped content, logged-in workflows that use saved browser profiles, and anything an AI agent is pointed at. Its stealth docs describe anti-detection techniques for getting past bot protection, so signing and stealth sit side by side in the same product.

How Hyperbrowser shows up on your site

Hyperbrowser sessions are cloud-hosted Chrome, controlled through Playwright or Puppeteer and started in under 500 ms. Session options include stealth mode, an enterprise-only Ultra Stealth mode, proxies with country, state and city targeting, static IPs and CAPTCHA solving. Default sessions without stealth show standard headless and DevTools markers and a 1280x720 screen.

Per its Web Bot Auth docs, a signed session sends Signature-Agent: "https://www.hyperbrowser.ai", signs with Ed25519, and publishes its keys at /.well-known/http-message-signatures-directory. Signing is enabled per team on request and switched on per session. Signed requests usually carry a standard browser user agent, so the signature is the only declaration.

Why Hyperbrowser is only sometimes easy to detect

When a session is signed, detection is a solved problem, because you can check the signature against a published key. The rest of Hyperbrowser's traffic depends on settings. A default session without stealth leaves headless markers and a fixed 1280x720 screen, which most automation checks catch.

The hard part is a design choice in the product. Hyperbrowser's docs say signing cannot be combined with Ultra Stealth, so the customers who choose the strongest stealth are by definition unsigned. Their sessions hide the headless markers and arrive through geo-targeted proxies, which leaves behavior as the main tell.

How Verisoul detects Hyperbrowser

Verisoul names Hyperbrowser when the session is signed. We verify the Web Bot Auth signature against Hyperbrowser's published key and confirm the rest of the session fits: 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 sessions, including Ultra Stealth, are flagged through bot score without the Hyperbrowser name.

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

• id is hyperbrowser, the key you write rules against
• type is headless_automation, a hosted scripted browser
• detection_method is signed, meaning the identity was proven cryptographically
• detection_signals lists cryptographic, network, device and behavioral, the signature plus the evidence that agrees with it

Hyperbrowser's Agent Atlas entry lists these signals, and the AI agent detection docs cover the response format.

How to detect Hyperbrowser step by step

1. Add the Verisoul SDK to sign-up, login and payout pages using the Verisoul docs
2. Give hyperbrowser with detection_method signed its own rule, separate from unknown automation
3. Use bot score for unsigned sessions, which is where Ultra Stealth traffic lands
4. Review signed sessions at sign-up and payouts, because the signature identifies Hyperbrowser and not its customer

Should you block Hyperbrowser?

A signed Hyperbrowser session is honest about being automation, which makes it reasonable to allow on public pages and on integrations you approve. It does not tell you who is behind it, so block or review it at sign-up, login and payouts.

Do not lean on IP rules. Hyperbrowser publishes no ranges and sells proxies down to city level plus static IPs, so any list you build will be out of date quickly.