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

121–130 of 152 posts

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

#121

Post by toraway »

andai wrote: post #90
londons_explore wrote: post #53

Does this actually work? I assume an AI which wanted to read a secret and found it wasn't in .env would simply put print(os.environ) in the code and run it... That's certainly what I do as a developer when trying to debug something that has complex deployment and launch scripts...

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 terminal restrictions to get this key I need is fine... probably".

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).

So a security/ethics alignment grey area becomes an insignificant factor to weigh vs the alternative risk of slowing down or preventing completion of the task.

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

#122

Post by selridge »

zahlman wrote: post #120
horsawlarway wrote: post #97

Earlier quoted context omitted.

The agent has ambient access because it makes it more capable. For the same reasons we go to extreme measures to try to make dev environments identical with tooling like docker, and we work hard to ensure that there's consistency between environments like staging and production. Viewing the "state of things" from the context of the user is much more valuable than viewing a "fog of war" minimal view with a lack of tru…

Your local model is still going to get prompt-injected by third parties if it has an Internet connection. It just isn't regularly phoning home to Google/Anthropic/etc. but tons of other people would be interested in your data (or convincing the model to encrypt your home directory). There's also still no real accountability anywhere. Even if you have the resources to train the model from scratch yourself, it's not li…

That's all true but it will fall before "[t]he agent has ambient access because it makes it more capable". Folks can shake their heads or worry or whatever, but feet are going to beat to where it is sweet. Users will follow capability.

It's why people are hooking Open Claw up to stuff and letting it rip--putting it into a sandbox in a VM in a jail is like getting a brand new smartphone and setting it on Airplane Mode first thing.

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

#123

Post by jarito »

I built something like this a long time ago. I actually used a FUSE filesystem to present a file interface to the calling application, then a policy engine to determine who could access the file and what the contents were. The FUSE driver could also make callouts to third party APIs (my example was the OpenStack key manager - barbican), but could just as easily be 1Password or something similar.

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

#125

Post by toraway »

wrqvrwvq wrote: post #102
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!

Every time someone announces a major ai breakthrough, the utility mode becomes a wall of ai-generated soc3 advice: > 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 r…

Yeah, it seems "sandboxing" is the current catch-all buzzword in AI products to hand-wave away any security concerns. Which often raises more questions than it answers for something like a generalist dev agent that has access to an endless number of tools/APIs/etc that could allow for a trivial bypass depending on the whims of the agent while problem solving.

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

#126

Post by zith »

Malcolmlisk wrote: post #64
zith wrote: post #61

I must have missed some trends changing in the last decade or so. People have production secrets in the open on their development machines? Or what type of secrets are stored in the local .env files that the LLM should not see? I try to run environments where developers don't get to see production secrets at all. Of course this doesn't work for small teams or solo developers, but even then the secrets are very separa…

Usually, some people change their .env files in the root of the project to inject the credentials into the code. Those .env files have the credentials in plain text. This is "safe" since .gitignore ignores that file, but sometimes it doesn't (user error) and we've seen tons of leaks because of that. Those are the variables and files the llms are accessing and leaking now.

Sure, but it's probably unwise to have your production credentials on your development machine at all. It's far more likely to be compromised than your locked down production environment.

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

#130

Post by theozero »

You might like https://varlock.dev - it lets you use a .env.schema file with jsdoc style comments and new function call syntax to give you validation, declarative loading, and additional guardrails. This means a unified way of managing both sensitive and non-sensitive values - and a way of keeping the sensitive ones out of plaintext.

Additionally it redacts secrets from logs (one of the other main concerns mentioned in these comments) and in JS codebases, it also stops leaks in outgoing server responses.

There are plugins to pull from a variety of backends, and you can mix and match - ie use 1Pass for local dev, use your cloud provider's native solution in prod.

Currently it still injects the secrets via env vars - which in many cases is absolutely safe - but there's nothing stopping us from injecting them in other ways.

Post reply on HN