Methodology: multi-source + counter-evidence search
Each claim about Browser Use and OpenClaw was checked against primary sources — GitHub, official docs, NVD — with counter-evidence searched for every one. Verdicts: green = confirmed, red = refuted, amber = uncertain.
selector_map — a dict[int, EnhancedDOMTreeNode] — where each interactive element is assigned a sequential integer index. The LLM receives a text rendering of this serialized structure, not a raw HTML dump.
EnhancedDOMTreeNode combines data from all three. The deep wiki for the project refers to this as a "DOM Processing Engine," not strictly an "accessibility tree." The serializer (browser_use/dom/views.py, DOMTreeSerializer) filters for interactive, visible nodes and assigns sequential integer indices — but the primary source is the DOM tree augmented with AX data, not a pure accessibility tree.
The claim says "accessibility tree" as if it is the sole or primary source. One technical source (deepwiki.com on browser-use) explicitly states: "The documentation does not describe this as an accessibility tree. Rather, it's part of the 'DOM Processing Engine'." The numeric indexing part is confirmed; the "accessibility tree" label is a simplification.
Sources
browser_use/examples/features/sensitive_data.py demonstrates a manual domain-keyed dictionary: sensitive_data = {'httpbin.org': company_credentials}. The developer must explicitly map credential names to domains. The model sees placeholder keys like x_name and x_password — it never sees values — but only for the keys you register.
sensitive_data as a "Dictionary of sensitive data to handle carefully," with no mention of automatic PII pattern detection. No changelog entry in the browser-use releases refers to regex-based or heuristic auto-detection of passwords, SSNs, or credit card numbers. Known bugs (Issue #713, Issue #695, Issue #1062) all concern the explicit-registration mechanism failing in edge cases — none reference an auto-detection layer being added.
Sources
use_vision=True sends screenshots to the LLM API — is confirmed. The docs state: True = always includes screenshots; False = never includes them; 'auto' = uses vision only when requested. The browser-use docs themselves warn: "if you must pass secrets, use sensitive_data and disable vision to avoid screenshot leaks." This implicit warning confirms that screenshots can expose content that text-layer redaction would mask.
service.py code shows sensitive_data filtering operates at the MessageManager level (text messages), and there is no visible screenshot-sanitization layer before API transmission. However, the absence of sanitization code in the one file fetched does not definitively confirm there is none anywhere in the pipeline.
The docs frame this as a known risk to mitigate through configuration (use_vision=False when handling credentials), not as a design defect with a code-level fix. The bypass concern is real but described as a deployment responsibility, not a bug.
Sources
Sources
browser_use/controller/service.py#L137 emitted lines such as ⌨️ Input xxxxxxxxxxxxx into index 3 where the x's represented the actual credential value in plaintext.
Sources
Conflating EchoLeak with browser automation agent security is a category error. EchoLeak involves Microsoft's XPIA classifier bypass and Teams proxy abuse — architectural specifics that have no analog in browser-use's threat model. Using CVE-2025-32711 as evidence of browser-agent risk would be misleading in a security report.
Sources
| Claim | Verdict |
|---|---|
| 01 — Indexed serialized accessibility tree | Uncertain |
| 02 — sensitive_data only redacts pre-registered values | Confirmed |
| 03 — use_vision=True screenshots bypass redaction | Uncertain |
| 04 — OpenClaw separate product, integrates as plugin | Confirmed |
| 05 — Issue #713 plaintext passwords in controller logs | Confirmed |
| 06 — CVE-2025-32711 relates to browser agent exfiltration | Refuted |
Strikethrough on Claim 06 indicates refuted claim text.