the agent inherits your shell, your env, and your network. encrypting one file doesn't change the trust boundary. the proxy approaches in this thread are closer to the right answer because the agent never holds real credentials at all
Show HN: enveil – hide your .env secrets from prAIng eyes
111–120 of 152 posts
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#112[flagged]
This matches what I've seen. The .env file is one vector, but the more common pattern with AI coding tools is secrets ending up directly in source code that never touch .env at all. The ones that come up most often: - Hardcoded keys: const STRIPE_KEY = "sk_live_..." - Fallback patterns: process.env.SECRET || "sk_live_abc123" (the AI helpfully provides a default) - NEXT_PUBLIC_ prefix on server-only secrets, exposing…
Just use gitleaks or trufflehog?
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#113Alternative, 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,…
OP isn't talking about giving agents credentials, that's a whole nother can of worms. And yes, agreed, don't do it. Some kind of additional layer is crucial.
Personally I don't like the proxy / MITM approach for that, because you're adding an additional layer of surface area for problems to arise and attacks to occur. That code has to be written and maintained somewhere, and then you're back to the original problem.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#114Earlier quoted context omitted.
This matches what I've seen. The .env file is one vector, but the more common pattern with AI coding tools is secrets ending up directly in source code that never touch .env at all. The ones that come up most often: - Hardcoded keys: const STRIPE_KEY = "sk_live_..." - Fallback patterns: process.env.SECRET || "sk_live_abc123" (the AI helpfully provides a default) - NEXT_PUBLIC_ prefix on server-only secrets, exposing…
Just use gitleaks or trufflehog?
gitleaks and trufflehog are great for scanning git history for leaked secrets but that's one of 52 rules. prodlint catches the structural patterns AI coding tools specifically create: hallucinated npm packages that don't exist, server actions with no auth or validation, NEXT_PUBLIC_ on server-only env vars, missing rate limiting, empty catch blocks, and more. It's closer to a vibe-coding-aware ESLint than a secrets scanner.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#115Does 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...
It doesn't even have to change the code to get the secret. If you're using env variables to pass secrets in, they're available to any other process via `/proc//environ` or `ps -p -Eww`. If your LLM can shell out, it can get your secrets.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#116Earlier quoted context omitted.
Good point. You would need to inject the secrets in an inaccessible part of the pipeline, like an external proxy.
Like deno sandbox https://deno.com/deploy/sandbox
But that's moving the whole LLM agent into the cloud, which creates its own difficulties. Not really a solution to the local secrets problem.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#117In 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.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#118[flagged]
I've had similar concerns with letting agents view any credentials, or logs which could include sensitive data.
Which has left me feeling torn between two worlds. I use agents to assist me in writing and reviewing code. But when I am troubleshooting a production issue, I am not using agents. Now troubleshooting to me feels slow and tedious compared to developing.
I've solved this in my homelab by building a service which does three main things: 1. exposes tools to agents via MCP (e.g. 'fetch errors and metrics in the last 15min') 2. coordinates storage/retrieval of credentials from a Vault (e.g. DataDog API Key) 3. sanitizes logs/traces returned (e.g. secrets, PII, network topology details, etc.) and passes back a tokenized substitution
This sets up a trust boundary between the agent and production data. The agent never sees credentials or other sensitive data. But from the sanitized data, an agent is still very helpful in uncovering error patterns and then root causing them from the source code. It works well!
I'm actively re-writing this as a production-grade service. If this is interesting to you or anyone else in this thread, you can sign up for updates here: https://ferrex.dev/ (marketing is not my strength, I fear!).
Generally how are others dealing with the tension between agents for development, but more 'manual' processes for troubleshooting production issues? Are folks similarly adopting strict gates around what credentials/data they let agents see, or are they adopting a more 'YOLO' disposition? I imagine the answer might have to do with your org's maturity, but I am curious!
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#119I dunno I think I'd rather use bitwarden secrets to pull the current ones using systemd preexec and an access key in the service file which is root and 600.
Re: Show HN: enveil – hide your .env secrets from prAIng eyes
#120The thread illustrates a recurring pattern: encrypting the artifact instead of narrowing the authority. An agent executing code in your environment has implicit access to anything that environment can reach at runtime. Encrypting .env moves the problem one print statement away. The proxy approaches (Airut, OrcaBot) get closer because they move the trust boundary outside the agent's process. The agent holds a scoped r…
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 like you can audit the weights and understand any potential malicious behaviour encoded in there, beyond the baseline of "yeah these things are kinda unpredictable".
And on the flip side, a remote model isn't creating risk in and of itself. That comes from the agent harness being permitted to make network and filesystem calls. Even the most evil possible version of ChatGPT isn't going to exfiltrate anything except by somehow social-engineering you into volunteering the information.