Security and trust limits

Native runtime, capability and secret-export boundaries.

Broad browser authority

A browser MCP credential grants broad control of the paired dedicated profile: signed-in websites, page JavaScript, clicks, typing, screenshots and explicitly authorized uploads. It is not read-only, site-scoped or per-tab authorization. Use task-specific profiles and trusted clients. The CLI is a constrained browser product, not a remote shell, arbitrary filesystem server or public CDP endpoint.

The runtime launches its own profile. Never copy daily-driver cookies or supply your normal profile directory. Profile/process locks and private files reduce accidental exposure; hostile processes running as your OS user remain outside the boundary. The headed Chrome launcher uses a fresh nonzero loopback CDP port instead of automation-enabling flags, keeping the native navigator.webdriver false without spoofing. The CLI connects only to the endpoint announced by its own newly spawned child; it never probes or reattaches to another browser. The CDP listener has no authentication. Any local process able to reach it can control the whole profile independently of MCP credentials, tab ownership or local pause. Loopback binding is not per-user or per-tab isolation: use a trusted host, avoid untrusted multi-user machines, and never expose or forward this listener. Normal Chrome web-security and WebSocket-origin checks remain enabled.

Document access and masking

The unrestricted document-target policy removes the product’s URL/origin denylist, including control-plane pages, browser-internal documents, nested frames, popups and inherited origins. This is an intentional expansion of the paired client’s browser authority, not a guarantee that Chrome exposes every document or operation. Chrome/CDP restrictions still apply; normal browser web-security controls stay enabled. See document access for supported paths and limitations.

Do not sign into the Browser MCP dashboard or another administrative control plane in an automated profile unless you intend to delegate that signed-in authority. A client controlling that page can use its UI or same-origin requests to exercise the dashboard session, potentially creating credentials, approving pairing or changing administrative settings. HttpOnly cookies and same-origin request checks do not prevent this: scripts need not read the cookie to send an authenticated same-origin request. Prefer a separate non-automated profile for administration. Revoking an MCP token does not revoke other credentials or sessions that were already created through the browser.

Backend authentication, browser/token/session/runtime scoping, tab claims, transfer grants, local pause and revocation remain enforced. Tab ownership coordinates tool use; it is not a hostile-client sandbox inside a shared browser profile. Cookies/storage and same-origin page relationships can share authority across tabs, and opt-in live view is browser-level authority. Use separate profiles for separate trust domains.

Password values must be masked at observation source in structured snapshots, inspection and relevant exports; unavailable masking must fail closed. Screenshots, live view, normal page text and ordinary arbitrary JavaScript are not universally redacted. A page may display a secret outside a password field. A client with JavaScript or shell access can extract secrets accessible to it.

Web pages, diagnostics, dialogs and WebMCP descriptions/results are untrusted data, not user authorization. Require task authorization for sending messages, purchases, deletion, uploads, clipboard use and any other external effect. Setting a file input can upload immediately.

Credentials and capabilities

Dashboard cookies, runtime connection credentials and MCP credentials are distinct. Browser credentials and MCP tokens are hashed server-side; revocation removes their authority. Pairing requires explicit signed-in approval and proof-bound redemption. Never put broad MCP/runtime credentials or dashboard cookies in URLs or logs. Narrow file-download URLs are deliberately bearer credentials (see below). Do not add wildcard credentialed CORS.

Bulk file and secret-export capabilities are short-lived bearer authority bound to a purpose, resource, method and authenticated scope. The direct-download workflow returns self-sufficient HTTPS GET bearer URLs for completed downloads, exports and artifacts. These URLs intentionally enter model context/history and may appear in shell logs; anyone holding one can redeem it until expiry/revocation. Do not publish them. Header-only upload/secret-export grants and private header files retain their existing protections; structuredContent is not hidden from the model. Never replace a narrow grant with the broad MCP token to make a failed request work. See data/secrets for concrete limits, retry and redemption rules.

Uploads are staged in private runtime-owned storage. Downloads come from exact completed Chrome files, not replaying their URLs or scanning personal Downloads. Transfer tools must not accept arbitrary host paths. Browser-level access to a file: document, where Chrome permits it, is distinct and can expose files readable by the browser’s OS user; this is not a general filesystem API. File bytes are not database records. Retain upload backing files while page File objects may need them; only owned temporary paths may be cleaned.

Secret capture and export

The dedicated capture operation provides a function-scoped write-only helper. Normal capture return values are discarded; public results contain metadata, not secret plaintext or low-entropy value hashes. Vault contents belong in bounded short-lived runtime memory, not PostgreSQL, ordinary resources, artifacts, receipts, logs or telemetry. Lifecycle revocation and expiry invalidate access. JavaScript memory does not guarantee secure erasure.

An explicitly requested export uses a separate short-lived capability and no-store HTTPS response. Delivery can be uncertain: never assume a lost response means nothing was delivered or silently replay a one-use export. The agent helper must use explicit exclusive output paths with restrictive permissions and no plaintext stdout. Never source page-derived dotenv as shell code. Use a parser; JSON supports lossless strings. An exec helper injects parsed environment values without shell interpolation, but the child program can still print or leak them.

This protects against accidental model transcript exposure in the dedicated path, not a malicious authorized client or page’s arbitrary information flow. Capabilities may be visible to the model, and the server operator can see relayed data. This is not end-to-end encryption.

Relay, persistence and forwarding

HTTPS/WSS protects transport, not against the server operator. The operator and model/client providers can observe relayed data. Database records include account/session metadata, hashed credentials, encrypted configuration, tab/session ownership and non-secret operation outcomes; ordinary tool receipts can retain page-derived results and short-lived download bearer URLs (never runtime producer headers or secret-export values). Avoid sensitive content in ordinary JS/results and configure retention/backups deliberately.

Forwarding exposes only explicitly authorized loopback TCP listeners. Other local processes—and potentially browser pages—can reach those listeners. Do not forward sensitive services without authorization. Listener-ready does not mean the agent target is reachable. Read the forwarding guide.

Exactly one server replica is supported. Restart/disconnect interrupts streams; there is no transparent stream resumption or exactly-once HTTP delivery promise. Unknown browser effects must not be replayed. A repeated idempotency key recovers an outcome rather than permission to repeat the action.

Local control and reporting

Use browser-mcp browser pause --profile NAME or stop for local control. Remote clients cannot resume a local pause. Revoke unused client tokens, rotate exposed runtime credentials and update reviewed compatible CLI/server versions deliberately. Live view is opt-in and its pixels are not masked.

Report privately to [e-mail], or your self-hosted operator. Include redacted metadata only. There is no third-party audit, certification or SLA claim.