Skip to main content

Setup

1. Create a dedicated vault

Create a new vault in 1Password for Browser Use. Add the credentials you want the agent to access (usernames, passwords, and 2FA/TOTP codes).

2. Create a service account token

  1. Go to 1Password Developer Tools - Service Accounts
  2. Click New Service Account, name it “Browser Use Cloud”
  3. Grant read access to the dedicated vault
  4. Copy the generated token

3. Connect to Browser Use Cloud

  1. Go to Browser Use Cloud Settings - Secrets
  2. Click Create Integration
  3. Paste your service account token

Use a vault in a v4 run

Pass the vault id and the domains where its credentials may be typed. Browser Use finds the project’s connected 1Password integration and makes the vault’s username, password, and TOTP fields available to the run. You do not need the integration, item, or field ids.
Every supported credential field in the vault is made available to the run. Use a dedicated vault containing only the accounts the agent needs.
  • opVaultAllowedDomains is required with opVaultId. Use bare hostnames; a hostname also covers its subdomains.
  • Vault items become aliases based on their titles, with _username, _password, or _bu_2fa_code suffixes.
  • Vault fields and explicit secretBindings share a limit of 10 bindings per run. The API returns 422 if the combined total exceeds 10.
  • Vault access requires exactly one active 1Password integration on the project and is unavailable for zero-data-retention projects.
These fields work through the v4 REST API. The currently published Python and TypeScript SDK types do not expose them yet; use the REST request above until those clients are regenerated.

Bind individual fields in a v4 run

For least-privilege access, use secret bindings instead of exposing every credential field in a vault. Each binding names one field of one 1Password item, gives it an alias the agent can ask for, and lists the hosts where it may be typed. The value never reaches the model; the server types it into the focused field when the agent asks for the alias on an allowed domain. Bindings are run-scoped, so a follow-up run that needs the same login must send them again.
  • integrationId is the 1Password integration you connected under Settings → Secrets.
  • vaultId and itemId are the 1Password UUIDs of the vault and item (copy them from 1Password).
  • fieldId is the field’s id, not its label: username, password, or one-time-password for a TOTP field, which resolves to the current code.
  • allowedDomains are bare hostnames; a host covers its subdomains.
In the chat UI at cloud.browser-use.com both options live under Run settings → Credentials. Use a whole vault asks for the vault and the allowed sites and sends opVaultId + opVaultAllowedDomains; Add a credential walks vault, item, and field, takes an alias and the domains, and sends one binding. The Agents page has a 1Password section with the same vault + allowed-sites pair, and its REST snippet shows the resulting request.

Use a vault in a v2 or v3 task

For SSO/OAuth redirects, include all required domains:

How it works

When the agent encounters a login form:
  1. It identifies the service (e.g., Twitter, GitHub, LinkedIn)
  2. Retrieves matching credentials from your 1Password vault
  3. Fills in the username and password
  4. If 2FA is required and a TOTP code is stored, it generates and enters the code automatically
The agent never sees your actual credentials. The actual username, password, and 2FA codes are filled in programmatically — keeping your secrets hidden from the AI model.