What happened
Browser Use’s 1Password guide separates the integration into three operating models. For API or dashboard runs using a service account, a team creates a dedicated 1Password vault, grants a service account read access, and connects its token in Browser Use Cloud settings. A v4 run can then name the vault with opVaultId; the run receives usernames, passwords, TOTP codes, and security-question answers. The documentation recommends keeping only accounts the agent needs in that vault.
The vault route applies website restrictions from each 1Password item by default: credentials can be typed only on the saved website’s host and its subdomains. Teams can instead set opVaultAllowedDomains for the vault. Items without a usable website are skipped, and the run response identifies skipped items. The request fails with HTTP 422 if every credential is skipped or if the run exceeds the combined limit of 20 vault fields and explicit secretBindings. Vault access requires exactly one active 1Password integration on the project and is unavailable for zero-data-retention projects. The guide says the current Python and TypeScript SDK types do not expose the v4 fields, so this route uses the REST API.
For a narrower grant, secret bindings identify one field from one vault item, give it an alias, and restrict it to specified domains. The server types the value into a focused field when the agent requests that alias on an allowed domain. Browser Use says this keeps the raw value out of the task text, but the value becomes available to the page and browser/CDP access once entered. Bindings apply to one run and must be sent again for a follow-up run that needs the login.
The personal-account flow is different: a user connects an Individual or Family account, enables 1Password for a dashboard run, and approves the login request in the 1Password desktop app. 1Password fills the login itself, so the password is not passed to the agent. The feature is off by default for each run, belongs to the connecting user and project, and is unavailable for zero-data-retention projects. Browser Use also documents a CDP integration for platforms running their own agent, in which an extension handles the fill after user approval; the page says the password does not pass through the platform’s servers or Browser Use API, but is present in the page during filling.
What the archive adds
New Runtime’s earlier coverage described Browserbase and 1Password’s Agentic Autofill integration, where user approval keeps credentials hidden from the agent (Browserbase + 1Password: secure sign-in for browser agents, 2026-10-23). This is a new product-specific implementation and a further fact on the broader sign-in story: Browser Use documents both approval-based personal logins and service-account options that expose credentials to runs.
Trend signal
This supports the shift toward runtime boundaries as the practical security control for agents: the credential path, host restrictions, and browser access determine what an agent can do, rather than a prompt asking it to handle secrets safely. The connection is to New Runtime’s agent security moves to runtime boundaries pattern. Browser Use’s guide is a concrete implementation, not evidence that all exposure risks are resolved.
Why it matters
Browser automation often needs authenticated access, but “the agent never sees the password” is not a blanket description of every integration mode. Teams can choose an approval-mediated personal login, or supply credentials through a service-account vault; the latter makes values available to the run. Secret bindings narrow which fields and domains are in scope, but the filled value can still be exposed to the page and browser/CDP layer.
That distinction affects both product design and threat modeling. A team building a user-facing agent can make the approval path explicit and preserve a user-controlled connection. A team automating shared operational accounts needs a dedicated vault, least-privilege contents, and carefully chosen host restrictions. The 20-binding cap and run-scoped behavior also shape task decomposition and repeat-login workflows. Security review should follow a secret through the whole path—storage, authorization, fill, page, and browser access—instead of treating it as protected merely because it is absent from the prompt.
Limits and uncertainty
Browser Use’s guide describes intended behavior and setup, but does not independently measure resistance to credential leakage or establish how often fills succeed across sites. The service-account mode explicitly makes credential values available to the run, while the secret-binding mode leaves them accessible to the page and browser/CDP access after entry. Personal-account connections exclude Business and Teams accounts; the CDP route has additional 1Password partner-preview requirements. The documentation also notes that SDK types for the v4 vault fields have not yet been regenerated.
Skill to build now
Map one real login workflow before connecting an account. Decide whether it needs a user’s personal approval or a service identity; for service identities, create a dedicated vault and test the saved-site restrictions. Where possible, bind only the required field to the exact host, then verify what the agent, page, and browser/CDP layer can observe after the fill.
Reader takeaway
Browser Use’s 1Password integration is not one security model: personal autofill keeps the password from the agent through user approval, while service-account and secret-binding paths make different trade-offs. Choose by identity and task, and treat domain limits and the post-fill page/browser as part of the credential boundary.