Browser Use Lets 1Password Fill Agent Logins Without Exposing Passwords

Browser Use has added a direct 1Password integration that lets browser agents enter authenticated sessions without receiving a user’s password. In the approval-based flow, 1Password fills the login after the user approves the request in the desktop app, then Browser Use resumes the task inside the authenticated session.

Common workarounds expose more credential data than many teams will accept: users paste passwords into prompts, share logged-in browser profiles, or build vault integrations that can surface secrets in model context, browser tools, or screenshots. The new personal-account flow gives the password manager control of credential delivery while leaving the agent in control of the surrounding task.

The password takes a separate path

After a user connects a personal 1Password account in the Browser Use dashboard, each protected login follows this sequence:

1. The agent reaches a login page and requests a matching credential.
2. Browser Use pauses the run and sends an approval request to the 1Password desktop app.
3. The user approves the request, and 1Password fills the form through its browser extension.
4. Browser Use resumes the run after authentication succeeds.

Because 1Password performs the fill, the agent receives metadata such as item titles, saved websites, and the authentication result. The password stays out of the prompt history, model context, and screenshot tool calls.

The integration uses 1Password’s Agentic Autofill protocol, which delivers credentials from the browser extension over an end-to-end encrypted channel at runtime. Credential material remains encrypted in the extension’s memory, is never written to disk, and is cleared when the task ends, the browser closes, or nine hours pass.

Three trust models, three exposure levels

Browser Use supports three integration modes with different approval, deployment, and credential-exposure properties:

Personal approval currently supports 1Password Individual and Families accounts hosted on 1Password.com. Business and Teams accounts cannot use this flow because 1Password does not provide the required consent screen for those plans. Work accounts must use the service-account route for now.

The service-account API stays compact

The service-account path adds an opVaultId field to the Browser Use run request:

Browser Use resolves usernames, passwords, time-based one-time passwords, and security-question answers from the selected vault. Each item is restricted to the websites saved on that 1Password record, which prevents an Amazon credential from being entered on an unrelated domain. The opVaultAllowedDomains option can narrow the permitted hosts further.

Runs that need tighter access can declare individual secret bindings instead of exposing an entire vault. Each binding identifies one field, assigns it an alias, and lists the hosts where Browser Use may enter it. A run can include up to 20 bindings.

Boundaries security reviews will probe

The integration docs identify several operational limits:

• Service-account credentials become reachable after insertion. The integration keeps raw values out of the task prompt and initial model context. Once a credential is typed into the page, browser and CDP tools can access it.
• CDP integrations must pause during autofill. Partner platforms should block DOM reads, screenshots, and CDP commands against the affected tab until fillCredential returns.
• TOTP codes work automatically. Store the TOTP secret on the 1Password Login item, and Browser Use generates the current code when required.
• Security questions use custom fields. Add each answer as a text field on the Login item and use the question itself as the field title. Browser Use matches the page’s prompt to that title.
• Zero Data Retention projects are unsupported. Personal 1Password and CDP flows require browser extensions that ZDR projects disable.

A cleaner boundary for authenticated agents

Security reviews often block browser-agent deployments when the model can retrieve or retain raw credentials. Agentic Autofill narrows that exposure by assigning the password manager a specific role: approve the request, deliver the credential to the correct site, and clear it when the task ends. 1Password introduced Browserbase as its first Agentic Autofill partner ; Browser Use, Perplexity, and Ramp have since joined the program.

Developers can use the Browser Use integration for tasks such as opening Jira, checking an order, retrieving an invoice, or accessing an internal dashboard while keeping personal credentials under 1Password’s approval controls. The resulting security boundary is straightforward to review: 1Password stores and fills the secret, Browser Use operates the authenticated session, and service-account deployments retain a documented higher-exposure option for unattended automation.