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.
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.
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.
- Path Anonymization: Data paths (e.g., specific memory keys or namespaces) are hashed locally using
sha256(path)before transmission. The server knows which path is being updated but cannot read the path's actual name. - Verified Semantic Recall (VSR): Every load re-derives
sha256(canonicalize(payload))and compares it against the storedclient_payload_hashfrom the server. If a mismatch or cipher tampering is detected, the SDK immediately fails closed (vsr_hash_mismatch), preventing memory poisoning.
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) | Held by the platform credential store; 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:
- 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. - Weak Backup Hygiene: If you export and 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, not a passphrase — protect the key material.
- 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 a cold backup, but zero-knowledge secures the transport and cloud layers — not a live, fully-compromised device.
Consolidated Threat Model
Our security architecture is designed to remain secure under the following threat scenarios:
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 in the event of a TLS termination compromise, the observer only sees AES-256-GCM ciphertext bytes and opaque SHA-256 path hashes.
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 the client-side VSR validation hash comparison.
3. Wholesale Ciphertext Substitution
- Threat: The server returns a valid ciphertext from a previous snapshot sequence to roll back the agent's state or present a stale context.
- Mitigation: The client re-derives the parent-pointer lineage:
snapshot_id = sha256(canonicalize(payload) ‖ parent_snapshot_id). Mismatches between expected and received lineage chains trigger a hard halt, preventing silent history rewriting.
Compliance Posture
For teams operating in regulated verticals, sovseal's zero-knowledge design simplifies compliance audits:
GDPR Compatibility
Under GDPR, the managed sovseal Platform acts purely as a conduit for encrypted data:
- Plaintext PII is never transmitted to or processed by our servers.
- The right to be forgotten (erasure) is handled locally or through rollback updates of lineage pointers.
- Cross-border data transfer concerns are eliminated because the plaintext remains local at all times.
HIPAA & FedRAMP Alignment
- Because the cloud gateway never possesses the means to decrypt stored snapshots, it does not process Protected Health Information (PHI).
- For organizations whose internal compliance policies strictly prohibit the use of external SaaS for any data, the Self-Hosted deployment tier allows you to host the Hono Edge function inside your private VPC or GovCloud infrastructure.
SOC 2 Status
- All infrastructure endpoints conform to strict separation of duties, and we audit transit configurations continuously.
- Since the central servers are blind, the scope of a SOC 2 audit is restricted to token management and gateway availability, keeping audit overhead low.