Skip to main content
Browser Use works with 1Password in three ways. Pick the one that matches who runs the agent and whose 1Password it is: Options 1 and 2 need no code beyond a normal run. Option 3 is for platforms that drive Browser Use browsers with their own agent and want their users to sign in with their own 1Password.

Service account

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, 2FA/TOTP codes, and security-question answers (see Security questions). Give each Login item the website it belongs to. v4 runs use it to decide where the item’s credentials may be typed.

2. Create a service account token

  1. In 1Password, open Developer > Service Accounts (guide)
  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 Connect 1Password
  3. Paste your service account token

Use a vault in a v4 run

Pass the vault id. Browser Use finds the project’s connected 1Password integration and makes the vault’s usernames, passwords, TOTP codes, and security-question answers 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.
  • Where credentials may be typed. By default each item’s credentials can only be typed on the hosts of the websites saved on that item in 1Password, so the Amazon password works on amazon.com and its subdomains, but not on other items’ sites. Websites marked “Never autofill” are ignored.
  • Items with no usable website (none saved, only invalid URLs, or only “Never autofill” entries) are skipped, and their titles come back in skippedVaultItems on the run response. The run starts as long as at least one vault credential is left; if every credential is skipped, the API returns 422.
  • Override with opVaultAllowedDomains. Pass a list such as ["amazon.com"] to use the same hosts for every item in the vault instead. Use bare hostnames.
  • Subdomains. Either way, a hostname also covers its subdomains, so amazon.com allows login.amazon.com. 1Password’s exact-domain autofill setting is not honored.
  • Aliases. Vault items become aliases based on their titles, with _username, _password, or _bu_2fa_code suffixes. Security answers get a suffix named after the question, for example chase_where_married.
  • Limit. Vault fields and explicit secretBindings share a limit of 20 bindings per run, and each filled security answer counts as one. The API returns 422 if the combined total exceeds 20.
  • 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 server types the value into the focused field when the agent asks for the alias on an allowed domain. This keeps the raw value out of your task text, but does not make it inaccessible to the agent: once entered, it is available to the page and to browser/CDP access. 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 only for the vault and sends opVaultId, so each item is limited to its own 1Password websites; 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-only picker, and its REST snippet shows the resulting request.

Use a vault in a v2 task

For SSO/OAuth redirects, include all required domains:

Personal 1Password

Connect your own 1Password account and let the agent ask it for a login while a dashboard run is in progress. You approve the login in 1Password, and 1Password fills it itself, so the password is never passed to the agent. If a fill fails and the agent retries the same login, it can reuse your approval while that approval is still valid.
Only personal 1Password accounts (Individual or Family) can connect. 1Password Business and Teams accounts cannot: 1Password shows no consent screen for them and opens the account dashboard instead.

Connect your account

  1. Go to Settings - Secrets and find Agentic Autofill: Personal.
  2. Click Connect personal 1Password and sign in with your personal 1Password account.
  3. On the consent screen (“Browser Use wants to connect to your 1Password account”), click Connect.
  4. You are sent back to Browser Use, which shows Ready for your first login.
The connection belongs to you and to the selected project. Other members of the project cannot use it. To remove it, click Disconnect on the same card.

Use it in a run

  1. In the run composer, turn on 1Password (“Use your 1Password for this run”). It is off by default and has to be turned on for each run.
  2. When the agent reaches a login page, it requests a login from 1Password and the run shows Waiting for your approval.
  3. Click Open 1Password on that card and allow your browser to open the 1Password desktop app if it asks. The app must be signed in to the same personal account.
  4. Review the request in 1Password and approve it. 1Password fills the login.
Personal 1Password is not available for zero-data-retention projects.

Personal 1Password with your own agent (CDP)

Use this if you run your own agent on Browser Use browsers (you create the browser and drive it over CDP) and want your end users to sign in with their own 1Password. This is the same 1Password Agentic Autofill integration other browser platforms offer: the 1Password extension runs in the browser, your backend calls it over CDP, the user approves in the 1Password app, and the extension fills and submits the login form. The password never goes through your servers or the Browser Use API. It is in the page only until the fill returns, so keep your model off the page during the fill (see Rules).
1Password Agentic Autofill is a 1Password partner preview, so its API can still change. Your end users need a personal 1Password account (Individual or Family, US) with the login in their own vault, and the 1Password desktop app on the Nightly release channel (Settings > Advanced > Release channel). Not available for zero-data-retention projects, which cannot use extensions.

Before you start

  1. Get OAuth apps enabled by 1Password. OAuth apps for Agentic Autofill are not enabled by default: until 1Password enables them for your 1Password Business account (not Teams), there is no option to create one. Ask your 1Password contact, or contact us and we will introduce you.
  2. Register your OAuth app. As an owner or administrator of that Business account, go to Integrations > OAuth Application. Enter the name and icon your users will see (the icon cannot be added later), your https redirect URL, grant type Authorization code and scope Read credentials. Store the client ID and secret; the secret is shown once.
  3. Upload the 1Password extension once with POST /api/v4/extensions (see Extensions): a ZIP, with manifest.json at its root, of the 1Password Nightly extension, version 8.12.46.6 or newer (see 1Password’s supported builds). Keep the returned id. In Browser Use browsers the extension gets its own runtimeId, so do not use the Chrome Web Store extension id.

Connect each user once

  1. Generate an unpredictable state and a PKCE code_verifier, and store both with the signed-in user’s pending connection. Send the user to https://my.1password.com/oauth/authorize (no /v1) with response_type=code, client_id, redirect_uri (exactly as registered), scope=brokered-credentials:request-access brokered-credentials:read, state, code_challenge and code_challenge_method=S256.
  2. Your redirect URL carries code and state in the query. Reject a missing, mismatched or already used state before you accept anything (see 1Password’s callback contract). On first consent it also carries an integration_key in the fragment (#integration_key=...). Browsers do not send fragments to your server, so read it in the browser, send it to your backend, store it before you exchange the code, then clear it from the address bar. It is delivered only once per connection; never overwrite a stored key with an empty value, and only reuse a stored key for the same user and 1Password account.
  3. Exchange the code: POST https://api.1password.com/v1/oauth/token, form-encoded grant_type=authorization_code, code, code_verifier, redirect_uri, with HTTP Basic auth (client ID and secret, not in the body). The response has access_token, refresh_token and expires_in.
  4. Access tokens last about 15 minutes. Refresh with the same endpoint and auth, form-encoded grant_type=refresh_token and refresh_token. Refresh tokens rotate, so store the new one every time (serialize refreshes per user). The refresh response never contains the integration_key, so keep the stored one.
Store tokens and keys encrypted in your backend. To disconnect a user, call 1Password’s self:revoke.

Sign a user in

  1. Create a browser with the extension: POST /api/v4/browsers with "extensionIds": ["<extension id>"]. Read extensions[0].runtimeId from the response.
  2. cdpUrl is an https:// URL. Playwright’s connectOverCDP accepts it directly; for raw CDP, take webSocketDebuggerUrl from {cdpUrl}/json/version.
  3. Find the target with type: "service_worker" and url chrome-extension://<runtimeId>/background/background.js (Target.getTargets, retry for a few seconds), and attach with Target.attachToTarget and flatten: true. Stay attached until you are done: the worker can suspend after about 30 seconds without a connection.
  4. Call the extension’s API with Runtime.callFunctionOn (awaitPromise: true, returnByValue: true), passing tokens as CDP arguments. Every call returns {success, result} or {success: false, error}; check success first.
  5. api.initialization.v1.whenSettled() (resolves to "ready"), then api.agenticMode.v1.enable().
  6. api.agenticAutofill.v1.createAccessRequest. Show the returned appLink (onepassword://...) as an Open 1Password button in your app, to open on the computer where the user’s 1Password app is signed in. The prompt closes after 2 minutes.
  7. Start polling getAccessRequestStatus when the user opens the link (1Password’s schedule): wait 5 seconds, then every 2 seconds, every 5 seconds after 30 seconds, every 10 seconds after a minute, every 20 seconds after 2 minutes, and stop after 3 minutes. If it is still pending, offer an “I approved it” button that checks once more, or create a new request. On rateLimitExceeded, wait at least a minute. Stop on denied, expired or any state you do not know. When it is resolved, take the reference of the grant whose entryId equals the id of the entry you requested (users can skip or add logins, so do not rely on array position).
  8. Open the login page with chrome.tabs.create in the worker, wait until chrome.tabs.get(id).status is complete (abort if it never is), check that the tab’s scheme, host and port still match the approved website exactly, then call fillCredential with that reference as resourcePath and the Chrome tab id as tabId.
  9. {"status": "fill_submitted"} means the form was submitted, not that the sign-in worked. Check the page: the site can reject the credentials or ask for another step. Then hand the browser to your agent.
  10. Stop the browser when the task is done (PATCH /api/v4/browsers/{id} with {"action": "stop"}); closing CDP alone does not stop it.
A grant stays valid for 30 days, so for repeat sign-ins you can keep the reference and fill again without a new approval. Put every login a task needs into one access request. A complete example (tested against production with a personal 1Password account):

Rules

  • Keep the model off the page while a fill runs. The values are in the page until fillCredential returns. Until then, pause your agent and block DOM reads, screenshots and other CDP commands to that tab, for example with a lock in your orchestrator. Do not install untrusted extensions in the same browser. See 1Password’s fill guidance.
  • Keep the extension session, tokens and the appLink out of the agent’s and model’s context and out of your logs. Do not log CDP traffic: it carries the token and key.
  • Do not turn on session recording for browsers that run fills.

Security questions

This section applies to the service-account integration, not to personal 1Password. If a site asks security questions, store the answers on the site’s Login item in 1Password. Add a custom field (text or concealed) titled with the question, with the answer as its value. 1Password’s Security Questions section works too. Browser Use passes every filled custom text or concealed field on a Login item to the agent, named after its question, so the agent can pick the right answer when the page asks.
  • Title each field with the question as the site words it. The agent matches the page’s question to the key.
  • Only Login items are read, and only fields with a value. Empty fields are skipped.
  • In v4, a question written only in a non-Latin script gets the alias <item>_answer, which does not say which question it answers. If an item has several such questions, write their titles in English.
  • The same allowedDomains rules apply as for the item’s password.

How it works

This describes the service-account integration. With personal 1Password, 1Password fills the login itself and the agent never receives the value. 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
  5. If the site asks a security question, it enters the matching stored answer
Credentials are filled programmatically, so you do not need to include their values in your task text. Once entered, they are available to the page; in v4, the agent can also access them through browser/CDP tools.