Cryptographic Trust Center

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.

---

​

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 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:

---

​

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

​

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.