Overview
Browser Harness (browser-use/browser-harness) is an open-source Python project that connects an LLM directly to a Chrome instance via the Chrome DevTools Protocol (CDP) over a single WebSocket. The project’s defining characteristic — and its primary security concern — is that it is explicitly designed with no framework, no guardrails, and no rails. When the agent encounters a capability it lacks, it autonomously edits its own helper code and writes the missing function mid-task. The tagline, “You will never use the browser again,” underscores the intent: total delegation of browser interaction to the LLM.
With 6,500+ stars and active development as of April 2026, this tool is seeing meaningful community adoption, making its security posture a practical concern, not a theoretical one.
Technical Analysis
The architecture introduces several compounding risk vectors:
1. Unrestricted Code Generation and Execution
The self-healing mechanism allows the LLM to write new Python functions into helpers.py and execute them without human review. An adversary controlling the LLM’s inputs (e.g., via malicious web content) could inject instructions that cause the agent to write and execute arbitrary system commands.
● agent: wants to upload a file
│ ● helpers.py → upload_file() missing
│ ● agent edits the harness and writes it
helpers.py 192 → 199 lines
│ + upload_file() ✓ file uploaded
2. Prompt Injection via Web Content Because the agent reads and acts on page content, any webpage visited can embed adversarial instructions. A malicious site could instruct the agent to exfiltrate session cookies, submit forms, or pivot to authenticated services open in other tabs.
3. CDP Full Browser Access Direct CDP access means the agent can access all open tabs, intercept network requests, read cookies and local storage, and execute JavaScript — a far broader attack surface than a typical browser extension.
4. Daemon Process
The daemon.py component suggests persistent background operation, increasing the window of exposure.
Framework Mapping
| Framework | ID | Reason |
|---|---|---|
| OWASP LLM | LLM08 | Excessive Agency — agent has unrestricted action scope with no human approval gates |
| OWASP LLM | LLM01 | Prompt Injection — malicious web content can redirect agent behaviour |
| OWASP LLM | LLM02 | Insecure Output Handling — LLM-generated code is written to disk and executed |
| OWASP LLM | LLM06 | Sensitive Information Disclosure — CDP access exposes session tokens and credentials |
| MITRE ATLAS | AML.T0051 | LLM Prompt Injection via adversarial web content |
| MITRE ATLAS | AML.T0054 | Jailbreak potential through unconstrained task framing |
Impact Assessment
- Individual users running the harness against personal browsers risk session hijacking and credential theft via prompt injection from any visited site.
- Organisations integrating this into automated workflows face arbitrary code execution risks on the host machine.
- Downstream consumers of Claude Code or Codex setups following the “paste this prompt” setup flow may inadvertently grant an LLM persistent, privileged browser access.
Mitigation & Recommendations
- Isolate the browser — run Chrome in a dedicated, ephemeral container with no access to authenticated sessions or sensitive local storage.
- Require human approval for any code written by the agent before execution; consider a code review gate in the harness loop.
- Scope CDP permissions — restrict the harness to a single browser context/profile with no access to other tabs.
- Apply prompt injection defences — treat all page content as untrusted input; implement an input sanitisation layer before passing DOM content to the LLM.
- Log all agent actions — maintain an immutable audit trail of every helper function written and every browser action executed.