It's me until I lock my screen

Security prompts are consent. A prompt nobody is there to answer is just a stalled task. 0.2.6 resolves that tension with trusted sessions.

enveigh's whole premise is that an agent should use your keys without seeing them, and that you approve when it matters. The approval policies do that well when you're at the keyboard: Touch ID per request if you want maximum control, once per environment as the balanced default.

Then agents got patient. A modern coding agent will happily grind through a task list for an hour, and somewhere in minute forty it needs the staging environment. The broker does exactly what you asked: it puts up a Touch ID prompt naming the process and the environment. But you went to get coffee. The task is now blocked on a fingerprint that isn't coming, and the least secure fix (switching the policy to "unlocked = allowed") is the one people reach for.

A window, not a switch

A trusted session is the answer we actually wanted for ourselves: "I'm here coding, it's me, stop asking until I lock my computer." You start it from the menu-bar icon and confirm once with Touch ID. From that moment the broker treats agent requests as approved, so a long run never stalls mid-task.

The important part is how it ends. The session dies the instant your presence can no longer be assumed: the screen locks, the screensaver starts, the Mac sleeps, the login session switches to someone else, or you lock the vault. There's an End trusted session item in the menu bar for ending it early, and it never survives an app relaunch.

Why this isn't a backdoor

Three properties keep a trusted session honest. First, it's never a stored preference: there is no toggle a rogue process could flip, and arming it always costs one fresh Touch ID at the moment you do it. Second, it changes prompting, not visibility: every access is still written to the audit log and still fires a notification per request, and the session's start and end are audit events themselves, so a no-prompt window is always visible after the fact. Third, it doesn't cover everything: destructive operations, like deleting an environment, prompt no matter what.

It's the same trade sudo made decades ago: authenticate once, act freely for a bounded window, log everything. The bound here isn't a timer you have to guess. It's the thing you already do when you walk away from your Mac.

Download enveigh →

The boring release (0.1.1)

A vault asks for your trust, so before adding anything new we audited what we'd already built.

0.1.1 adds no features. It's the result of a full correctness and memory-safety review of the vault, the broker, and the scanner, done the unglamorous way, file by file, then fixed and regression-tested the same day.

What it caught, in rough order of "glad that's gone": a data race in the secret scanner's regex cache (two threads sharing a mutable dictionary: the kind of bug that crashes once a month and never in a debugger), a crash on hostile backup files (a forged PBKDF2 iteration count could trap the app instead of being rejected as malformed), a potential deadlock when scanning git history in noisy repos, and an audit log that re-encrypted its entire history on every single reveal. The audit log is now append-only, one AES-GCM-sealed line per event, so it stays O(1) forever.

Two behavior changes ride along: agent-run commands (run_with_env) now time out instead of hanging a tool call forever, and the env scrubber exempts SSH_AUTH_SOCK; it's the ssh-agent's socket path, not a secret, and stripping it was quietly breaking git-over-SSH inside wrapped builds.

We also wrote down the answer to the question every secrets tool gets: does this break my build? It doesn't. Your build runs as a normal child process with the same env vars a .env would have given it. The new page explains why, and when to use the CLI instead of the agent tool.

Updates ship through the built-in updater; Check for Updates… in the app menu gets you there now.

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.

Download enveigh →