Skip to content
VaultTerm
Browse docs

browser-extension

Browser extension overview

A browser password manager for Chrome, Edge and Firefox. A fill is a local decrypt from an encrypted copy your organization can withdraw, and every reveal is still recorded.

Updated Aug 10, 2026

The VaultTerm browser extension is a password manager for Chrome, Edge (Chromium) and Firefox. It matches saved logins to the sites you visit, fills them, captures new logins as you create them, and generates one-time codes.

Where the secrets are

The extension keeps an encrypted copy of your vault on the device, so a fill is a local decrypt rather than a round trip, and it works with the browser offline. The organization keeps control of that copy:

  • The copy is sealed under a key the server issues. The key is bound to (you, this device, your organization), carries a lifetime, and can be withdrawn — from your own account settings, by an org admin, or by an organization policy that turns offline copies off entirely. Once it is withdrawn or lapses, the copy is wiped on the device’s next sync.
  • Unlock releases the key, and nothing else does. Offline, unlock is the account password (a browser extension has no keychain to hold a key behind a fingerprint); online, the usual device-bound unlock applies — see Install and unlock.
  • Every reveal is still recorded. A fill served from the local copy is written to a sealed, hash-chained journal on the device and handed to the server on the next sync, where it becomes an ordinary audit entry. If those records cannot be handed over within the window your organization sets, the extension stops filling from the copy until they are. An organization can also require the strict behaviour — no local reveals at all, so the audit record is always written before the secret is handed over. See Audit logs.
  • Some items never go into the copy. Injection-only credentials and honeytokens are listed without their value on purpose. A honeytoken costs a live, audited reveal; an injection-only credential is refused on every reveal path, so the extension cannot fill it at all. That flag keeps the secret out of the extension, not out of the broker — see SSH broker overview for what it does and does not prevent.

This matches VaultTerm’s overall posture: an audited access broker, not zero-knowledge. The server can decrypt your secrets for an authorized session, and so can the key it issued to your device. Envelope encryption and no-plaintext-at-rest apply the same way they do in the web app.

What it does

  • On-site match detection and autofill. The extension detects login forms on the current page, finds the credentials that match the site, and fills them on request.
  • Capture new logins on submit. When you sign in or create an account, the extension can detect the submitted credentials and offer to save them to the vault.
  • Built-in TOTP authenticator. Time-based one-time codes (RFC 6238) are generated in the extension for accounts that have a TOTP seed stored, so you do not need a separate authenticator app — see Secret types.
  • Phishing / look-alike-domain guard. A deterministic check flags homograph, punycode, typosquat, TLD-swap and brand-embedding domains before you hand over a credential. The classification runs locally and needs no network egress.

Permissions model

The extension requests optional host permissions rather than install-time permissions. It ships with no broad site access; when a feature needs to read or fill a page, you grant access in the popup, and the extension registers its content scripts dynamically at that point. This keeps the default permission footprint small and makes store review fast. Site access can be granted broadly or per site, and features resume immediately after a grant.

Where to go next