Browser-use is an open-source Python framework for building agents that operate a web browser. Give the agent a task and a language model, and it can open pages, click controls, enter text, fill forms, and extract data.
What Browser-use controls
Browser-use sits above the browser. It handles the agent loop: reading the page, asking the model what to do next, carrying out that action, and continuing until the task is complete. The open-source project supports its own hosted models as well as models from other providers and is available under the MIT license.
The browser underneath is configurable. The current CLI can launch managed headless Chromium, connect to an existing Chrome profile, or use a cloud browser. The Python library also accepts a local executable, a browser channel, proxy settings, profile data, or a Chrome DevTools Protocol (CDP) connection to a remote browser. That range matters to defenders because there is no single network or browser fingerprint that identifies every Browser-use job.
Where its traffic appears
The project's own examples cover form filling and structured data extraction. Its documentation also recommends the Python library for repeatable work such as scraping, monitoring, and quality assurance.
These jobs can look ordinary one page at a time. An agent can use a normal Chrome profile with existing cookies, follow multi-step flows, and wait for the model between actions. It can also run headlessly in a fresh local or cloud browser. A rule written for one of those setups may say little about another.
Browser-use is the orchestration layer, not an identity sent in an HTTP header. A site usually observes the chosen browser, network path, requests, and interaction pattern rather than the name "Browser-use." It is one source of the agentic traffic that sites now need to classify.
Why one browser check is not enough
A visible automation property can be useful evidence, but it is not a durable identity. Browser-use lets an operator change browsers, profiles, launch arguments, and remote infrastructure. A separate stealth layer can alter some browser-facing properties again.
Detection therefore needs context. Check whether the connection, request headers, browser claims, and session behavior agree. Pay attention to what the session touches, how it moves through the flow, and whether the same task pattern recurs across different apparent identities. Treat each observation as evidence, not a verdict on its own.
For a practical model, see how to detect browser automation.
Centinel benchmark result
Centinel detected Browser-use in our September 2026 benchmark.
That result makes Browser-use a useful regression case for a bot-protection program. Retest it when the browser or detection logic changes.
Set policy from the job
Start with the resource, not the tool name. Automation on a public status page deserves a different policy from automation attempting to log in, reserve inventory, or extract protected data.
Record enough evidence to explain the decision, then choose the least disruptive control that fits the flow. Observation or rate limits may be enough for low-risk traffic. Sensitive or abusive flows may justify a challenge or block. Preserve an allow path for automation the site has approved. Centinel bot management, the product tested in that benchmark, sets these controls per route. Test it against your own traffic.