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 that’s so fresh out of the oven its install instructions are hypothetical.)
There are other mismatches between your claims / aims and the reality. Some highlights: You’re not actually zeroizing the secrets. You call `std::process::exit()` which bypasses destructors. Your rotation doesn’t rotate the salt. There are a variety of weaknesses against brute forcing. `import` holds the whole plain text file in memory.
Again, none of these are problems in the context of just preventing accidental .env file ingestion. But then why go to all this trouble? And why make such grand claims?
Stick to established software and patterns, don’t roll your own. Also, don’t use .env if you care about security at all.
My favorite part: I love that “wrong password returns an error” is listed as a notable test. Thanks Claude! Good looking out.
This is amazing. I agree with your take except "You’re not actually zeroizing the secrets"... I think it is actually calling zeroize() explicitly after use.
Can I get your review/roast on my approach with OrcaBot.com? DM me if I can incentivize you.. Code is available:
https://github.com/Hyper-Int/OrcaBot
enveil = encrypt-at-rest, decrypt-into-env-vars and hope the process doesn't look.
Orcabot = secrets never enter the LLM's process at all. The broker is a separate process that acts as a credential-injecting reverse proxy. The LLM's SDK thinks it's talking to localhost (the broker adds the real auth header and forwards to the real API). The secret crosses a process boundary that the LLM cannot reach.