Security model
This page explains, at a high level, how Sablefort Keyvault keeps your secrets private. The short version: your data is encrypted on your own device before it is ever synced, and Sablefort's servers only ever hold encrypted material. This is what we mean by zero-knowledge — we cannot read your vaults, because we never have the keys to them.
Client-side encryption
Encryption and decryption happen on your device, inside the Sablefort app or CLI — never on our servers. When you save an item, the Sablefort engine encrypts it locally first, and only the encrypted result leaves your machine. When you open an item, the app fetches the encrypted material and decrypts it in place. Plaintext exists only in memory on a device you control, for as long as you're using it.
Your master password never leaves your device
Your master password is the root of your access, and it is never transmitted to Sablefort. It is used locally to unlock your account's keys on the device in front of you. Because we never receive it, we cannot look it up, email it to you, or hand it to anyone else — and neither can an attacker who compromises our servers.
Per-item encryption
Each vault is encrypted under your account, and items within it are individually encrypted. This granularity is what makes sharing safe: when you grant a teammate access to a single vault, they gain the ability to decrypt that vault's items and nothing else. Removing access removes it everywhere the next time clients sync. Non-secret metadata (such as an item's title) may be handled separately from secret field values so the app can list and search your items responsively.
Encrypted in transit and at rest
Beyond client-side encryption, every connection between your device and Sablefort is protected with modern transport security (HTTPS/TLS), and the encrypted vault data we store is also encrypted at rest in our infrastructure. In practice your secrets are wrapped in multiple independent layers: your own client-side encryption, transport encryption on the wire, and storage encryption on disk.
Zero-knowledge sync
Your vaults sync automatically across all your devices and to your teammates. Throughout that process, Sablefort's servers move and store only ciphertext. Sync is a matter of distributing encrypted blobs and the membership metadata needed to route them — the servers coordinating the sync never see the contents they are syncing.
Access control and auditability
Who can decrypt what is governed by vault membership and roles (viewer, editor, admin). Administrative actions and secret access are written to an audit log that your security team can search and export, so there is always a record of who accessed which vault and when. Requiring two-factor authentication and SSO adds identity assurance in front of that access. Note that these controls govern access to encrypted data; the encryption itself is the same regardless of role.
What Sablefort can and cannot do
| Sablefort can | Sablefort cannot |
|---|---|
| Store and sync your encrypted vaults | Read the plaintext inside your vaults |
| Route access based on vault membership | Recover a forgotten master password for you |
| Record access in the audit log | Hand your secrets to a third party in readable form |
| Enforce policies like 2FA and auto-lock | Decrypt an item without an authorized device and account |
Account recovery caveats
The same design that keeps Sablefort out of your data also means recovery depends on you and your organization, not on us. Organizations can enable an admin-assisted recovery process so that a member who loses their master password can be re-provisioned by an administrator, and you can keep an encrypted backup for continuity. Plan for these before you need them — after a password is lost is too late to set them up. The details are covered in Backup & recovery.