Alternative, and more robust approach is to give the agent surrogate credentials and replace them on the way out in a proxy. If proxy runs in an environment to which agent has no access to, the real secrets are not available to it directly; it can only make requests to scoped hosts with those.
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...
Yep - requires the client to trust the SSL cert of the proxy. Cooperative clients that support eg HTTP_PROXY may be easier to support, but for Airut I went for full transparent mitmproxy. All DNS A requests resolve to the proxy IP and proxy cert is injected to the container where Claude Code runs as trusted CA. As a bonus this closes DNS as potential exfiltration channel.
You can already put op:// references in .env and read them with `op run`.
1P will conceal the value if asked to print to output.
I combine this with a 1P service account that only has access to a vault that contains my development secrets. Prod secrets are inaccessible. Reading dev secrets doesn't require my fingerprint; prod secrets does, so that'd be a red flag if it ever happened.
In the 1P web console I've removed 'read' access from my own account to the vault that contains my prod keys. So they're not even on this laptop. (I can still 'manage' which allows me to re-add 'read' access, as required. From the web console, not the local app.)
I'm sure it isn't technically 'perfect' but I feel it'd have to be a sophisticated, dedicated attack that managed to exfiltrate my prod keys.
Sometimes I need to give Claude Code access to a secret to do something. (e.g. Use the OpenAI API to generate an image to use in the application.) Obviously I rotate those often. But what is interesting is what happens if I forget to provide it the secret. It will just grep the logs and try to find a working secret from other projects/past sessions (at least in --dangerously-skip-permissions mode.)
I use bubblewrap to sandbox the agent to my projects folder, where the ai gets free read/write reign. Non-synthetic env cars are symlinked into my projects folder from outside that folder.
this solves a real problem. i run coding agents that have access to my workspace and the .env files are always the scariest part. even with .gitignore, the agent can still read them and potentially include secrets in context that gets sent to an API.
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.
What about something like Hashicorp secrets? We have a the hashicorp secrets in launch.json and load the values when the process is initialized (yeah it is still not great)
> can read files in your project directory, which means a plaintext .env file is an accidental secret dump waiting to happen
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.
Alternative, and more robust approach is to give the agent surrogate credentials and replace them on the way out in a proxy. If proxy runs in an environment to which agent has no access to, the real secrets are not available to it directly; it can only make requests to scoped hosts with those.
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...
How does this work with SSL? Do you need to provision certs on the agent VM?
Yep - requires the client to trust the SSL cert of the proxy. Cooperative clients that support eg HTTP_PROXY may be easier to support, but for Airut I went for full transparent mitmproxy. All DNS A requests resolve to the proxy IP and proxy cert is injected to the container where Claude Code runs as trusted CA. As a bonus this closes DNS as potential exfiltration channel.
https://github.com/getsops/sops
This software has done this for years
In the vein of related work, there is https://github.com/imbue-ai/latchkey which injects secrets into cURL commands issued by your agent.
This looks interesting. For agent-fecfile I used the system keyring + an out-of-process proxy (MCP Server) to try to maximize portability.¹
¹ https://github.com/hodgesmr/agent-fecfile?tab=readme-ov-file...
This doesn’t really fix that it can echo the secrets and read the logs. `enveil run — printenv`
Not the author but No, the decryption would ask the secret again? The readme mentions it's wiped from memory after use.
I think it would be best if AI agents would honor either .gitignore or .aiexclude (https://developers.google.com/gemini-code-assist/docs/create...).
The problem is, you cannot force the agent to do anything.
A suitably motivated AI will work around any instructions or controls you put in place.
It doesn’t even need to be motivated: just forgetful.
1Password has this feature in beta. [1]
[1]: https://developer.1password.com/docs/environments/
You can already put op:// references in .env and read them with `op run`.
1P will conceal the value if asked to print to output.
I combine this with a 1P service account that only has access to a vault that contains my development secrets. Prod secrets are inaccessible. Reading dev secrets doesn't require my fingerprint; prod secrets does, so that'd be a red flag if it ever happened.
In the 1P web console I've removed 'read' access from my own account to the vault that contains my prod keys. So they're not even on this laptop. (I can still 'manage' which allows me to re-add 'read' access, as required. From the web console, not the local app.)
I'm sure it isn't technically 'perfect' but I feel it'd have to be a sophisticated, dedicated attack that managed to exfiltrate my prod keys.
I'm using https://www.litellm.ai/ as a proxy
this won't solve the problem.
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
https://github.com/jdx/fnox
A recent project by the creator of mise is related too
I use the combination of sops and age combined with pre-commit hooks to encrypt.env files. Works tremendously well.
Sometimes I need to give Claude Code access to a secret to do something. (e.g. Use the OpenAI API to generate an image to use in the application.) Obviously I rotate those often. But what is interesting is what happens if I forget to provide it the secret. It will just grep the logs and try to find a working secret from other projects/past sessions (at least in --dangerously-skip-permissions mode.)
What software do you use that logs credentials?
Claude Code does it. Check out the JSONL files.
I use bubblewrap to sandbox the agent to my projects folder, where the ai gets free read/write reign. Non-synthetic env cars are symlinked into my projects folder from outside that folder.
this solves a real problem. i run coding agents that have access to my workspace and the .env files are always the scariest part. even with .gitignore, the agent can still read them and potentially include secrets in context that gets sent to an API.
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.
What about something like Hashicorp secrets? We have a the hashicorp secrets in launch.json and load the values when the process is initialized (yeah it is still not great)
I prefer waiting till it gets me in trouble. So far, it having access to all my .env secrets seems to work out okay.
Looks good. Almost stopped reading due the npm example, grasped it was just a use case, kept reading.
Kernel keyring support would be the next step?
PASS=$(keyctl print $(keyctl search @s user enveil_key))
> can read files in your project directory, which means a plaintext .env file is an accidental secret dump waiting to happen
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.