Bitwarden vault

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: no CLI 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 — including 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 CLI 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 — 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.