https://github.com/getsops/sops
This software has done this for years
Show HN: enveil – hide your .env secrets from prAIng eyes
11–20 of 152 posts
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#12https://github.com/jdx/fnox
A recent project by the creator of mise is related too
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#13Sometimes I need to give Claude Code access to a secret to do something. (e.g. Use the OpenAI API to generate an image to use in the application.) Obviously I rotate those often. But what is interesting is what happens if I forget to provide it the secret. It will just grep the logs and try to find a working secret from other projects/past sessions (at least in --dangerously-skip-permissions mode.)
What software do you use that logs credentials?
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#14this won't solve the problem.
Instead you need to do what hardsnow is doing: https://news.ycombinator.com/item?id=47133573
Or what the https://github.com/earendil-works/gondolin is doing
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#15Alternative, and more robust approach is to give the agent surrogate credentials and replace them on the way out in a proxy. If proxy runs in an environment to which agent has no access to, the real secrets are not available to it directly; it can only make requests to scoped hosts with those. I’ve built this in Airut and so far seems to handle all the common cases (GitHub, Anthropic / Google API keys, and even AWS,…
How does this work with SSL? Do you need to provision certs on the agent VM?
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#16Sometimes I need to give Claude Code access to a secret to do something. (e.g. Use the OpenAI API to generate an image to use in the application.) Obviously I rotate those often. But what is interesting is what happens if I forget to provide it the secret. It will just grep the logs and try to find a working secret from other projects/past sessions (at least in --dangerously-skip-permissions mode.)
What software do you use that logs credentials?
Claude Code does it. Check out the JSONL files.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#17In the vein of related work, there is https://github.com/imbue-ai/latchkey which injects secrets into cURL commands issued by your agent.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#18Alternative, and more robust approach is to give the agent surrogate credentials and replace them on the way out in a proxy. If proxy runs in an environment to which agent has no access to, the real secrets are not available to it directly; it can only make requests to scoped hosts with those. I’ve built this in Airut and so far seems to handle all the common cases (GitHub, Anthropic / Google API keys, and even AWS,…
How does this work with SSL? Do you need to provision certs on the agent VM?
Yep - requires the client to trust the SSL cert of the proxy. Cooperative clients that support eg HTTP_PROXY may be easier to support, but for Airut I went for full transparent mitmproxy. All DNS A requests resolve to the proxy IP and proxy cert is injected to the container where Claude Code runs as trusted CA. As a bonus this closes DNS as potential exfiltration channel.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#19> can read files in your project directory, which means a plaintext .env file is an accidental secret dump waiting to happen
It's almost like having a plaintext file full of production secrets on your workstation is a bad fucking idea.
So this is apparently the natural evolution of having spicy autocomplete become such a common crutch for some developers: existing bad decisions they were ignoring cause even bigger problems than they would normally, and thus they invent even more ridiculous solutions to said problems.
But this isn't all just snark and sarcasm. I have a serious question.
Why, WHY for the love of fucking milk and cookies are you storing production secrets in a text file on your workstation?
I don't really understand the obsession with a .ENV file like that (there are significantly better ways to inject environment variables) but that isn't the point here.
Why do you have live secrets for production systems on your workstation? You do understand the purpose of having staging environments right? If the secrets are to non-production systems and can still cause actual damage, then they aren't non-production after all are they?
Seriously. I could paste the entirety of our local dev environment variables into this comment and have zero concerns, because they're inherently to non-production systems:
- payment gateway sandboxes;
- SES sending profiles configured to only send mail to specific addresses;
- DB/Redis credentials which are IP restricted;
For production systems? Absolutely protect the secrets. We use GPG'd files that are ingested during environment setup, but use what works for you.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#20I think it would be best if AI agents would honor either .gitignore or .aiexclude (https://developers.google.com/gemini-code-assist/docs/create...).