OpenClaw

OpenClaw is an open-source personal AI agent that runs on the user's own computer or server, takes instructions over chat apps such as WhatsApp, Telegram, Slack and iMessage, and uses a real browser to get things done with the user's accounts. Peter Steinberger first published it on Nov 24, 2025 under the name Warelay, and it went through CLAWDIS, Clawdbot and Moltbot before settling on OpenClaw on Jan 30, 2026. In February Steinberger joined OpenAI, and the project moved to the OpenClaw Foundation, a non-profit OpenAI supports, while the code stays MIT-licensed.

Its growth has been unusual even by AI standards. The New Stack reported that OpenClaw passed React in early March 2026 to become GitHub's most-starred software project, and the repository showed 393.5k stars and 82.7k forks on Nov 1, 2026. Tom's Hardware reported 1.5 million agents created by early February. OpenClaw 2.0 shipped on Aug 30, 2026 with easier setup and shared cloud sessions, which lowers the bar for people who would never have touched a terminal.

For fraud and risk teams the interest comes from what OpenClaw can do once it has a browser. It fills forms, signs up for accounts, books, shops and posts, and nothing in the core project forces a human approval before a purchase. Third-party skills openly teach anti-bot bypass, so the same tool that runs one person's errands can also run a sign-up farm.

How OpenClaw shows up on your site

By default, OpenClaw's local Gateway launches a dedicated agent-only Chrome, Brave, Edge or Chromium profile and drives it over the Chrome DevTools Protocol with Playwright on top, according to its browser tool docs. On a Linux server with no display it goes headless automatically. Users can also attach it to their real, signed-in Chrome through Chrome DevTools MCP or a relay extension, or point it at a hosted browser from a vendor such as Browserbase or Browser Use, and each of those changes what your site sees.

Why OpenClaw is easy to catch in some setups and hard in others

The default setup is the easy case, because a fresh Playwright-driven profile over CDP leaves automation artifacts in the browser, a headless server run can announce HeadlessChrome, and an agent-only profile arrives with no history or cookies, so it looks like a brand new device on every run. Playwright also tends to leave its own globals in the page, such as __playwright__binding__ and __pwInitScripts. Those are the same markers any scripted browser leaves, and they are reliable when present.

The hard case is attached mode. When OpenClaw rides the user's own Chrome on their home connection, the fingerprint, cookies and IP all belong to a real person, and the only thing left is how the session behaves. Self-hosting also means there is no central egress and no shared identity, while every user's mix of skills and backends is different, so no single list or rule covers OpenClaw as a whole.

How Verisoul detects OpenClaw

Verisoul does not name OpenClaw itself, because OpenClaw never declares who it is. What we name is the automation it uses. When OpenClaw drives its own browser, the browser gives itself away through DevTools-protocol automation artifacts or headless markers in the device fingerprint, and the session moves with scripted navigation and no human input. Verisoul returns those sessions as cdp_automation or headless_chrome. When it attaches to the user's real Chrome, Verisoul flags the session through bot score and does not name the agent.

"agent": {
  "id": "cdp_automation",
  "name": "DevTools automation",
  "provider": "Open source",
  "type": "headless_automation",
  "detection_method": "self_declared",
  "detection_signals": [
    "network",
    "device",
    "behavioral"
  ]
}

• id is the stable identifier you write rules against, here cdp_automation (or headless_chrome for headless server runs)
• type is the class of traffic, and headless_automation means a scripted browser with no person driving it
• detection_method is how the label was reached. self_declared means the browser itself exposed automation markers
• detection_signals lists the evidence, here device (DevTools or headless artifacts) and behavioral (scripted navigation with no human input)

Each id has an entry in Verisoul's Agent Atlas, along with Headless Chrome, and the AI agent detection docs cover the response format and how to act on it.

How to detect OpenClaw step by step

1. Add the Verisoul SDK to the pages that matter, starting with sign-up, login, rewards and checkout, using the Verisoul docs
2. Read the agent object on each session and route cdp_automation and headless_chrome to your automation policy
3. Write one rule per id and per step, for example block at account creation, allow on public browsing
4. Review sessions with a high bot score and no agent name, since that is where attached-mode OpenClaw lands

Should you block OpenClaw?

On public pages, an OpenClaw session is usually one person's errand, and blocking it buys little. Sign-up is different, because the tool is cheap to run at scale and skills for account creation are easy to find, so most teams block cdp_automation and headless_chrome at account creation and on rewards, promo and payout steps.

Checkout sits in between. A returning customer whose agent reorders something is low risk, while a new account checking out through an automated browser looks like the pattern behind card testing and reseller bots. Treat attached-mode sessions flagged by bot score with the same rules, because the person behind them can still be anyone.