pass vs Bitwarden for AI agent credentials: which works with agents

2026-08-16 · 3 min read

When you decide to stop putting API keys in .env files and start keeping them in a real secret store, the first question is: which store? For AI agent setups, the two realistic candidates are pass (the unix password manager) and Bitwarden. Both work — but they make different trade-offs, and the right choice depends on your existing workflow.

pass: the unix-native store

pass is a shell script over a directory of GPG-encrypted files. That’s the whole architecture.

Strengths for agent use:

  • Zero infrastructure. No server, no sync, no daemon. The store is files.
  • Scriptable by nature. Everything is files and GPG, so tooling around it is trivial — a broker reads a path, decrypts, injects.
  • GPG is already everywhere. If you sign commits or use SSH with GPG keys, the tooling is already installed.
  • Transparent. pass show <name> and you see exactly what a tool will get.

Weaknesses:

  • Sync is your problem. No built-in sync across machines; you roll your own (git remote, Syncthing, etc.).
  • No native web vault / mobile app ecosystem. The CLI is the interface. For a single-user developer setup, that’s fine.

Bitwarden: the managed vault

Bitwarden is a full password manager: client apps, web vault, sync, sharing, and a CLI (bw) that agents can drive.

Strengths for agent use:

  • Sync and recovery built in. Vault is on your terms (Bitwarden cloud or self-hosted Vaultwarden).
  • Rich entry model. Login items with URIs, fields with hidden values, notes — better structured than a flat file tree.
  • Access control. Collections and organizations, if you ever share credentials with a team.

Weaknesses:

  • Session management is fiddly. The bw CLI needs a session key (BW_SESSION) that must be passed to every invocation — get it wrong and the tool either fails or prompts interactively. This is the classic integration trap for agent tooling.
  • More moving parts. Server sync, unlock state, API rate limits.

What the agent setup actually needs

For a credential broker pattern — the agent references by name, the broker resolves at process/transport time — the store is an implementation detail. What matters is that the broker can read it non-interactively:

  • With pass: the broker decrypts with the GPG key; no session state to manage.
  • With Bitwarden: the broker unlocks once, holds the session key in an environment variable (never argv — that would leak it into process lists), and fails closed when the session is invalid. A dedicated unlock command handles the interactive step.

Both backends can power the same injection, sanitization, and DLP layers. The pragmatic rule: use pass if you’re a single-machine, CLI-first user; use Bitwarden if you already live in it or need sync across devices.

trustless supports both as first- class backends — pass by default, Bitwarden via the bw CLI with BW_SESSION handling and fail-closed behavior. The backend design is documented in the architecture page.

Whichever store you pick, the goal is the same: the agent gets access, never the plaintext. Which one are you already using — or are you still on .env?

← Blog