Skip to content

Security model

hushenv is honest about what it does and does not defend against. A security tool that overpromises is worse than one that is clear about its limits.

  • Agents and tools reading secrets from .env. The file holds references, not values.
  • Secrets leaking through git. There is nothing sensitive in the tracked file.
  • Vault theft without the keychain. The vault on disk is ciphertext; without the master key it is useless.
  • Swapping ciphertext between entries. Each value is bound to its name via AES-256-GCM additional authenticated data, so a moved blob fails to decrypt.
  • hushenv run -- env prints that project’s resolved secrets. Per-project grants (coming in v1) will narrow this; it cannot be eliminated while the tool’s job is to inject secrets into programs you choose to run.
  • hushenv get --force from a non-interactive shell. Pair the TTY gate with a Bash(hushenv get*) deny rule in your agent’s settings.
  • Malware running as your user with an unlocked keychain. Anything you can decrypt, code running as you can decrypt. This is true of every local secret manager.

Values are encrypted with AES-256-GCM, a fresh random 96-bit IV per encryption, and the secret’s name as additional authenticated data. The 256-bit master key is generated with a cryptographically secure random source and stored in the OS keychain. On machines without a keychain, it is supplied through the HUSHENV_MASTER_KEY environment variable.

Please report security issues privately through the repository’s security advisory page rather than a public issue.