Use, don't see
Why a secrets vault for the age of coding agents has to do exactly one counterintuitive thing.
For a decade the advice was simple: keep your keys in a .env file, keep that file out of git, and move on. It worked because the only thing reading your .env was you and your build.
Coding agents broke that. Now there's a tireless process in your repo that reads files, runs commands, and streams chunks of your project into a model's context to reason about them. A .env in that world isn't a quiet local file — it's a key sitting one tool-call away from a transcript, a log, or a paste into a chat you don't control.
The instinct is to lock the agent down. But a locked-down agent is a useless one — half the value is letting it actually build, test, and deploy, which means it needs a real environment.
The trick is separating use from see
A process can use a secret without a human (or a model) ever reading it. enveigh leans entirely on that: it injects your keys into the child process your command runs in, then redacts those values from everything that comes back. The agent gets a working npm run deploy and an exit code. It never gets the key.
When an agent genuinely needs the plaintext — rendering a real .env to hand to a tool that demands a file — that path exists, but it's off by default, gated behind Touch ID, and written to an audit log before the value leaves the app. The default is the safe thing; the exception is the deliberate one.
Local, because trust shouldn't require a server
The values live in the macOS Keychain on your machine. There's no enveigh cloud, no account, no sync target you have to vet. Agents reach the vault through a local broker that only runs while you've unlocked it — and each one gets a token scoped to exactly the environment you granted.
None of this is novel cryptography. It's mostly just refusing to hand a model something it doesn't need. That turns out to be most of the battle.