Resolving secrets at runtime helps only if the agent stops reading them somewhere else — and the file it reads first is .env. Replacing those values with deterministic fakes while it works closes the obvious hole, and unsandboxing puts the real ones back. Check the tier before planning around a feature: the vault and the sandbox are free, the audit log and sharing are not.
An encrypted local vault with an MCP front end. Secrets are stored in an encrypted SQLite database and resolved when a command needs them, so the plaintext never lands in a conversation. A sandbox mode rewrites your .env with deterministic fakes, so an agent reading the file finds nothing real.
- resolve_secret and store_secret — fetch a value at runtime, or encrypt and keep a new one
- list_secrets, which returns names only and never values
- delete_secret for removing one
- sandbox_env and unsandbox_env — swap real .env values for fakes while an agent is working, then restore them
- audit_log for who resolved what and when
- totp_store, totp_code, totp_list and totp_delete for two-factor codes alongside the keys
- create_share_link and receive_share for handing a secret to someone else, encrypted and expiring
- deadman_status and deadman_checkin for a dead man's switch
- sso_status for the single sign-on path
- Backends beyond the local vault: 1Password, Bitwarden, AWS, GCP and Azure, plus plain environment variables
Install it, initialise the vault, and let its setup command write your client configuration. It is fully local — no network involved in the default backend. A biometric gate is available on macOS, which requires authenticating before secrets resolve and expires the session after a short window. The free tier caps how many secrets you can keep; the audit log, sharing, dead man's switch, two-factor codes and the biometric gate are paid.
One command — npm i -g keyblind