> ## 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.

# Cryptographic Trust Center

> Consolidated threat model, encryption guarantees, compliance posture, and key custody details.

The **sovseal Trust Center** provides transparent documentation of our cryptographic guarantees, key custody boundaries, compliance posture, and threat model. Because sovseal is designed from the ground up as a local-first, zero-knowledge memory layer, security is not an operational policy—it is a mathematical guarantee enforced by client-side cryptography.

<Info>
  **Zero-Knowledge Design**

  Our security posture dictates that the replication server (whether the managed Platform or a Self-Hosted node) remains entirely blind to your plaintext. Decryption keys never traverse the network.
</Info>

***

## Core Cryptographic Guarantees

Every state snapshot stored or synchronized via the sovseal network is protected by strict cryptographic primitives:

* **Payload Encryption:** AES-256-GCM client-side encryption. A unique 96-bit random Initialization Vector (IV) is generated for every write operation to prevent cipher-state replay.
* **Decentralized Key Isolation:** Encryption keys are generated locally. No central server has access to, or custody of, these keys.
* **Integrity Anchoring:** Every snapshot carries a `client_payload_hash` — `sha256(canonicalize(payload))`, computed client-side and covering the full payload including its `agent_id` and `sequence_number`. The server stores this anchor but never sees the plaintext it was derived from.
* **Verified Semantic Recall (VSR):** On restore, re-deriving `sha256(canonicalize(payload))` and comparing it against the stored `client_payload_hash` catches both ciphertext tampering and wholesale record substitution. **This check is not automatic** — the SDK provides the primitives (`decryptJson`, `canonicalize`, the hash anchor); you run the comparison and decide how to fail closed. There is no built-in `vsr_hash_mismatch` error. See [Verified Semantic Recall](/platform/core-concepts/verified-semantic-recall) for a ready-to-use implementation.

***

## Key Custody & Storage Boundaries

Your keys, your memory. We enforce a strict boundary between client machines and replication gateways:

| Property              | Location / Boundary                                                         | Access Control                                                                                                                      |
| :-------------------- | :-------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------- |
| **Master Key**        | Client Device — **OS keychain** (Keychain / Credential Manager / libsecret) | Subkeys (`k_rest`, `k_sync`) derived via HKDF, non-extractable. Opt-in `0600` file fallback only under `SOVSEAL_KEY_FALLBACK=file`. |
| **Plaintext Memory**  | Client RAM only                                                             | Memory `text` is encrypted **at rest** in local LanceDB under `k_rest`; decrypted only inside active local agent processes.         |
| **Ciphertext Memory** | Sync Gateway (Supabase + Object Bucket)                                     | Opaque bytes, unreadable without the client key.                                                                                    |
| **Auth Tokens**       | Sync Gateway / Environment Variables                                        | Bearer API token (`sov_proj_<uuid v4>` or `sov_live_*`).                                                                            |

***

## What We Cannot Recover (The Unforgiving Boundary)

Zero-knowledge means absolute privacy, which comes with operational responsibilities. **The sovseal Platform cannot assist with the following situations:**

1. **Lost Master Key:** If you lose the keychain master key (or, under `SOVSEAL_KEY_FALLBACK=file`, the fallback key file) without a backup, your local and remote snapshots are **permanently unrecoverable**. There is no key escrow, no "forgot password" flow, and no support override.
2. **Weak Backup Hygiene:** If you back up the master key carelessly (e.g. to an unencrypted, world-readable location), anyone who obtains that copy can decrypt your memory. The strength is the key — protect the key material.
3. **Local Host Machine Compromise:** If an attacker gains root access or code execution on your host, they can read the running agent's process memory or unlock the OS keychain as your user. At-rest encryption and keychain custody raise the bar against a stolen disk or cold backup, but zero-knowledge secures the transport and cloud layers — **not** a live, fully-compromised device.

***

## Consolidated Threat Model

### 1. Passive Network Observer (Man-in-the-Middle)

* **Threat:** An attacker intercepts sync packets on a public network to read agent memory.
* **Mitigation:** All replication traffic is forced over HTTPS. Even under a TLS termination compromise, the observer only sees AES-256-GCM ciphertext bytes and non-secret metadata (`agent_id`, `sequence_number`, `client_payload_hash`) — never plaintext or the encryption key.

### 2. Malicious or Compromised Sync Gateway

* **Threat:** A compromised cloud operator attempts to read memory contents or inject false memories to poison the agent's context.
* **Mitigation:** The gateway has no access to the keys. Any attempt to modify ciphertext is caught by the AES-GCM authentication tag. Any attempt to swap the payload with an older or different valid ciphertext is caught by client-side VSR validation.

### 3. Wholesale Ciphertext Substitution

* **Threat:** The server returns a valid ciphertext from a previous snapshot sequence to roll back the agent's state.
* **Mitigation:** `client_payload_hash` covers the entire payload, including `sequence_number` and `parent_snapshot` — so a substituted (older or different) snapshot's re-derived hash will not match the one issued at its original write. Combined with the server's strict `sequence_number` enforcement (must equal `latest confirmed + 1`, or `409 sequence_gap`), an attacker cannot silently rewrite history or replay a stale snapshot as current. See [Deterministic Lineage](/platform/core-concepts/deterministic-lineage) for the full ordering model.

***

## Compliance Posture

sovseal states its compliance status honestly. Zero-knowledge narrows audit scope — the gateway processes **ciphertext plus metadata only, never plaintext PHI or PII** — but a narrow scope is not a certification. Current status:

| Framework             | Status                                                                                                                                                                           |
| :-------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **SOC 2 Type I / II** | **In Progress** — a readiness engagement is underway. **No SOC 2 report has been issued**; we do not claim "SOC 2 certified" or "SOC 2 compliant".                               |
| **GDPR**              | **In Progress** — plaintext PII never reaches our servers; erasure is satisfied locally and via the retention TTL purge (a 7-day grace precedes irreversible cloud deletion).    |
| **HIPAA**             | **Self-Attested** — the gateway holds ciphertext only and never processes PHI. A self-service **BAA template** is available and requires your counsel's review before execution. |

The source of truth for every compliance artifact — the BAA template, SOC 2 TSC mapping, sub-processor registry, and risk register — is the public Trust Center at [sovseal.com/trust](https://sovseal.com/trust). Sub-processors process ciphertext and metadata only.

For organizations whose policies prohibit any external SaaS, the **Self-Hosted** tier runs the Hono edge function inside your own infrastructure.

### Tamper-Evident Audit Trail

* Every privileged team action (key grants/revocations, DEK rotations, member changes, shared-memory writes) is recorded in a per-team **append-only ledger**, each entry SHA-256-chained to the one before it.
* Any retroactive edit, deletion, or reorder breaks the chain at a provable sequence number; `UPDATE`/`DELETE` are additionally blocked at the database level.
* Administrators can verify chain integrity and export the trail (JSON with embedded verification, or CSV) from the dashboard **Audit Log** page.
* The ledger records only non-secret descriptors (member ids, roles, sequence numbers, sizes, reasons) — never key material or memory content. See [Observability](/platform/features/observability).

### Enterprise SSO & SCIM Provisioning

* **Enterprise** teams connect their IdP (Okta, Azure AD, OneLogin) for **SAML 2.0 SSO** and **SCIM 2.0** automated provisioning. See [SSO & SCIM](/platform/features/sso-and-scim).