Skip to content
Blopblop docs

Security model

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

Section titled “Guarantees”
GuaranteeDetail
No arbitrary codeNo JavaScript evaluation tool, no shell tool and no unrestricted CDP commands
Validated targetsStructured targets keep strict ambiguity errors; stale, detached, hidden, inert or occluded targets are rejected
Bounded outputSnapshots, screenshots, extraction, logs and batched actions have size limits
Recorded actionsSuccessful and failed actions are recorded for host-side evidence
Explicit finishfinish_test cannot run inside a batch
Private CLI daemonListens on 127.0.0.1 only, authenticates calls with a random token, and restricts runtime files to the current user
Explicit profile accessAttaching to an existing Chrome profile requires --attach-existing

Risks and what to do

Section titled “Risks and what to do”
RiskWhat to do
The daemon runtime directory holds session tokens and stateKeep it private; never proxy the daemon to a public interface
A Chrome CDP endpoint controls that profile’s cookies, tabs and signed-in sessionsBind CDP to localhost and use a dedicated profile directory
browser_upload_file reads any path the host passesValidate 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 dataStore and retain them under the same controls as test artifacts
Docker socket access can start containers, mount host paths and change infrastructureDo 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 serverUse a dedicated trusted network with no unrelated workloads
The Chromium container disables web security by default for cross-origin testingSet BLOP_CONTAINER_DISABLE_CORS_BYPASS when same-origin behaviour is part of the test or isolation model

Host policy

Section titled “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

Section titled “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 has the full operator checklist.

Next

Section titled “Next”