Quickstart

This walkthrough takes you from a fresh account to a server pulling a secret behind one human approval. Setup happens in the web console; consumption happens with the stillvault CLI on the machine that needs the secret.

Pre-GA. Stillvault isn’t generally available yet. The console flow below is live; the consumer CLI installs with the one-liner in step 4 (Linux today; macOS on the roadmap). Command names are stable; some flags are still settling — check stillvault help.

1. Create your organisation and its identity key

Sign up, create your organisation, and you’ll land on the Org-Identity key step.

This key is your organisation’s trust root: it’s what makes a release authentic and what an admin uses to admit approver devices. It is generated in your browser — the private side is never sent to us. You’ll download an encrypted backup and a recovery code; store both safely (a password manager is fine). You’ll need them to admit devices from another browser, or to recover if you lose this one.

Only the public half of this key reaches our servers. Lose the backup and the recovery code and no one — including us — can vouch for new devices, by design.

2. Enrol an approver device

An approver is a person, acting through their devices. A device holds a wrapping key that secrets are sealed to; that key is generated on the device and never leaves it.

On Devices → Enrol this device, your browser generates the wrapping key, keeps the private half locally, and submits only the public half. The device lands pending, with a short fingerprint.

Admitting it is a separate, admin-held step (so the trust-root key stays with admins, not on every device):

1. An admin opens Devices → Awaiting admission and unlocks the Org-Identity key (it’s in their browser, or restored from the backup + recovery code).
2. They compare the fingerprint with the enrollee out of band (read it aloud, etc.) — this is what stops a tampered key being admitted.
3. They click Admit, which signs the device into the approver directory.

If you’re a solo org, you’re both: enrol the device, then unlock your key and admit it.

3. Store a secret

In the console, open Secrets → New secret, choose a hierarchical path (e.g. db/prod/password), pick the approvers, and enter the value. It’s encrypted in your browser and sealed to each approver’s device — only ciphertext and wrapped keys reach us.

(You can also seal from the CLI on a consumer host with stillvault seal — same model, same vendor-blind guarantee.)

4. Install the CLI and enrol the host

On the machine (or agent) that needs the secret, install the CLI with one command. An admin first mints a one-time enrolment token in the console (Agents → Generate enrolment token) and gives it to whoever sets up the host, along with the org id:

curl -fsSL https://stillvault.ai/install.sh \
  | STILLVAULT_ORG=<org-id> STILLVAULT_ENROLL_TOKEN=<token> sh

This installs the stillvault binary and the Claude skills bundle (so an AI agent can use Stillvault as its secrets backend), then enrols this host’s own signing key — generated locally. Your organisation’s identity key never touches the machine; the host only ever holds a key that an admin has to admit. The installer prints a fingerprint; an admin compares it in the console (Agents → Admit) before the host can request anything.

Then start the local agent and you’re ready to release:

STILLVAULT_BROKER=https://stillvault.ai STILLVAULT_TENANT=<org-id> \
  stillvault agent --agent <agent-id> &

5. Release it to a server — one approval

On the enrolled machine:

stillvault get db/prod/password

This raises a request signed by the host’s admitted agent key and sends it on. An approval prompt — showing which secret, which process, which host, and when — reaches an enrolled approver, in the web console or on their phone. They check the context and approve with a biometric; the secret is released to the requesting process for that one use.

Verify the fields match what you expect before approving. One approval releases exactly one named secret.

6. Repeat access within the cache window — no prompt

stillvault get db/prod/password
# <served locally within the policy window — no network, no approval>

The cached value lives only on that machine and is discarded when the window elapses; the next get after that prompts again. The control plane sets the maximum window and never sees the cached value.

What happens at each step

Our relay never sees a secret in the clear at any point in this flow.