Browser Use is an MIT-licensed Python library that lets a large language model drive a Chromium browser by turning each page into structured text the model can act on. Magnus Muller and Gregor Zunic first showed it on Hacker News as a weekend prototype in late 2024, and by Mar 22, 2025 it had 50,000 GitHub stars and a $17M seed round led by Felicis, with Y Combinator, Paul Graham and SV Angel joining. The repository had about 119,200 stars on Nov 1, 2026.
The company also sells Browser Use Cloud, which rents stealth cloud browsers and runs hosted web agents. Browser Use says its cloud created 3.7M browser sessions in the seven days to Oct 14, 2026, which is a vendor figure but gives a sense of scale. It is also the browser layer under other agents, including Hermes Agent and some of OpenAI's computer-use hosting partners, so its traffic often carries someone else's agent.
Site owners ask about it because it is the default way developers point an LLM at a website. Logins, form filling, booking and checkout flows are all documented use cases, and the cloud product markets getting through bot protection as a feature.
How Browser Use shows up on your site
Since Aug 20, 2025 the library has controlled Chromium directly over the Chrome DevTools Protocol rather than through Playwright, as the team explains in leaving Playwright for CDP. A self-hosted run therefore looks like a CDP-driven Chromium coming from wherever the developer runs it, often a cloud VM. Browser Use Cloud is different, because it runs a hardened Chromium fork with stealth on by default, fingerprints randomized per session, residential proxies in 195+ countries and automatic CAPTCHA solving outside its EU region, per its stealth docs.
| Check | What Browser Use does |
|---|---|
| User agent | Ordinary Chrome user agent, no Browser Use token |
| Web Bot Auth signature | None. A GitHub request to add signing (#6109) is open |
| IP ranges | No list. Cloud exits through residential proxies by default |
| robots.txt | Not documented |
Why Browser Use is hard to detect
There is nothing declared to match, which means every check has to come from the browser and the behavior. Self-hosted runs are the easier half, because CDP control leaves automation artifacts and the sessions often come from datacenter IPs on VM hardware. The cloud fork is built to remove exactly those tells, and because it randomizes canvas, WebGL, font and navigator fingerprints on every session while exiting through residential IPs, static checks mostly come up empty.
Behavior is harder to fake. A May 2026 academic study, FP-Agent, found that Browser Use typed with near-constant gaps between keystrokes, moved the cursor by jumping straight to targets with no movement in between, and scrolled in instant jumps, which separated it from people almost perfectly. The same study found its fingerprint often matched other agents, so fingerprints alone were a weaker way to tell agents apart than behavior was.
How Verisoul detects Browser Use
For self-hosted runs, Verisoul labels the session by what the browser reveals about itself: DevTools-protocol automation artifacts in the browser, plus scripted navigation with no human input. Those sessions come back as cdp_automation. Browser Use Cloud stealth sessions are flagged through bot score, and Verisoul does not yet name Browser Use as the agent.
"agent": {
"id": "cdp_automation",
"name": "DevTools automation",
"provider": "Open source",
"type": "headless_automation",
"detection_method": "self_declared",
"detection_signals": [
"network",
"device",
"behavioral"
]
}idis the stable identifier for rules, herecdp_automation, which covers any browser driven over the DevTools Protocoltypeisheadless_automation, meaning a scripted browser rather than a person or a personal assistantdetection_methodisself_declared, because the browser itself exposed automation markersdetection_signalslists the evidence:devicefor the DevTools artifacts andbehavioralfor scripted navigation
The DevTools automation entry in Agent Atlas lists the signals behind the label, and the AI agent detection docs show where the agent object sits in the API response.
- 01Developer runs a Browser Use script
- 02Library drives Chromium over CDP
- 03Session hits your login or sign-up
- 04Your page sees DevTools automation
How to detect Browser Use step by step
- Install the Verisoul SDK on sign-up, login and payout pages following the Verisoul docs
- Route sessions with agent id
cdp_automationto your automation policy - Set a bot score threshold for unnamed sessions, which is where Browser Use Cloud stealth traffic lands
- Allowlist your own QA and partner automation separately so your rules stay strict for everyone else
Should you block Browser Use?
Browser Use is a developer tool, so a session on your sign-up or payout page is rarely a real customer acting for themselves. Most teams block cdp_automation at account creation and payouts and send high bot scores to review on the same steps.
Public pages are a scraping and rate-limit question more than a fraud one. If partners or your own team automate flows on purpose, give them a separate path, such as an API, rather than loosening the rules on the browser flow everyone else uses.