> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sovseal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How Your Data is Protected

> A complete guide to sovseal's cryptographic pipeline, zero-knowledge architecture, and local-first memory model.

Your data's security is our highest priority. sovseal employs multiple layers of protection to ensure your agent's memory remains private, secure, and under your absolute control.

## 1. Zero-Knowledge Architecture

sovseal uses a **zero-knowledge architecture**, meaning we have no ability to access, read, or share your memories. This is not a policy — it is a technical reality of how our system is designed.

* **Client-Side Encryption**: Memories are encrypted on your local device before transmission to the sync edge function.
* **Server-Blind Storage**: Our servers and storage backends store only encrypted, opaque ciphertext blobs.
* **Unreadable Keys**: The sync encryption keys are derived on your device using HKDF-SHA256 from a master key in your OS keychain. We never see or store your keys.

## 2. Local-First At-Rest Cryptography

Memory text is encrypted at rest in your local **LanceDB** database using AES-256-GCM:

1. **OS Keychain Custody**: The master encryption key lives in the secure operating system keychain (macOS Keychain, Windows Credential Manager, or Linux libsecret).
2. **Key Derivation**: We derive subkeys for at-rest encryption (`k_rest`) and sync (`k_sync`) using HKDF-SHA256, ensuring domain separation.
3. **Envelope Format**: Envelopes use the `sgcm1:` format (base64-encoded IV, ciphertext, and authentication tag) with a unique 12-byte IV per row.
4. **Vector Safety**: Only the textual content is encrypted. Vectors remain in the clear for fast local retrieval.

## 3. Cryptographic Data Integrity (VSR)

To prevent server tampering or database corruption during replication, sovseal uses **Verified Semantic Recall (VSR)**:

* **SHA-256 Hash Anchoring**: The local client computes a SHA-256 hash of the canonicalized payload before encrypting it, returned as `client_payload_hash` on every snapshot receipt.
* **Verification on Recall**: The SDK exposes the primitives — `decryptJson`, `canonicalize`, and the hash anchor — for you to re-derive and compare on every restore.
* **Not automatic**: This check is not run for you, and there is no built-in `vsr_hash_mismatch` error class — you implement the comparison and decide how to fail closed. See [Verified Semantic Recall](/platform/core-concepts/verified-semantic-recall) for a ready-to-use implementation.

## 4. Secure Sync Replication

* **Write-Behind Worker**: Storing memories returns immediately on local commit. Cloud replication runs asynchronously in the background.
* **Secure Transport**: All sync traffic is forced over HTTPS/TLS to the Frankfurt edge endpoint.
* **Escrow by plan, not by default**: On Hobby/Starter and the local/MCP tier, sovseal never escrows or backs up your master key — lose your keychain credentials and your memories are permanently unrecoverable. Growth, Pro, and Enterprise plans include opt-in **Managed Key Recovery** (Shamir-split DEK escrow; HSM-backed on Enterprise) — see [Account & Device Security](/security/account-security) for the full plan-by-plan breakdown.