Multiple AI agents, one credential store: sharing secrets safely

A team of developers runs Claude Code, OpenCode, and a handful of scripts that call the same APIs. Each tool got a .env file at setup time, because that is the path of least resistance. Two months later there are six copies of the production database password in six home directories, the key was rotated in one place but not the others, and nobody can say which copy is current. This is the normal lifecycle of credentials on an agent-heavy machine. The fix is not another tool with another vault format — it is sharing one existing store correctly.

The copy-everywhere failure mode

Copies of secrets fail in predictable ways. Rotation becomes a series of edits across files, and one missed file silently breaks a pipeline. Old copies persist in dotfiles, shell history, and backups long after they are revoked. Every copy is an additional attack surface: any agent that reads a .env file reads all the credentials in it, and whatever it reads enters its context window. The more agents you run, the more copies you create — until the secret is everywhere and current nowhere.

One store, but agents should not read it directly

Centralizing into pass or Bitwarden is the obvious step, and it helps — until agents are told to read the store themselves. An agent that runs pass show to fetch a key receives the plaintext in tool output, which lands in context and leaves with the next model request. Worse, an agent with store access can list every entry that exists, and the inventory of what you hold is sensitive on its own. A shared store is the right backend, but the agent must never be the reader.

The broker pattern: names in, values out

A credential broker sits between the agents and the store. Each agent references a secret by name — in a command invocation, a config value, or a proxy endpoint — and the broker resolves the value at the layer where it is used: subprocess environment, HTTP header, or query parameter. trustless run -s <key> -- <cmd> injects the secret into the child process and scrubs stdout and stderr, including base64 and URL-encoded variants, so tool output cannot carry the value into context. The agent gets the use of the credential without a copy it can read, print, or store.

Sharing OAuth tokens without sharing secrets

OAuth is where shared credentials get dangerous, because refresh tokens are long-lived and reusable. The broker runs the RFC 8628 device flow itself and keeps the refresh token; the token is rotated after a single use, so a stolen copy expires immediately. Agents receive only short-lived access credentials, and a reauth-required state is reported instead of silently retrying an invalid grant. The secret is shared across agents through the store, but no agent ever holds the token.

Auditing shared access

When several agents use the same store, you need to know who used what. The audit log records each event — injection, denial, OAuth refresh, failure — as append-only JSONL at ~/.local/state/trustless/audit.jsonl, with 0600 permissions and SIGHUP reopen for log rotation, or it can write to journald. It never contains token values, only event types and metadata. The setup wizard imports existing .env files into the store, scanning directories, parsing KEY=VALUE lines, and backing up the originals; trustless doctor then checks GPG validity, store health, and agent integration with a --fix flag. trustless reads your existing pass or Bitwarden store — no migration, no new format — and the command reference covers every mode.

Every agent on your machine is one .env read away from every other agent’s secrets. How many copies of your production credentials exist right now — and who is accountable for each one?