# Security model

> Check what Browser Harness guarantees, what it leaves to the host, and how to deploy sessions and containers safely.

Browser Harness limits an agent to explicit, inspectable browser operations. These limits reduce accidental or model-driven capability escalation; they do not make the browser a general-purpose security sandbox.

## Guarantees

| Guarantee | Detail |
| --- | --- |
| No arbitrary code | No JavaScript evaluation tool, no shell tool and no unrestricted CDP commands |
| Validated targets | Structured targets keep strict ambiguity errors; stale, detached, hidden, inert or occluded targets are rejected |
| Bounded output | Snapshots, screenshots, extraction, logs and batched actions have size limits |
| Recorded actions | Successful and failed actions are recorded for host-side evidence |
| Explicit finish | `finish_test` cannot run inside a batch |
| Private CLI daemon | Listens on `127.0.0.1` only, authenticates calls with a random token, and restricts runtime files to the current user |
| Explicit profile access | Attaching to an existing Chrome profile requires `--attach-existing` |

## Risks and what to do

| Risk | What to do |
| --- | --- |
| The daemon runtime directory holds session tokens and state | Keep it private; never proxy the daemon to a public interface |
| A Chrome CDP endpoint controls that profile's cookies, tabs and signed-in sessions | Bind CDP to localhost and use a dedicated profile directory |
| `browser_upload_file` reads any path the host passes | Validate upload paths in multi-user services; never pass paths to secrets or unrelated user data |
| Screenshots, extracted HTML, console logs and page text can hold sensitive data | Store and retain them under the same controls as test artifacts |
| Docker socket access can start containers, mount host paths and change infrastructure | Do not expose container helpers to untrusted input without a separate authorisation boundary |
| In shared-network mode, every container on the network can reach the browser server | Use a dedicated trusted network with no unrelated workloads |
| The Chromium container disables web security by default for cross-origin testing | Set `BLOP_CONTAINER_DISABLE_CORS_BYPASS` when same-origin behaviour is part of the test or isolation model |

## Host policy

Browser Harness provides tool contracts, not an authorisation policy. The host decides:

- 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 stop.

## Production targets

Capability limits alone do not make operating a production site safe. Production browser checks need an explicitly selected target, a dedicated synthetic identity, least privilege, reversible actions, cleanup and TTLs, rate limits, a kill switch and sensitive-artifact handling. Review third-party effects such as payments, email, SMS and webhooks before the session starts. [Production checks](/checks/production/) has the full operator checklist.

## Next

- [Browser Harness](/harness/)
- [TypeScript API](/harness/library/), to give an agent a restricted tool set