Your agent signs in. It never holds the password.

No. Agents get a vault:// reference and a masked hint such as oc•••at. When a login is needed, Unbrowse types the value into the site's own login form, or places it into the outgoing request at the network edge for a learned tool. Tool results, page snapshots, traces and model prompts show [from vault], never the value.

One component: Sentinel. Every agent use of a saved login — filling a login form, signing in for a learned tool, reusing a kept session — is decided there before the vault opens anything. Sentinel allows it, refuses it, or asks you. Nothing else in Unbrowse can hand a login to a page.

The agent's call stops with approval_required and a one-time link. You open it, see the site, what the agent wants to do and why, and choose: just this sign-in, this browser session, one hour, 24 hours, always for this site — or deny. The agent waits with unbrowse.credentials.status and retries. It never sees the login, only the link.

Enforced. An approval is a capability bound to one site and one scope, checked by the server on every use. An agent cannot talk its way past it: text in a page or a prompt injection can change what the agent asks for, not what Sentinel allows.

Ask me. When you save a login because an agent asked for it, you pick the scope on the same page (24 hours is preselected). Logins saved before Sentinel shipped keep working unattended — their sites start at Always allow — and you can tighten any site in the password manager.

No. A login opens only for its own site or a subdomain of it, on the same scheme and port, and a lookalike domain never matches. Each use is a single-use lease that expires within a minute and names the page it is for; the page must match again when the value is released.

AES-256-GCM. Each workspace has its own data key, wrapped by a master key, and every record is bound to its workspace and id so ciphertext cannot be swapped between records. Keys are unwrapped per use and zeroed after. Snapshots store ciphertext only.

The server can decrypt them — that is what lets your agents sign in while you are away. It is not a zero-knowledge vault. What we do limit is who can make the server use them: only Sentinel-approved agent uses and you, signed in, on the vault page. Every read is audited and shown to you.

It is an open problem, for us and for everyone. Our answer is to bound the damage: the model never holds a secret it could leak, a login only opens for its own site, sign-ins on an Ask-me site need your approval, and the sign-in browser refuses to type a saved password anywhere but the matching site.

The password manager shows every Sentinel decision (allowed, refused, asked you, and why), every live approval with a revoke button, and every time a value was filled, revealed or changed. Revoking takes effect on the next use.

Meta's write-up of how they secured Muse, their personal agent (September 2026). We adopted the parts that apply to a credential vault: the model never holds real credentials, one permission authority decides allow / deny / ask, approvals are strict scoped capabilities, and credentials are inserted at the boundary. Parts that do not apply to us yet — a per-user VM, kernel-level taint tracking, classifier ensembles — are listed as limits in our article.

Email security@unbrowse.ai (or hello@unbrowse.ai). Tell us what you found and how to reproduce it.