the approach of encrypting at rest and only decrypting into environment variables at runtime means the agent never sees the raw secrets even if it reads every file in the project. much better than the current best practice of just hoping your .gitignore is correct and your AI tool respects it.

one suggestion: it would be useful to have a "dry run" mode that shows which env vars would be set without actually setting them. helps verify the config is correct before you realize three services are broken because a typo in the key name.

Kernel keyring support would be the next step?

PASS=$(keyctl print $(keyctl search @s user enveil_key))

I’ve built this in Airut and so far seems to handle all the common cases (GitHub, Anthropic / Google API keys, and even AWS, which requires slightly more work due to the request signing approach). Described in more detail here: https://github.com/airutorg/airut/blob/main/doc/network-sand...

[1]: https://developer.1password.com/docs/environments/

This software has done this for years

A recent project by the creator of mise is related too

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

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.

¹ https://github.com/hodgesmr/agent-fecfile?tab=readme-ov-file...