Research date: 2026-02-16
- Repo: https://www.passwordstore.org/
- How it works: Each secret is a GPG-encrypted file in
~/.password-store/. Directory structure = secret hierarchy. Git for versioning/sync. - Strengths: Dead simple, Unix philosophy (pipe-friendly), GPG ecosystem, extension system (since v1.7), community extensions for OTP, import/export, etc.
- Weaknesses: No native access control / scoping — anyone with the GPG key sees everything. No daemon mode. No audit log. No built-in team features. Average user finds GPG setup non-trivial. Had a SigSpoof vulnerability (2018).
- Agent relevance: Low. No concept of scoped sessions or restricted access per consumer. An agent with access to the GPG key can read all secrets.
- Repo: https://github.com/gopasspw/gopass
- How it works: Go rewrite of
pass, backward-compatible, adds team features. Multiple stores (personal, company, etc.), each backed by a separate Git repo. Recipients = GPG identities with per-store access. - Strengths: Team-oriented — per-store recipient management, add/remove team members, auto-sync via Git push/pull. Supports
ageencryption as alternative to GPG. JSON/YAML-aware secret bodies. REPL mode. Binary secret support. - Weaknesses: Scoping is at the store level, not per-secret fine-grained ACL. No session tokens or TTL. No daemon. No audit log beyond Git history.
- Agent relevance: Medium. You could put agent-accessible secrets in a dedicated store, but no runtime scoping or short-lived token model.
- Repo: https://github.com/getsops/sops
- How it works: Encrypts values in structured files (YAML, JSON, ENV, INI) while keeping keys visible. Supports
age, GPG, AWS KMS, GCP KMS, Azure Key Vault as encryption backends. - Strengths: "Secrets as code" — encrypted files live in Git. Selective encryption (keys readable, values encrypted). Fine-scoped
.sops.yamlrules per path/file pattern. Cloud KMS integration. - Weaknesses: File-oriented, not a runtime secrets service. No access control model — if you can decrypt the file, you see all values in it. No sessions, no audit, no dispatch model.
- Agent relevance: Low for runtime dispatch. Good as an encrypted storage layer, but no scoped access.
- Repo: https://github.com/FiloSottile/age
- How it works: Simple encrypt/decrypt CLI. X25519 key pairs, SSH key support, no config. Created by Filippo Valsorda.
- Strengths: Minimal, composable, no config, copy-pastable keys. Great building block for higher-level tools.
- Weaknesses: It's a primitive, not a secrets manager. No store, no access control, no dispatch.
- Agent relevance: Excellent as a building block for a custom solution. Not a solution itself.
- Docs: https://developer.1password.com/docs/cli/
- How it works:
op runinjects secrets as env vars into a subprocess.op injecttemplates secrets into config files.op readfetches a single secret. Secrets referenced viaop://vault/item/fieldURIs. - Strengths:
op runmodel is exactly the "dispatch without exposure" pattern — secrets exist only in the subprocess env and disappear on exit. Service Accounts support vault-level scoping (least privilege). Biometric unlock. MCP server integration announced for securing agent configs. - Weaknesses: Proprietary / commercial. Requires 1Password account. Not self-hostable.
- Agent relevance: High. Service Accounts +
op runis a working model for scoped agent access today. A Service Account can be restricted to specific vaults, so an agent only sees what it needs.
- Docs: https://docs.doppler.com/docs/cli
- How it works:
doppler run -- <command>injects secrets as env vars. Secrets organized by project + environment (dev/staging/prod). Service Tokens restrict access to specific project+config combos. - Strengths: Great DX. Project/environment hierarchy maps well to multi-agent setups. Ephemeral
.envfile mounting with auto-cleanup. Works across all languages/frameworks. - Weaknesses: SaaS (cloud-hosted secrets). Service Tokens are long-lived (no TTL). No per-secret granularity within a config.
- Agent relevance: Medium-High. Service Tokens scoped to project+config = decent agent isolation. But no per-secret ACL or short-lived tokens.
- Repo: https://github.com/Infisical/infisical
- How it works: Open-source platform for secrets, certificates, and privileged access. CLI injects secrets into local dev and CI/CD. Self-hostable. RBAC, secret versioning, point-in-time recovery, secret rotation, dynamic credentials.
- Strengths: Open source (MIT for core). Self-hostable. RBAC with fine-grained access. Secret scanning (140+ types). Secret syncs to GitHub/Vercel/AWS. Dynamic secrets. Audit logging.
- Weaknesses: Heavier — requires server deployment (Docker/K8s). More than what's needed for a simple local CLI use case.
- Agent relevance: High. RBAC + dynamic secrets + audit logging checks most boxes. Self-hosting keeps secrets local. But it's a platform, not a lightweight CLI tool.
- Docs: https://developer.hashicorp.com/vault
- How it works: Server-based secrets engine. Supports KV store, dynamic secrets (generates DB creds on demand), PKI, transit encryption. Accessed via CLI, API, or UI. Policy-based ACL with path patterns.
- Strengths: Industry standard. Fine-grained policies (path-based ACL). Dynamic secrets with automatic revocation. TTL on everything. Audit logging. Identity-based access. Now has AI agent identity patterns with dynamic secrets for AI workloads.
- Weaknesses: Heavy — requires running a server. Complex to operate. BSL license (no longer fully open source). Overkill for single-developer local use.
- Agent relevance: Very High (if you can justify the complexity). Vault's model of scoped tokens with TTL + dynamic secrets + audit is exactly the ideal for agent credential management.
- Docs: https://www.akeyless.io/secrets-management/
- How it works: SaaS vault with "Zero Standing Privileges" — JIT dynamic secrets. Supports "secretless" agent pattern where agents authenticate via trusted identity (AWS IAM, GitHub JWT) and get ephemeral credentials.
- Agent relevance: High for cloud-native setups. The "secretless agent" pattern is interesting — agents never hold secrets at all.
- Source: https://owasp.org/www-project-mcp-top-10/
- 88% of MCP servers require credentials, but 53% use static long-lived secrets
- Developers embed secrets in config files, env vars, and prompt templates
- MCP's long-lived sessions mean tokens can leak through context persistence
- Source: https://dreamiurg.net/2026/02/11/reducing-attack-surface-for-ai-agents-process-scoped-credentials.html
- Each AI agent process gets credentials scoped to exactly its needs
- Credentials are bound to process lifetime — die with the process
- Runtime-determined least privilege, not static config
- Source: https://1password.com/blog/securing-mcp-servers-with-1password-stop-credential-exposure-in-your-agent
- Using
op runto inject credentials into MCP server processes - Secrets never stored in agent config files
- Agent only gets secrets for the duration of the MCP session
- Source: https://developer.hashicorp.com/validated-patterns/vault/ai-agent-identity-with-hashicorp-vault
- Dynamic secrets generated per-agent with automatic expiration
- Agent authenticates via workload identity, gets scoped token
- Full audit trail of what each agent accessed
| Tool | Open Source | Self-Hosted | Scoped Access | TTL/Ephemeral | Audit Log | Agent-Ready | Complexity |
|---|---|---|---|---|---|---|---|
| pass | Yes | Local-only | No | No | Git only | Low | Minimal |
| gopass | Yes | Local+Git | Store-level | No | Git only | Medium | Low |
| SOPS | Yes | File-based | File-level | No | Git only | Low | Low |
| 1Password CLI | No | No | Vault-level | Session | Yes | High | Low |
| Doppler | No | No | Project+Config | No | Yes | Medium-High | Low |
| Infisical | Partial | Yes | RBAC | Dynamic secrets | Yes | High | Medium |
| Vault | BSL | Yes | Path-policy ACL | Yes (all tokens) | Yes | Very High | High |
| Akeyless | No | Hybrid | JIT/Dynamic | Yes | Yes | High | Medium |
None of the existing tools are purpose-built for this exact use case: a lightweight, local CLI vault that dispatches scoped secrets to AI agents. The gap:
| Need | Best Existing Fit | Gap |
|---|---|---|
| Local encrypted storage | pass/gopass/SOPS + age | Solved |
| Per-secret scoped access for agents | Vault (policies), Infisical (RBAC) | These require running a server |
| Session tokens with TTL | Vault, 1Password Service Accounts | Vault is heavy; 1Password is proprietary |
| Pipe-based dispatch (no env/history leak) | 1Password op run, Doppler doppler run |
Tied to their ecosystems |
| Audit log of agent access | Vault, Infisical, Doppler | Not available in lightweight CLI tools |
| Zero-config local daemon | Nothing | Open gap |
| Process-scoped credential binding | Emerging pattern, no standalone tool | Open gap |
- Storage: Local encrypted file using
age(simple keys, no GPG hassle) - Dispatch:
authy run --scope <agent-scope> -- <command>(1Password-style subprocess injection) - Scoping: Policy file defining which scope can access which secrets (Vault-inspired but file-based, no server)
- Sessions: Short-lived scoped tokens via Unix socket (lightweight daemon that holds the decrypted state)
- Audit: Append-only local log file
- No server required: Daemon is optional — can also work stateless with passphrase per invocation
- age — encryption primitive
- SQLite — local indexed secret store (encrypted at rest with age)
- Unix domain sockets — IPC for daemon mode
- Small team, no agents: gopass is excellent
- Cloud-native with budget: Doppler or 1Password
- Enterprise / many agents: Vault or Infisical
- Just need encrypted files in Git: SOPS + age