Open-source credential tools for developers: 2026 roundup
Your secrets are scattered: a password manager for logins, .env files, CI
variables, a KMS entry for staging, and the configuration your AI coding
agent can read. None of these talk to each other.
The open-source credential landscape is not one tool but several schools of thought solving different problems; picking the wrong one means fighting your own infrastructure for years. This roundup covers the practical options, the trade each makes, and where it stops working.
The file-and-GPG school: pass and gopass
pass (password-store) keeps each secret in its own GPG-encrypted file under
~/.password-store: standard files, your existing GPG key, git for sync.
That makes it scriptable — every secret is a path, so automation reads
pass show api/example like a file. The cost: shared secrets need a shared
GPG setup, and plaintext round-trips through your process whenever a tool
needs the value.
gopass is a Go rewrite of the same store layout that adds structured output and team sharing — a drop-in with better ergonomics if you already keep a pass store.
Server-based stores: Vault and Bitwarden
HashiCorp Vault is a server you run: central storage, policies, rotation, dynamic credentials, short-lived tokens. That is the right model for a fleet and a heavy load for one developer — now you operate a stateful service, manage its storage backend, and keep its TLS and unseal story straight.
Bitwarden is open source and self-hostable, and its CLI (bw) makes it
usable from scripts. The caveat that bites everyone in automation: the CLI
needs a session token, conventionally exported as BW_SESSION, and it
expires. Your script either re-authenticates or breaks at 2 a.m.
Encrypting the file itself: age and SOPS
age encrypts files and nothing else — no server, no config format, no daemon. A public key encrypts, the private key decrypts; the sane default for one-off archive and transfer cases.
SOPS encrypts the values inside an existing file (YAML, JSON, env) while
leaving the structure readable, with keys from age, GPG, or cloud KMS. A
.env file can stay in git with its secrets turned into ciphertext — the
pick for “secrets in the repo, but encrypted”.
Detection and brokers: gitleaks, and the agent gap
None of the above stops a secret from leaking in the first place. gitleaks scans git history and pull requests, and it is the piece most setups are missing: a pre-commit hook or CI job that refuses to merge a commit containing a key.
The recent gap is AI agents. An agent must run commands that use secrets, and every store above hands the agent the plaintext — putting the secret in the agent’s context window, a place you cannot audit. The credential-broker model injects at the process boundary instead: the agent runs a command through a wrapper, the secret goes into the subprocess environment, and output is sanitized before the agent sees it.
My own implementation is trustless, an MIT-licensed CLI that reads an existing pass or Bitwarden store, so there is no migration. It adds a DLP reverse proxy for LLM calls, OAuth device-flow refresh (Google and Lark), and an append-only audit log — details in the documentation. Code: https://github.com/ikkun1222/trustless.
What this roundup says
- Single developer, everything on one machine: pass or gopass, with git sync.
- Team or fleet, managed credentials: Vault.
- Encrypted secrets inside versioned files: SOPS.
- Catching what already leaked: gitleaks in CI.
- Agents that must use secrets without seeing them: a credential broker.
Start with the smallest piece that covers your actual workflow. Most teams are already close to pass or Bitwarden, and layering detection and a broker on top gets you farther than migrating to a new vault.
Which of these do you already run, and where does it fail you — at rest, in CI, or when an agent needs the secret?