security model
Security model
The whole architecture exists to make one statement true — not as a policy promise, but by construction.
Even if Stillvault-the-company is breached or subpoenaed, we cannot produce your secrets — we never hold a key that opens them.
To be precise about scope: this is about your stored secrets — we never hold a key that decrypts them at rest. We do see metadata (secret labels, access times, and approver identities), and a secret is briefly in the clear inside your own process at the moment of use. Both are detailed below, in the threat model and the known residuals.
three planes
The vendor side is blind; the keys live on your side.
Three planes, split by a single boundary. Above it, the vendor cloud routes and authorises but holds only ciphertext. Below it — on your side — your own infrastructure, your organisation's identity, and the enrolled device — a phone or your browser — that holds the key and performs the biometric release.
threat model
What it defends, what it does not, and what it trusts.
Stated plainly, with no softening. The middle list is a feature: knowing exactly what a system does not protect is how you decide whether to trust it.
Defends against
- Theft of disk, backups, or snapshots — only ciphertext at rest, on the server and in the vendor cloud.
- A compromised but idle server — with no active release, there's nothing to steal.
- A compromised or malicious vendor — our relay is blind; it can deny service or observe metadata, but cannot read secrets.
- Silent or automated exfiltration — every release needs a human biometric, so a background attacker can't quietly pull secrets without a visible prompt landing on an approver's device.
- Silent unilateral access by an insider — every release is biometric-gated, attributed to a named approver, and audit-logged, so no one acts without a visible, accountable prompt. (Structurally preventing any single approver from releasing alone needs M-of-N quorum release, available on the Enterprise plan.)
Does not defend against
- The requesting host compromised mid-use — the secret is in that process's memory by necessity.
- A single-approver secret whose one device is compromised and biometric passed — they have you and your finger. (M-of-N quorum release removes this single point of failure — available on the Enterprise plan.)
- Coerced approval — an approver tapping approve under duress.
- Metadata exposure to the vendor — which secrets exist, access times, who approved — a residual leak with a hardening path.
Trust anchors
- The approver's key store — a hardware secure enclave (Android StrongBox / iOS Secure Enclave) on the device-bound tier, your enrolled devices on the synced tier — holds the private key and never yields it to our servers.
- Your organisation's identity, customer-held and never given to the vendor — anchors that a release is authentic and can't be redirected to us.
- The requesting process's memory integrity during an active release only.
Explicitly not trusted: the vendor cloud / managed
relay , the push channel , the network .
why it holds
Two properties keep the relay blind — even to a malicious vendor.
The key lives on your device, behind a biometric.
The material that opens a secret is reconstructed only on an enrolled approver's device, gated by their biometric, and used there. It never reaches our servers — the relay only ever carries an encrypted result it cannot read.
Every release is bound to your own identity.
Each release is cryptographically tied to your organisation's identity, verified on the approving device. We never hold the private side of that identity, so we cannot substitute our own endpoint in the middle — only deny service or observe metadata. The relay is reachable on the public internet, but it verifies that identity on every request before it acts: an unsigned or forged request is refused outright — never parked, never surfaced to an approver.
And why a biometric rather than just "the device signs an approval": a signature only proves someone consented — the key itself can still be sitting on a server. Stillvault makes the biometric a required ingredient of the release itself. No device, no key.
approver custody
Two approver tiers — convenience or hardware, your call.
The same vendor-blind guarantee holds on both: the key that opens a secret is never on our servers. They differ only in where, on your side, the key is kept.
Synced
The approver's key is available across the devices you enrol — including the web console in your browser, so a release can be approved without reaching for a phone. Held on your devices, never on ours. Available on every plan.
Device-bound (enterprise)
The key is sealed in the device's hardware secure enclave (Android StrongBox / iOS Secure Enclave), where it is non-exportable and can never leave. The strongest custody, for your most sensitive secrets.
stated plainly
The one thing it cannot protect.
To actually use a secret, your app must hand it to, for example, a database driver — so it exists in the clear in that process at the moment of use. Any scheme has this property. What Stillvault does is make that window short, explicit, biometric-gated, and confined to your own process.
An attacker who captures a secret in that window has compromised that one secret — until the underlying credential is rotated out of band. Stillvault confines this to your own host during an active, approved release: never our relay, never the vendor. Rotation is the only true remediation, and it is out of scope today.
residuals & roadmap
Known residuals, and where we're headed.
Metadata hardening is the main residual: the control plane today sees secret labels, access times, and approver identities, and the hardening path is opaque secret IDs and encrypted labels so the cloud sees only ciphertext and routing tokens. On compliance, SOC 2 Type II then ISO 27001 are on the roadmap, not achievements — we make no certification claims we have not earned.
Found something? Responsible disclosure:
hello@stillvault.ai .