Anchor Browser

Anchor runs managed Chromium cloud browsers for AI agents. Its pitch is that an agent plans a task with AI once and then replays it as deterministic browser code, with built-in authentication for logged-in work. Anchor, led by co-founder and CEO Idan Raman, raised a $6M seed led by Blumberg Capital with Gradient on Oct 22, 2025, and SiliconANGLE reported that Groq runs parallel Anchor browsers for its Compound research agent.

Plans start with a free tier and run through $50, $500 and $2,000 a month tiers to custom enterprise deals, with AWS Marketplace, bring-your-own-cloud and on-prem options. Anchor's OmniConnect authentication and a 1Password partnership let its browsers log in to accounts, which is why it shows up on ticketing, marketplaces, SaaS, fintech and crypto sites, and on anything behind a login.

Anchor is interesting from a detection point of view because it sells both sides at once. Cloudflare named it in its first cohort of signed agents on Aug 28, 2025, when Anchor announced Web Bot Auth signing and support for Cloudflare's Pay Per Crawl, while its homepage describes Anchor Chromium as stealthy and recognized as human, with CAPTCHA bypass on paid plans.

How Anchor Browser shows up on your site

Anchor sessions run Anchor Chromium, its own Chromium fork, in Anchor's cloud or the customer's. Traffic leaves through Anchor's VPN or the customer's own proxies. CAPTCHA bypass comes with the Starter plan, full stealth with Growth and unique fingerprinting with Enterprise. Anchor's docs say Web Bot Auth signing is turned on per session through a web_bot_auth.active setting and is off unless the customer turns it on.

When a session is signed, it carries the standard Web Bot Auth headers, and you verify them against the public keys at the signer's /.well-known/http-message-signatures-directory, as the IETF draft describes. Cloudflare Radar lists Anchor Browser as verified, with a signatures directory and a robots.txt token of Anchor Browser, and oddly files it under AI training crawlers even though it works on tasks its customers direct. Whether that token appears in the User-Agent header is not confirmed.

Why Anchor Browser is hard to detect when unsigned

A signed Anchor session is easy to recognize, because the signature checks out against Anchor's key or it does not. Everything else is harder. Signing is off by default, so most sessions likely carry no declaration, and the browser is built to pass as human, with CAPTCHA bypass and stealth on the higher plans and egress through a VPN or customer proxies rather than a known range.

Anchor's replay model gives one useful tell. A workflow planned once and then replayed as code tends to produce the same request sequence and timing across many sessions, so a cluster of accounts that move through your pages in exactly the same way is worth a look. Even a valid signature only identifies Anchor, not the customer or the task behind the session.

How Verisoul detects Anchor Browser

Verisoul names Anchor Browser when the session is signed. We verify the Web Bot Auth signature against Anchor's published key and confirm 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 Anchor sessions are flagged through bot score without the Anchor name.

"agent": {
  "id": "anchor_browser",
  "name": "Anchor Browser",
  "provider": "Anchor",
  "type": "headless_automation",
  "detection_method": "signed",
  "detection_signals": [
    "cryptographic",
    "device",
    "behavioral"
  ]
}

• id is anchor_browser, the key for rules on signed Anchor sessions
• 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 session evidence behind it

Anchor Browser's Agent Atlas entry lists the signals, and the AI agent detection docs describe the full response.

How to detect Anchor Browser step by step

1. Add the Verisoul SDK to sign-up, login, checkout and payout pages using the Verisoul docs
2. Give anchor_browser with detection_method signed its own rule, separate from unknown automation
3. Use bot score for unsigned sessions and look for groups of accounts with identical paths and timing
4. Review signed sessions on ticket and limited-inventory checkout, where replayed workflows do the most damage

Should you block Anchor Browser?

Signed Anchor sessions are verifiable automation, often doing logged-in work for a business customer, so allowing them on integrations you approve makes sense. At sign-up and payouts review or block them, because the signature tells you nothing about who directed the task.

Ticketing and limited-inventory checkout deserve the strictest rules. A replayed workflow running across many sessions is exactly how inventory gets cleared before people get a chance, signed or not.