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

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?