81–90 of 152 posts
This doesn’t really fix that it can echo the secrets and read the logs. `enveil run — printenv`
Of course that's only a defense against accidents. Nothing prevents encoding base64 or piping to disk.
https://github.com/getsops/sops This software has done this for years
Has done "wat" for years? I use sops for encrypting yaml files. But how does it replace .env or other ENV var setters/holders?
The 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.
The cases that bite me:
1. Docker build args — tokens passed to Dockerfiles for private package installs live in docker-compose.yml, not .env. No .env-focused tool catches them.
2. YAML config files with connection strings and API keys — again, not .env format, invisible to .env tooling.
3. Shell history — even if you never cat the .env, you've probably exported a var or run a curl with a key at some point in the session.
The proxy/surrogate approach discussed upthread seems like the only thing that actually closes the loop, since it works regardless of which file or log the secret would have ended up in.
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.
This 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?
At the simplest level, keeping .env-ish files, use sops + age [1] or dotenvx [2] (or similar) to encrypt just the values. You keep the .env file approach, the actual secrets are encrypted, and now you can check the file in and track changes without leaking your secrets. You still have the env variable problems.
There are some options that'll use virtual files to get your secrets from a vault to your process's env variables, or you can read the secrets from a secret manager yourself into env variables, but that feels like more complexity without a lot more gain to me. YMMV.
You could use a regular password manager (your OS's keychain, 1Password and its ilk, etc) if you're just working on your own. Also in the more complexity without much gain category for me.
If you want to use a local file on disk, you could use a config file with locked down permissions, so at least it's not readable by anything that comes along. ssh style.
Better is to have your code (because we're talking about your code, I assume) read from secret managers itself. Whether that's Bitwarden, AWS / GCP / Azure (well, maybe not Azure), Hashicorp, or one of the many other enterprisey options. That way you get an audit trail and easy rotation, plus no env variables and no plain text at rest. You can still leak them, but you have fewer ways to do so.
Speaking of leaking accidentally, the two most common paths: Logging output and Docker files. The first is self explanatory, though don't forget about logging HTTP requests with auth headers that you don't want exposed. The second is missed by a lot of people. If you inject secrets into your Dockerfile via `ARG` or `ENV` that gets baked into the image and is easy to get back out. Use `--mount-type=secret` etc. (Never use the old Docker base64 stored secrets in config. That's just silly.)
There are other permutations and in-between steps, these are just the big ones. Like all security stuff, the details really depend on your specific needs. It is easy to say, though, that plain text .env files injected into env variables are at the bad end of the spectrum. Passing the secrets in as plain text args on the command line is worse, so at least you're not doing that!
1: https://github.com/getsops/sops / https://github.com/FiloSottile/age
https://github.com/getsops/sops This software has done this for years
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...
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!