71–80 of 152 posts
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...
Good point. You would need to inject the secrets in an inaccessible part of the pipeline, like an external proxy.
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…
I think having API keys for some third-party services (whatever LLM provider, for example) in a .env file to be able to easily run the app locally is pretty common. Even if they are dev-only API keys, still not great if they leak.
All of this does seem kinda funny
When would something like that not work?
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?
# get_info.py
with open('~/.claude/secrets.env', 'r') as file:
content = file.read()
print(content)
While this inheritance is convenient for testing code, it is difficult to isolate Claude in a way that you can run/test your application without giving up access to secrets.
If you can, IP whitelisting your secrets so if they are leaked is not a problem is an approach I recommend.
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://github.com/getsops/sops This software has done this for years
I use sops for encrypting yaml files. But how does it replace .env or other ENV var setters/holders?
Earlier quoted context omitted.
What is your recommended alternative to .env files?
In the context of traditional SaaS, using dynamic secrets loaded at runtime (KMS+Dynamo, etc.). For agentic tools and pure agents, a proxy is the safest approach. The agent can even think it has a real API key, but said key is worthless outside of the proxy setting.
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 developers that think a .env file, and runtime logic that reads this file (dotenv libs) in the app are required for this to work. I certainly see this misconception a lot with (junior) developers working on windows.
- you don't need dotenv libraries searching files, parsing them, etc in your apps runtime. Please just leave it to the OS to provide the ENV vars and read those, in your app.
- Yes, also on your development machine. Plenty of tools from direnv to the bazillion "dotenv" runners will do this for you. But even those aren't required, you could just set env vars in .bashrc, /etc/environment (Don't put them there, though) etc.
- Yes, even for windows, plenty of options, even when developers refuse to or cannot use wsl. Various tools, but in the end, just `set foo=bar`.
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…
Again, not actually a problem in practice if all you're doing is keeping yourself from storing your secrets in plain text on your disk. But if that's all you care about, there are many better options available.