Browser Use Lets 1Password Fill Agent Logins Without Exposing Passwords

Browser Use shipped a 1Password integration that lets browser agents log into sites without the model ever seeing the password, using an approval flow on the user's own device. When the agent hits a login page, Browser Use pauses the run and sends an approval request to the 1Password desktop app; the user approves, 1Password fills the form through its browser extension via the Agentic Autofill protocol, and the agent receives only metadata such as item titles, saved websites and the authentication result. The personal flow requires 1Password Individual or Family accounts on 1Password.com — Business and Teams plans cannot use it because 1Password does not provide the required consent screen — and credential material is cleared when the task ends, the browser closes, or nine hours pass.

Browser Use Lets 1Password Fill Agent Logins Without Exposing Passwords Browser Use agents can now log into any site through 1Password without the model ever seeing the password, using an approval flow on your own device. - Browser Use shipped a 1Password integration https://docs.browser-use.com/cloud/guides/1password?utm source=alphasignal where the agent never sees the password. - Agent hits a login, 1Password prompts your desktop app, you approve, 1Password fills it in. - Three modes: service-account vault, personal 1Password dashboard, or your own agent over CDP. - Personal flow requires 1Password Individual or Family accounts, not Business or Teams. - Supports usernames, passwords, TOTP codes and security-question answers, scoped to item domains. - Uses 1Password's Agentic Autofill protocol with end-to-end encrypted, just-in-time credential delivery. Browser Use https://browser-use.com/posts/browser-use-1password?utm source=alphasignal 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: | Mode | How it works | Credential exposure | Best fit | |---|---|---|---| | Service-account vault | Create a dedicated vault, issue a read-only service-account token, and add it to Browser Use. | The agent and browser tools can access values used during the run. | Shared, unattended automation accounts. | | Personal 1Password | Connect an Individual or Families account and approve each login in the desktop app. | 1Password fills the form without delivering the secret to the agent. | Interactive tasks using a person’s credentials. | | Personal 1Password over CDP | A platform runs its own agent on Browser Use browsers while end users connect 1Password through an OAuth app. | The platform must pause agent access while 1Password fills the form. | Products built on the Chrome DevTools Protocol, or CDP. | 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: curl -X POST https://api.browser-use.com/api/v4/runs \ -H "X-Browser-Use-API-Key: $BROWSER USE API KEY" \ -H "Content-Type: application/json" \ -d '{ "task": "Open amazon.com, log in, and check my recent orders", "opVaultId": "<vault-id " }' 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 https://docs.browser-use.com/cloud/guides/1password?utm source=alphasignal 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 https://1password.com/blog/closing-the-credential-risk-gap-for-browser-use-ai-agents?utm source=alphasignal ; 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.