Security model

Authority stays bounded from agent to browser.

BrowserPair is designed around explicit scope, extension-owned execution, durable task ownership and fail-closed recovery.

Trust boundaries first.

BrowserPair separates the user, agent key, cloud control plane and extension executor so no single untrusted page or agent response can silently expand authority.

Page text is data

Content from a website can inform the task, but it cannot add permissions or override the task contract.

Extension owns mutations

Browser mutations happen only inside the extension executor. Cloud coordinates the task but does not click, fill or navigate pages itself.

Tab ownership is explicit

Hosted tasks act only on strongly owned tabs. Probable or unrelated tabs require explicit input instead of silent adoption.

Keys define the ceiling.

Each agent key can restrict browser IDs, domains, ordinary capabilities and elevated capabilities. The immutable task contract narrows that scope again for one task.

BR

Browser scope

Choose which connected browser identities an agent can use.

DN

Domain scope

Limit the websites a key or task may navigate and act within.

CP

Capability scope

Grant only the action classes the agent actually needs.

OK

Approval policy

Choose when BrowserPair pauses for a person without expanding hard scope.

Sensitive operations get extra friction.

Publish, send, delete, payment, password and transfer effects require explicit capability and any confirmation required by policy or the task contract.

Redaction boundary

Passwords, OTPs, card data, API keys, auth tokens and cookies are redacted before observations leave the device.

Agent keys and browser device credentials are separate. The extension does not store the agent key that authorized a task.

Unknown effects are not retried blindly.

Browser automation can fail at awkward boundaries: the page may change, the network can disappear or a tab can reload after a click. BrowserPair records task and effect state so recovery can distinguish “safe to retry” from “must verify first.”

Idempotent task creation

Retrying the same task creation request does not create duplicate work when the idempotency key and body match.

Fencing generations

Controllers and reconnects carry generations so stale executors cannot keep mutating a task they no longer own.

Effect verification

An executing or unknown side effect is verified before retry. If certainty is impossible, BrowserPair waits for resolution.

The cloud is a control plane, not your browser.

BrowserPair Cloud handles identity, permissions, routing, usage and audit. It keeps the coordination layer durable while your existing signed-in browser session stays on the connected device.

Task goals, contracts and results stored by BrowserPair are encrypted at rest. Operational logs are designed to avoid task/page text, cookies and credentials.

Security contact

For security questions or responsible disclosure, email browserpair@gmail.com.

Scope the agent before the first task.

Use a separate key for each agent and keep browser, domain and capability access as narrow as the workflow allows.

Open BrowserPair