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

> SANDBOX YOUR AGENT. Seriously. Run it in a dedicated, isolated environment like a Docker container, a devcontainer, or a VM. Do not run it on your main machine.

> "Docker access = root access." This was OP's critical mistake. Never, ever expose the host docker socket to the agent's container.

> Use a real secrets manager. Stop putting keys in .env files. Use tools like Vault, AWS SSM, Doppler, or 1Password CLI to inject secrets at runtime.

> Practice the Principle of Least Privilege. Create a separate, low-permission user account for the agent. Restrict file access aggressively. Use read-only credentials where possible.

In order to use this developer-replacement, you need accreditation from professional orgs. Maybe the bot can set all this up for you, but then you are almost definitely locked out of your own computer and the bot may not remember its password.

I'm not sure what we've achieved here. If you give it your gmail account, it deletes your emails. If you "sandbox" it, then how is it going to "sort out your inbox"?

It might or might not help veteran devs accelerate some steps, but as with vibeclaw, there's essentially no way to use the tool without "sandboxing" it into uselessness. The pull requests for openclaw are 99% ai slop. There's still no major productivity growth engine in llm's.

... So if the process is expecting a secret on stdin or in a command-line argument, I need to make a wrapper?

The ones that come up most often:

  - Hardcoded keys: const STRIPE_KEY = "sk_live_..."
  - Fallback patterns: process.env.SECRET || "sk_live_abc123" (the AI helpfully provides a default)
  - NEXT_PUBLIC_ prefix on server-only secrets, exposing them to the client bundle
  - Secrets inside console.log or error responses that end up in production logs

It checks for these patterns plus related issues like missing auth on API routes, unvalidated server actions, and hallucinated imports. No LLM, just AST parsing + pattern matching, runs in under 100ms.

On the "read from secret managers directly" option — that's the ideal but the friction is what kills adoption. Most small teams look at Vault's setup guide and go back to .env files. Doppler and Infisical lowered that bar but they're still priced for enterprise ($18/user/mo for Doppler's team plan).

I've been building secr (https://secr.dev) to try to hit the sweet spot: real encryption (AES-256-GCM, envelope encryption, KMS-wrapped keys) with a CLI that feels as simple as dotenv. secr run -- npm start and your app reads process.env like normal. Plus deployment sync so you can secr push --target render instead of copy-pasting into dashboards.

The env variable leakage problem you mention is real and something I don't think any tool fully solves without the proxy approach hardsnow described. But removing the plaintext-file-on-disk vector and the sharing-over-Slack vector covers the majority of real-world leaks.