Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

141–150 of 152 posts

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

#141

Post by SOLAR_FIELDS »

chrismatic wrote: post #82
berkes wrote: post #77

Earlier quoted context omitted.

Has done "wat" for years? I use sops for encrypting yaml files. But how does it replace .env or other ENV var setters/holders?

Sops can natively handle .env files. All you need to apply them to your process is a small wrapper script that sources the decrypted file before invoking your command.

There's a lot of gotcha bundled into this statement. It is true what you say, but it also hides away the nightmare of shell escaping bullshit that comes with the .env format the second you have to have some sort of transformation on the data that is orthogonal to the normal decryption path. I think that now they have a better story around some of the edge cases but if you go into SOPS you will see several issues around how the .env file format is just a complete nightmare with crazy escaped values such as a Google Service Account JSON.

The way I got around this on my own stuff is just to have a policy that all sops secrets have to be base64 encoded before the encryption hits them. That seems to solve basically every piping issue you could hit. Works super well with kubernetes, who supports native base64 encoded secrets, so you just take the value and inject it in, using data: instead of stringData: in the manifest of the created secret.

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

#142

Post by hdjrudni »

toraway wrote: post #121
andai wrote: post #90

Earlier quoted context omitted.

Your concerns are not entirely unfounded. https://www.reddit.com/r/ClaudeAI/comments/1r186gl/my_agent_... I have noticed similar behavior from the latest codex as well. "The security policy forbid me from doing x, so I will achieve it with a creative work around instead..." The "best" part of the thread is that Claude comes back in the comments and insults OP a second time!

Yep, I see both Codex and Opus routinely circumvent security restrictions without skipping a beat (or bothering to ask for permission/clarification). Usually after a brief, extremely half-hearted ethical self-debate that ends with "Yes doing Y is explicitly disallowed by AGENTS.md and enforced by security policy but the user asked for X which could require Y. Therefore, writing a one-off Python script to bypass termi…

Honestly, I think this the correct behavior.

If it's technically possible for an agent to circumvent a security policy, it should.

Telling it not do something via AGENTS.md was never secure. This is just an expedient way of pointing out all the flaws in your setup. And if it's not even doing it for nefarious reasons, just trying to do what you asked of it, I think it's fair.

I've even found it genuinely helpful. I've sandboxed my Codex so it can't run certain things. Things I'd actually like it to run but I've restricted it too much, so it finds clever ways of doing it anyway.

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

#143

Post by ivannovazzi »

The root fix is avoiding .env files entirely. We built KeyEnv (keyenv.dev) with this in mind: a CLI-first secrets manager where you run `keyenv run -- npm start` and secrets are injected as env vars at runtime without ever touching disk. No .env file means nothing for an AI agent (or anyone with filesystem access) to read.

enveil is a good defense-in-depth layer for existing .env workflows. But if you can change the habit, removing the file at the source is cleaner.

Disclosure: I'm one of the builders of KeyEnv.

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

#144

Post by berkes »

Arrowmaster wrote: post #138
berkes wrote: post #79

Earlier quoted context omitted.

It suprises me how often I see some Dockerfile, Helm, Kubernetes, Ansible etc write .env files to disk in some production-alike environment. The OS, especially linux - most common for hosting production software - is perfectly capable of setting and providing ENV vars. Almost all common devops and older sysadmin tooling can set ENV vars. Really no need to ever write these to disk. I think this comes from unaware deve…

The problem isn't the .env file itself but using environment variables at all to pass secrets is insecure.

I strongly disagree.

Environment variables are -by far- the securest AND most practical way to provide configuration and secrets to apps.

Any other way is less secure: files on disk, (cli)arguments, a database, etc. Or about as secure but far more complex and convoluted. I've seen enterprise hosting with a (virtual) mount (nfs, etc) that provides config files - read only - tight permissions, served from a secure vault. A lot of indirection for getting secrets into an app that will still just read them plain text. More secure than env vars? how?

Or some encrypted database/vault that the app can read from using - a shared secret provided as env var or on-disk config file.

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

#145

Post by ivannovazzi »

Neat framing around the AI angle. A complementary approach is removing .env files from the workflow entirely rather than masking them — so there's nothing to leak to begin with.

We built KeyEnv (https://keyenv.dev) for exactly that: the CLI pulls AES-256 encrypted secrets at runtime so .env files never exist locally. `keyenv run -- npm start` and secrets are injected as env vars, then gone.

The tradeoff is it requires a network hop and team buy-in, whereas enveil is local. Different threat models — enveil protects secrets already on disk from AI tools, KeyEnv prevents them from touching disk at all.

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

#146

Post by andai »

hdjrudni wrote: post #142
toraway wrote: post #121

Earlier quoted context omitted.

Yep, I see both Codex and Opus routinely circumvent security restrictions without skipping a beat (or bothering to ask for permission/clarification). Usually after a brief, extremely half-hearted ethical self-debate that ends with "Yes doing Y is explicitly disallowed by AGENTS.md and enforced by security policy but the user asked for X which could require Y. Therefore, writing a one-off Python script to bypass termi…

Honestly, I think this the correct behavior. If it's technically possible for an agent to circumvent a security policy, it should . Telling it not do something via AGENTS.md was never secure. This is just an expedient way of pointing out all the flaws in your setup. And if it's not even doing it for nefarious reasons, just trying to do what you asked of it, I think it's fair. I've even found it genuinely helpful. I'v…

I just gave it its own user, and run it (and all AIs) in yolo mode.

So they are free to nuke themselves and each other, but cannot touch my files.

For most people I tell them to just get a dedicated device, which is less annoying and (I think?) more secure. Like you can literally give it root on a $3 VPS and what's the worst case scenario? It bricks itself and you reset the VPS? (Or installs crypto miners, but I think it can do that without root :)

My favorite option for a dedicated agent device so far is the $50 thinkpad, which gets you rpi-ish price, better performance, and the screen and keyboard included.

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

#147

Post by tetha »

toraway wrote: post #121
andai wrote: post #90

Earlier quoted context omitted.

Your concerns are not entirely unfounded. https://www.reddit.com/r/ClaudeAI/comments/1r186gl/my_agent_... I have noticed similar behavior from the latest codex as well. "The security policy forbid me from doing x, so I will achieve it with a creative work around instead..." The "best" part of the thread is that Claude comes back in the comments and insults OP a second time!

Yep, I see both Codex and Opus routinely circumvent security restrictions without skipping a beat (or bothering to ask for permission/clarification). Usually after a brief, extremely half-hearted ethical self-debate that ends with "Yes doing Y is explicitly disallowed by AGENTS.md and enforced by security policy but the user asked for X which could require Y. Therefore, writing a one-off Python script to bypass termi…

> The primary motivating factor by far for these CLI agents always seems to be expedience in completing the task (to a plausible definition of "completed" that justifies ending the turn and returning to the user ASAP).

Curiously enough, step one of becoming a good system operator is to learn how to do things. Step two is learning when not to do things and how to deal with a user trying to force you to do things. And step three is learning how to do things you should not do, just very carefully. It can be a confusing job.

But that's why any kind of AI agent stays very far away from any important production access. People banging configs in uncontrolled ways until something beneficial happens is enough of a problem already.

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

#148

Post by Arrowmaster »

berkes wrote: post #144
Arrowmaster wrote: post #138

Earlier quoted context omitted.

The problem isn't the .env file itself but using environment variables at all to pass secrets is insecure.

I strongly disagree. Environment variables are -by far- the securest AND most practical way to provide configuration and secrets to apps. Any other way is less secure: files on disk, (cli)arguments, a database, etc. Or about as secure but far more complex and convoluted. I've seen enterprise hosting with a (virtual) mount (nfs, etc) that provides config files - read only - tight permissions, served from a secure vaul…

Disagree, the best way to pass secrets is by using mount namespaces (systemd and docker do this under /run/secrets/) so that the can program can access the secrets as needed but they don't exist in the environment. The process is not complicated, many system already implement it. By keeping them out of ENV variables you no longer have to worry about the entire ENV getting written out during a crash or debugging and exposing the secrets.

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

#149

Post by berkes »

Arrowmaster wrote: post #148
berkes wrote: post #144

Earlier quoted context omitted.

I strongly disagree. Environment variables are -by far- the securest AND most practical way to provide configuration and secrets to apps. Any other way is less secure: files on disk, (cli)arguments, a database, etc. Or about as secure but far more complex and convoluted. I've seen enterprise hosting with a (virtual) mount (nfs, etc) that provides config files - read only - tight permissions, served from a secure vaul…

Disagree, the best way to pass secrets is by using mount namespaces (systemd and docker do this under /run/secrets/) so that the can program can access the secrets as needed but they don't exist in the environment. The process is not complicated, many system already implement it. By keeping them out of ENV variables you no longer have to worry about the entire ENV getting written out during a crash or debugging and e…

How does a mounted secret (vault) protect against dumping secrets on crash or debugging?

The app still has it. It can dump it. It will dump it. Django for example (not a security best practice in itself, btw) will indeed dump ENV vars but will also dump its settings.

The solution to this problem lies not in how you get the secrets into the app, but in prohibiting them getting out of it. E.g. builds removing/stubbing tracing, dumping entirely. Or with proper logging and tracing layers that filter stuff.

There really is no difference, security wise, between logger.debug(system.env) and logger.debug(app.conf)

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

#150

Post by gverrilla »

ctmnt wrote: post #117
gverrilla wrote: post #74

In Claude Code I think I can solve this with simply a rule + PreToolUse hook. The hook denies Reading the .env, and the rule sets a protocol of what not do to, and what to do instead :`$(grep KEY_NAME ~/.claude/secrets.env | cut -d= -f2-)`. When would something like that not work?

You can just set `"deny": ["Read(./.env)", "Read(./.env.*)"]` if you want to keep it simple and rely on Claude's own mechanisms.

last time I tried allowing/denying tool usage I found a lot of bugs, so I stay away from that as much as I can. Opus is quite smart, rules/ work quite well for things like this in my experience. The way I see it, sandboxing is only really important for people doing specific stuff like pentests, games, adversarial stuff, etc.
Post reply on HN