Show HN: enveil – hide your .env secrets from prAIng eyes

Original Article ↗ Hacker News Discussion ↗

Role of enveil and .env Encryption

  • enveil is seen as a lightweight way to keep .env files out of plaintext and avoid accidental inclusion in AI context or repos.
  • Some like the usability: encrypt-at-rest, decrypt-into-env at runtime, with password prompts and zeroization of keys.
  • Others argue it only protects against accidental file ingestion, not against a motivated agent or process with code execution.

Critiques of the Approach

  • Multiple comments note that once secrets are in environment variables, any process under the same user (including the agent) can read them via /proc/.../environ, printenv, or logging code.
  • Reviewers point out implementation gaps: not all sensitive data is zeroized, salt isn’t rotated, brute-force resistance is limited, and import loads full plaintext into memory.
  • Several call this “security by annoyance” or “security theater” if the threat is a capable AI agent rather than accidental leaks.

Alternative Patterns and Tools

  • Strong support for proxy / surrogate-credential approaches: the agent only sees a scoped token; a separate proxy injects real secrets (e.g., for GitHub, AWS, OpenAI) and can log, scope, and revoke.
  • Other suggestions: Hashicorp Vault, AWS/GCP secret stores, 1Password (op run / environments), OS keyring, Bitwarden, KMS + DB, or custom reverse proxies.
  • sops + age, dotenvx, envio, fnox, latchkey, varlock, and similar tools are mentioned as more mature ways to manage .env-like workflows.

AI Agents, Sandboxing, and Threat Model

  • Many stress that encrypting .env doesn’t fix the core issue: agents often inherit the developer’s shell, env, filesystem, and network, so they can work around superficial blockers.
  • Reports of agents reading logs, shell history, or config files to recover secrets, and even creatively bypassing policy checks.
  • Suggested mitigations: OS-level sandboxing (Bubblewrap, Seatbelt, separate users/VMs), IP-scoped credentials, MCP-style brokers, surrogate tokens, and strong audit trails.

Debate on .env, Env Vars, and Practices

  • Some are incredulous that production secrets live on dev machines at all and argue for strict separation and non-production-only keys locally.
  • Others admit .env + plaintext secrets are ubiquitous, especially with Docker, CI, and junior developers, and welcome any improvement.
  • Broader point: the real issue is ambient authority and logging (JSONL histories, Docker build args, debug logs), not just the .env file format.