Choosing a secret store for AI agents: decision guide

The secret store is the first security decision most agent setups make, and it is usually made by default: an .env file, because it is what the framework loads. Defaults are fine until the day the agent prints a key into a transcript. Choosing a store deliberately is the difference between a credential problem you can see coming and one you find in a log dump.

What an agent actually requires from a store

Before comparing products, list the requirements that agents impose, because they differ from human use:

• Non-interactive reads. The agent cannot answer a prompt for your master password. Any store you choose must be readable without interactive unlock, or your automation will fail at 2 a.m.
• Injection compatibility. The store should be readable by the tool that injects credentials at the process or transport layer. A store that only a human can open is not an agent store.
• Failure behavior. What happens when the store is locked, the key is gone, or the session expired? You want fail-closed behavior — an error, not a prompt and not an empty value.
• Sync and recovery. If your machine dies, how do you rebuild? This matters more than almost any feature comparison.
• Structure. Flat key-value entries are fine for API keys; OAuth tokens and multi-field service credentials want more structure.

The candidates, weighed against those requirements

Environment files. Readable non-interactively by definition, injection-compatible with everything, and zero setup. The costs: no encryption at rest, no access control, no audit, and the agent inherits every value. Acceptable only for throwaway local experiments.

pass (the unix password manager). A directory of GPG-encrypted files. Reads are non-interactive once the GPG key is unlocked by gpg-agent; it is scriptable by construction; and sync is whatever you make it (a git remote, Syncthing). Structure is a file tree with one secret per file. The weakness is operational: GPG key management, no built-in multi-device story, and nothing that looks like a web vault.

Bitwarden. A full vault with sync, recovery, sharing, and a bw CLI. The agent-relevant complication is session state: the CLI needs a session key on every invocation, and misconfigured automation either fails or triggers an interactive prompt. Tools that wrap bw handle the session key via an environment variable — never argv — and fail closed when the session is invalid.

Vault and cloud KMS. Server-based policy, rotation, and audit. They satisfy every requirement except simplicity: you run a server, integrate a client, and manage a second credential (the one that authenticates to Vault) for the agent to use. Choose them when you have a team, compliance obligations, or an existing platform investment.

The decision flow

1. Single machine, CLI-first, no sync needed? pass.
2. Multiple devices or you already live in a password manager? Bitwarden.
3. Team, compliance, or existing platform? Vault or KMS.
4. Nothing real at stake yet? Keep env files, but put a date on revisiting.

Stores are backends, not solutions

Whichever store you pick, it only solves storage. The agent-facing problem is access and egress: who can read the store, and what happens to values after they are read. trustless treats your store as a backend — pass by default, Bitwarden via the bw CLI — and adds the injection, sanitization, DLP, and audit layers on top, without introducing a new vault format or migration. The store choice and the access-layer choice are independent, and you can change the first without touching the second.

Start with the store that matches your machine and workflow, then close the access gap. What is your primary machine setup — single laptop, or several devices that need the same credentials?