human-in-the-loop secrets for AI agents
Even we can't read your secrets.
AI agents need real credentials — API keys, database passwords — to do their work. Stillvault releases them only when a named human approves with a biometric, and the key that opens a secret never exists on our servers.
- agent requested prod/db-primary uid=1001 exe=/usr/bin/claude
- system push delivered → approver phone any-of-2
- ben countersigned prod/db-primary → released lease 15m
the shared flaw
The server can decrypt — so server compromise is key compromise.
Every option today shares one flaw: the server can decrypt unaided, so server compromise is key compromise.
| Approach | Failure |
|---|---|
plaintext file (chmod 600) | disk image / backup / root = instant compromise. |
pass / gpg-agent | unlock passphrase and decrypted secret live on the server; root during the cache window gets everything. |
Vault / Infisical / Doppler | server-side KMS holds the key. Unsealed Vault + host compromise = secrets. The vendor (or whoever holds the KMS) can also decrypt. |
push-MFA (Duo, etc.) | gates access timing, not key custody. Server can still decrypt. |
For a SaaS secret manager the flaw compounds: the vendor's cloud holds the keys, making the vendor the single most valuable breach — and subpoena — target on the internet.
how it works
Five steps, one human, no key on our servers.
-
01An agent asks the local consumer wrapper over a Unix socket.
-
02The wrapper mints an ephemeral key, signed by your Org Identity key so it can't be vendor-substituted.
-
03A one-time push reaches an enrolled approver's phone — first to approve wins.
-
04A biometric unlocks the unwrap on the phone; the plaintext is re-sealed to the requesting consumer.
-
05The broker relays a blob it cannot open; the wrapper unseals it and holds the lease.
The only place plaintext ever appears is the consumer's RAM at time of use, on your own machine.
The vendor stays blind. That's the design, not a promise.
Decryption happens on the phone.
The DEK that opens a secret is unwrapped and used on the approver's phone, gated by a biometric. It never leaves the device, so the broker only ever relays an opaque blob.
Results are sealed to a key we can't substitute.
The plaintext is re-sealed to a consumer key your Org Identity key signed. We never hold that private key — so we can't swap in our own endpoint and MITM the seal.
Managed or self-hosted is an ops choice.
Because the broker is blind either way, picking the managed tier is zero-ops convenience — not a security tradeoff. The vendor-blind property is identical.
Proven on real hardware — WebAuthn PRF release on Android, StrongBox
device-bound keys, end-to-end blind approval loop.