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 or app requests a secret through a local Stillvault client on your own machine.
-
02The request is cryptographically bound to your organisation's identity, so it can't be spoofed or redirected.
-
03A one-time prompt reaches an enrolled approver — on their phone or in the web console — first to approve wins.
-
04The approver authorises the release on their device, behind a biometric — the key that opens the secret never leaves it.
-
05Our service relays only an encrypted result it cannot read; the secret is delivered to the requesting app for that one use.
The only place a secret appears in the clear is the moment of use, inside your own process — never on our servers.
The vendor stays blind. That's the design, not a promise.
The key stays on the approver's device.
The key that opens a secret is used only on an approver's device — their phone, or the web console — behind a biometric, and never leaves it. We only ever relay an encrypted result we can't read.
Every release is bound to your own identity.
Releases are cryptographically tied to your organisation's identity — one whose private side we never hold. So we can't quietly redirect a release to ourselves.
Managed or self-hosted is an ops choice.
Because our service 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 — biometric secret release on Android, with
hardware-backed device keys and an end-to-end blind approval loop.