How it works

Stillvault is a vendor-blind secret-release layer. The control plane routes requests and holds ciphertext; it never holds a key that can open them. The key that opens a secret lives on an enrolled approver device — a phone, or a browser you’ve enrolled — and the result is delivered straight to the requesting process. Our relay never sees a secret in the clear.

End-to-end flow

When an app or agent asks for a secret through the local Stillvault client, the client first checks whether it already holds a valid, recently-approved copy. If it does, it returns it locally — no network, no phone. Otherwise the full approval loop runs:

1. Request. The local client raises a request and binds it to your organisation’s identity, so it can’t be spoofed or redirected.
2. Route. Our service looks up the encrypted secret and forwards a one-time approval prompt to the enrolled approver(s). It only ever handles ciphertext.
3. Approve. The approver’s device — their phone, or the web console — shows trustworthy context: which secret, which process, which host, and when. Any-of-N: the prompt fans out to all enrolled approvers, and the first to approve wins.
4. Release. A biometric authorises the release on the approver’s device. The key never leaves it, and our service relays only an encrypted result it cannot read.
5. Deliver. The local client receives the result and hands the secret to the requesting process for that one use.

The only place a secret appears in the clear is the requesting process, on your own machine, at the moment of use.

Caching

So a tight loop doesn’t prompt a human on every single call, the local client can hold a released secret for a short, policy-bounded window and serve repeat requests locally — no network, no phone tap — until that window expires. The cached secret lives only on your own machine, attributable to the process using it; the control plane sets the maximum window and logs each grant, and never sees the cached value.

The window is the single per-secret policy knob, from “re-prompt every few minutes” to “approve once for this task.”

Multi-approver

Any-of-N (today): several people can be enrolled as approvers for a secret; any one of them approving releases it. The prompt fans out to all of them, and the first to respond wins.

M-of-N quorum (Enterprise): a threshold mode where M of N named approvers must each approve before a secret is released, so no one individual — and no single compromised phone — can release a secret alone (the “two-person rule” for your most sensitive secrets). The key is reconstructed only on your own side, after the quorum approves — so no single approver, and not the vendor, can release alone.

Approval context

Once a server is compromised, the attacker effectively is the service and can trigger an approval prompt at will. The only thing between them and a secret is a human reading the prompt — so the approval screen is a first-class security surface.

The approver’s device shows attacker-uninfluenced context about the request:

Your organisation’s identity gates that the request is authentic, and each approval can only ever release the one named secret shown on the screen.

Where you approve

Approvals aren’t tied to one gadget. An enrolled approver can act from:

• The web console — sign in, see pending releases with their full context, and approve in the browser. The key that opens the secret is held on that device and never sent to us.
• Their phone — a one-time push, approved behind a biometric.

Two approver tiers, the same vendor-blind guarantee — we only ever relay ciphertext:

• Synced tier — the approver’s key is available across the devices you enrol, including the browser. Convenient, and available on every plan.
• Device-bound tier (enterprise) — the key is sealed in the device’s hardware secure enclave (Android StrongBox / iOS Secure Enclave) and can never leave it. The strongest custody, for your most sensitive secrets.

The web console is also where you run the org day-to-day: invite your team and set roles, enrol approver devices and revoke them, seal new secrets in the browser, and read or export the audit log. Removing an approver re-seals or warns before any secret would be left with no one able to release it.

Agent integrations

Stillvault treats AI agents as first-class consumers: an agent gets the secrets it’s authorised for through the same human-in-the-loop approval, and we still see no usable key. Enrol an agent, scope it to the paths it needs, and it requests releases through the stillvault CLI — a versioned Claude skill bundle installs alongside the CLI so an agent can use Stillvault as its secrets backend. A Model Context Protocol (MCP) server is on the roadmap. See Agents & the CLI.