February 24, 2026
Hide and Sneak: AI vs. .env
Show HN: enveil – hide your .env secrets from prAIng eyes
Hides your app passwords from AI snoops — fans cheer, skeptics yell 'check the logs'
TLDR: Enveil encrypts app secrets so AI coding tools can’t read your .env file, injecting values only at startup. Commenters love the direction but argue logs, printed variables, and proxies may still expose secrets, sparking a lively debate over whether this is a fix or just one layer of defense.
A new tool called enveil strutted onto the stage promising to hide your app secrets from nosy AI coders, and the crowd went wild — and then split into two loud camps. Enveil keeps passwords and keys encrypted, and only slips them into your app right as it starts, so AI assistants like Claude, Copilot, and Cursor don’t rummage through your .env file. One fan waved a big foam finger: “This solves a real problem,” cheering that even with .gitignore, agents still can peek. The irony everyone loved? Enveil was built with Claude Code — an AI helping build a tool to stop AI snooping. You can peek at the GitHub repo.
Then the skeptics crashed the party. “It won’t stop printenv or log leaks,” warned a commenter, pointing out that if your app or terminal prints environment variables, game over. Others chimed in with alternatives: Hashicorp Vault (a popular secrets manager), kernel keyrings (storing secrets in the operating system), and one spicy suggestion to use surrogate credentials behind a proxy so agents only touch fake keys. There were jokes about the “npm example” almost scaring readers away and memes around “technically safe to commit (maybe don’t).” Verdict: the vibe is cautiously excited — with a heavy side of “nice lock, now watch the doors and windows.”
Key Points
- •enveil keeps plaintext secrets out of .env files by using symbolic ev:// references and an encrypted local store.
- •At runtime, enveil prompts for a master password, derives a 256-bit AES key via Argon2id, and decrypts the store using AES-256-GCM.
- •Resolved secrets are injected into the subprocess environment; keys and password bytes are zeroized from memory after use.
- •Each store write uses a fresh 12-byte random nonce; any ciphertext modification causes authentication to fail.
- •Installation is via cargo (once published) or building from source with Rust 1.70+, followed by per-project initialization and interactive secret entry.