Skip to main content
Anything an AI must never see lives here, and only here.

​
Its job in the four-tier model

Bitwarden is T4, the never-AI human tier of the four-tier secrets model: break-glass and crown jewels. It is the one tier with no programmatic bridge by design. It has no command-line-tool integration, no MCP server, no agent path. Everything here is reached by a human at a keyboard with a second factor. It holds the material that can rebuild the other tiers if they are lost. That includes the OpenBao recovery shares that are the last-resort unseal path when both T2 and the T3 secret-zero are gone.

​
What goes in the Bitwarden vault

  • SSH private keys (full plaintext, not just shapes).
  • Age private keys (the master keys for every SOPS-encrypted file).
  • Recovery codes for every account (GitHub, AWS, Bitwarden itself, Doppler, the registrar).
  • Account passwords for services without OIDC integration.
  • TOTP seeds for MFA-protected accounts.
  • Encrypted backup exports of every other secrets store.
  • OpenBao recovery shares: the N-of-M unseal material for the T2 runtime manager.

​
What does not go here

  • Anything that flows into a workflow programmatically. CI cannot read Bitwarden; Bitwarden is not for CI. Use Doppler or secrets-sync instead.
  • Programmatic AI tokens. Use BWS (a sister product, separate vault) for those.

​
The “AI never touches” boundary

There is no command-line-tool integration, no MCP server, no programmatic bridge in this stack that reads the Bitwarden vault. Reaching it always requires the master password plus a second factor at the keyboard. These are gates an AI subprocess cannot satisfy.

​
Workflow patterns

​
SSH key checkout

  1. Open Bitwarden (browser, native app, or bw unlock).
  2. Copy the private key to ~/.ssh/id_ed25519_<name>.
  3. Load into the agent: ssh-add --apple-use-keychain ~/.ssh/id_ed25519_<name>.
  4. The key file is sensitive but path-denied to AI tools (~/.ssh/id_* is on the Claude Code deny list).

​
Age key escrow restore

  1. Unlock Bitwarden.
  2. Reveal the age key secure note.
  3. Paste into ~/.config/sops/age/keys.txt.
  4. chmod 600 ~/.config/sops/age/keys.txt.
That is the only path to restore a SOPS-encrypted repo after a workstation wipe.

​
Recovery-code restore

  1. Unlock Bitwarden.
  2. Read the relevant service’s recovery codes.
  3. Use one at the service’s recovery prompt; the rest stay in the vault, one-use-per-code.
  4. Generate a fresh set after each use and replace the vault entry.

​
Best practices

  • One Bitwarden organization (or paid Personal vault): collections instead of multiple orgs to avoid invite-revoke churn.
  • TOTP enabled on Bitwarden itself; recovery codes for the recovery codes are printed and stored offline.
  • Master password is unique, length-driven (passphrase preferred), and stored only in human memory plus the offline print.
  • Vault export quarterly: encrypted .json to a secondary location (encrypted disk, USB, or alternate cloud). Test the restore annually.
  • Use a hardware key (FIDO2) as the second factor where Bitwarden supports it.

​
What about a self-hosted Bitwarden?

Vaultwarden (the self-hosted alternative) is on the homelab roadmap. Until then, the canonical vault is the Bitwarden-hosted cloud: auditable, US-region, with their published security posture. The homelab move is a defense-in-depth posture change, not a “this is broken” fix.

​
See also

  • Tools comparison: the four-tier model and why T4 has no programmatic path.
  • OpenBao: the T2 runtime manager whose recovery shares are escrowed here.
  • BWS: the Bitwarden product an AI bridge does interact with.
  • SOPS: the consumer of age-keys escrowed here.
  • Local AI isolation: the path-deny list that blocks SSH-key file reads even after a manual export.