How does this compare with https://dotenvx.com/ ?
Thanks for this! I’ve been looking for a better solution to the .env files and this is ideal, covers all my needs.
Show HN: enveil – hide your .env secrets from prAIng eyes
31–40 of 152 posts
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#32as you have stated 'And yes, this project was built almost entirely with Claude Code with a bunch of manual verification and testing.' this code is not copyright protected, therefore you are not allowed to apply a MIT LICENSE to this project.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#33[dead]
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#34The JSONL logs are the part this doesn't address. Even if the agent never reads .env directly, once it uses a secret in a tool call — a curl, a git push, whatever — that ends up in Claude Code's conversation history at `~/.claude/projects/*/`. Different file, same problem.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#35This suffers from all the usual flaws of env variable secrets. The big one being that any other process being run by the same user can see the secrets once “injected”. Meaning that the secrets aren’t protected from your LLM agent at all. So really all you’re doing is protecting against accidental file ingestion. Which can more easily be done via a variety of other methods. (None of which involve trusting random code…
What is your recommended alternative to .env files?
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#36Is configuration management dead? Sandbox the agent and provision unique credentials to that environment.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#37This suffers from all the usual flaws of env variable secrets. The big one being that any other process being run by the same user can see the secrets once “injected”. Meaning that the secrets aren’t protected from your LLM agent at all. So really all you’re doing is protecting against accidental file ingestion. Which can more easily be done via a variety of other methods. (None of which involve trusting random code…
This is amazing. I agree with your take except "You’re not actually zeroizing the secrets"... I think it is actually calling zeroize() explicitly after use.
Can I get your review/roast on my approach with OrcaBot.com? DM me if I can incentivize you.. Code is available:
https://github.com/Hyper-Int/OrcaBot
enveil = encrypt-at-rest, decrypt-into-env-vars and hope the process doesn't look.
Orcabot = secrets never enter the LLM's process at all. The broker is a separate process that acts as a credential-injecting reverse proxy. The LLM's SDK thinks it's talking to localhost (the broker adds the real auth header and forwards to the real API). The secret crosses a process boundary that the LLM cannot reach.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#38This suffers from all the usual flaws of env variable secrets. The big one being that any other process being run by the same user can see the secrets once “injected”. Meaning that the secrets aren’t protected from your LLM agent at all. So really all you’re doing is protecting against accidental file ingestion. Which can more easily be done via a variety of other methods. (None of which involve trusting random code…
What is your recommended alternative to .env files?
In the context of traditional SaaS, using dynamic secrets loaded at runtime (KMS+Dynamo, etc.).
For agentic tools and pure agents, a proxy is the safest approach. The agent can even think it has a real API key, but said key is worthless outside of the proxy setting.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#39as you have stated 'And yes, this project was built almost entirely with Claude Code with a bunch of manual verification and testing.' this code is not copyright protected, therefore you are not allowed to apply a MIT LICENSE to this project.
> this code is not copyright protected, therefore you are not allowed to apply a MIT LICENSE to this project.
(Not sure if claiming copyright without having it has any legal consequences though.)
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#40I think it would be best if AI agents would honor either .gitignore or .aiexclude ( https://developers.google.com/gemini-code-assist/docs/create... ).
The problem is, you cannot force the agent to do anything. A suitably motivated AI will work around any instructions or controls you put in place.
You are absolutely correct, but I don't need it to be 100% bulletproof.
I'm using opencode as a coding agent and I've added a custom plugin that implements an .aiexclude check (gist (https://gist.github.com/yanosh-k/09965770f37b3102c22bdf5c59a...)) before tool calls. No matter how good the checks are, on the 5th or 6th attempt a determined prompt can make the agent read a secret — but that only happens if reading secrets is the explicit goal. When I'm not specifically prompting it to extract secrets, the plugin reliably prevents the agent from reading them during normal coding work.
My threat model isn't a motivated attacker — it's accidental ingestion.
That's also why I think this should be a built-in feature of coding agents — though I understand the hesitation: if it can't guarantee 100% coverage, shipping it as a native safeguard risks giving users a false sense of security, which may be harder to manage than not having it at all.