docs: clarify browser allowlist defaults and risks

This commit is contained in:
Peter Steinberger
2026-01-11 01:55:38 +01:00
parent a32021dc3e
commit fe46a2663b
3 changed files with 11 additions and 0 deletions

View File

@@ -1471,6 +1471,7 @@ Allowlists for remote control:
- `allowedControlUrls`: exact control URLs permitted for `target: "custom"`.
- `allowedControlHosts`: hostnames permitted (hostname only, no port).
- `allowedControlPorts`: ports permitted (defaults: http=80, https=443).
Defaults: all allowlists are unset (no restriction). `allowHostControl` defaults to false.
### `models` (custom providers + base URLs)

View File

@@ -199,6 +199,15 @@ Also consider agent workspace access inside the sandbox:
Important: `tools.elevated` is the global baseline escape hatch that runs bash on the host. Keep `tools.elevated.allowFrom` tight and dont enable it for strangers. You can further restrict elevated per agent via `agents.list[].tools.elevated`. See [Elevated Mode](/tools/elevated).
## Browser control risks
Enabling browser control gives the model the ability to drive a real browser.
If that browser profile already contains logged-in sessions, the model can
access those accounts and data. Treat browser profiles as **sensitive state**:
- Prefer a dedicated profile for the agent (the default `clawd` profile).
- Avoid pointing the agent at your personal daily-driver profile.
- Keep host browser control disabled for sandboxed agents unless you trust them.
## Per-agent access profiles (multi-agent)
With multi-agent routing, each agent can have its own sandbox + tool policy: