Security model
Browser Harness limits an agent to explicit, inspectable browser operations. The host still controls where sessions run, which tools are exposed, what files can be uploaded, and how evidence is stored.
Controlled capabilities
Section titled “Controlled capabilities”The public browser tool set has deliberate boundaries:
- It doesn’t expose arbitrary JavaScript evaluation.
- It doesn’t expose shell execution.
- It doesn’t expose unrestricted CDP commands.
- It validates structured targets and preserves strict ambiguity errors.
- It rejects stale, detached, hidden, inert, or occluded action targets.
- It bounds snapshots, screenshots, extraction, logs, and batched actions.
- It records successful and failed actions for host-side evidence.
- It requires
finish_testto run outside a batch.
These boundaries reduce accidental or model-generated capability escalation. They don’t turn a browser into a general-purpose security sandbox.
Protect local sessions
Section titled “Protect local sessions”The CLI daemon listens on 127.0.0.1, authenticates RPC with a random token,
and restricts its runtime files to the current user. Keep the runtime directory
private and don’t proxy the daemon to a public interface.
An existing Chrome CDP endpoint is especially sensitive because it grants control over that profile’s cookies, tabs, and authenticated sessions. Bind CDP to localhost and use a dedicated profile directory.
Protect file access
Section titled “Protect file access”browser_upload_file reads paths explicitly supplied by the host. Validate
upload paths before exposing the tool in a multi-user service, and don’t pass
paths containing secrets or unrelated user data.
Screenshots, extracted HTML, console logs, and page text can also contain sensitive application data. Store and retain them under the same controls as test artifacts.
Protect container infrastructure
Section titled “Protect container infrastructure”Access to the Docker socket can start containers, mount host paths, and alter local infrastructure. Don’t expose container session helpers to untrusted input without a separate authorization boundary.
Shared-network mode makes the browser server reachable to other containers on that network. Use a dedicated trusted network and don’t attach unrelated workloads.
The Chromium container disables web security by default to support
cross-origin testing. Set BLOP_CONTAINER_DISABLE_CORS_BYPASS when normal
same-origin behavior is part of the test or isolation model.
Keep host policy outside the harness
Section titled “Keep host policy outside the harness”Browser Harness provides tool contracts, not an authorization policy. The host must decide:
- Which users can create or reuse sessions.
- Which origins a session can visit.
- Which tools each agent can call.
- Which local files can be uploaded.
- Where screenshots and logs are stored.
- When sessions and warm containers are stopped.
Next steps
Section titled “Next steps”Return to Browser Harness for integration choices, or read the TypeScript API to create a restricted tool set for your host.