Privacy policy
Last updated: 2026-06-12 — placeholder. Executed policy will be published before general availability.
What the control plane sees vs. what it can never see
Stillvault’s architecture is designed so the vendor can observe the minimum necessary to route and coordinate approvals. The table below is accurate as a structural description of the system, not just a policy commitment.
| The control plane sees | The control plane can never see |
|---|---|
| Secret labels (names you give secrets) | Secret plaintext |
Access times — when each stillvault get was requested | Decryption keys (DEKs) |
| Approver identities — which user approved each release | Wrapped DEK material |
Consumer metadata — uid/pid/exe of the requesting process (from SO_PEERCRED) | The Org Identity private key (held customer-side) |
| Org Identity public key (pinned at enrollment) | Any key that could open a stored ciphertext |
| Tenant org memberships and device enrollments | Passkey private key material |
| Billing and subscription state | Break-glass / recovery key material |
The broker relays sealed blobs: ciphertext is decrypted on the approver’s phone and re-sealed directly to the requesting consumer’s ephemeral key. The relay never holds a key that opens the result.
Data collected
- Account data: email address, org name, user roles.
- Audit log: request timestamps, approver decisions, consumer process metadata. Retained per subscription tier; exportable.
- Encrypted stores: secret ciphertext and wrapped DEK envelopes. Stored on the broker. Not decryptable by Stillvault.
- Device enrollment records: passkey credential IDs and public keys. No private key material.
Data not collected
- Secret plaintext — decryption occurs on the approver’s phone and the result is sealed to the consumer. It does not transit or rest on the control plane.
- Biometric data — all biometric processing occurs on-device inside the phone’s secure enclave. Stillvault receives only the cryptographic output (a passkey assertion).
Hardening roadmap
Current residual: the control plane sees secret labels and access times in cleartext. The hardening path (not yet implemented) is opaque secret IDs and encrypted labels so the cloud sees only ciphertext plus routing tokens. This will be implemented before GA.
Contact
For privacy enquiries: privacy@stillvault.com (once published).
This is a placeholder. The executed privacy policy will be published before general availability.