What the server sees vs. cannot see
Formal threat model — four attacker profiles
1. Passive network observer (MITM)
- Attacker goal. Intercept sync packets on the public network to read agent memory.
- Mitigation. All replication traffic runs over HTTPS. Even if TLS is terminated or compromised, the observer only sees AES-256-GCM ciphertext bytes and non-secret metadata (
agent_id,sequence_number,client_payload_hash) — nothing recoverable without the client key.
2. Malicious or compromised replication server
- Attacker goal. Read stored memories or inject false state to poison the agent’s context.
- Mitigation. The server does not hold the decryption keys. Payload integrity and chronological substitution are both closed by Verified Semantic Recall (VSR) — a check you run on restore, not one the SDK runs for you (see “Fail-closed behavior” below).
3. Local host machine compromise
- Attacker goal. Extract encryption keys and cached database records directly from the client device.
- Mitigation. The master key lives in the OS keychain (not a plaintext file), and memory text is encrypted at rest in local LanceDB under an HKDF-derived
k_rest. A stolen disk or cold backup yields ciphertext, not memories. A fully compromised live host with root or code-execution access as your user can still read the running agent’s process memory or unlock the OS keychain. Zero-knowledge protects transit and storage — it cannot protect a live, fully-owned device.
4. Wholesale ciphertext substitution
- Attacker goal. Swap a valid ciphertext record with a different valid ciphertext from an older write to replay stale state.
- Mitigation.
client_payload_hash—sha256(canonicalize(payload))— covers the entire payload, including itssequence_numberandparent_snapshot, so a substituted (older or different) snapshot’s re-derived hash will not match the one issued at its original write. This is combined with the server’s strictsequence_numberenforcement (must equallatest confirmed + 1, or409 sequence_gap) — see Deterministic Lineage for the full ordering model. Neither check runs automatically; you implement the hash comparison on restore (below).
What actually reaches the server
Semantic memory (store/recall) never leaves the device at all — there’s no replication step for it. For state replication (snapshot/restore/lineage), the server receives exactly:
- AES-256-GCM ciphertext — the encrypted
active_context. client_payload_hash— a SHA-256 integrity anchor over the whole payload, used for idempotency and as the tamper/substitution check’s comparison target.agent_idandsequence_number— used for auth scoping and ordering.agent_idis a value you choose (a common convention issha256(project_id + ":" + some_stable_identifier), but it’s not a mandated derivation — see Authentication).
path_hash, no per-key hashing scheme. Records are flat content strings (semantic memory) or agent_id-scoped sequences (state replication); see Memory Model for the full record shapes.
Dual verification strategy
sovseal uses two complementary cryptographic primitives on every restore, each closing a different attack surface:Key custody
Your keys never leave your device. The table below documents where each piece of key material lives and who can access it:Fail-closed behavior
Technical limitations
Zero-knowledge is a strong guarantee, but it does not defend against every condition. Understand these boundaries before deploying in high-assurance environments:
- Passphrase entropy. If you configure key derivation from a weak or guessable passphrase, the derived AES-256 key is vulnerable to offline brute-force attacks. Use high-entropy secrets.
- Metadata traffic analysis. A server-side observer can still analyze request frequency, sync volume, packet timings, and total ciphertext size to infer general activity levels — even without reading content.
- Device loss. Losing your keychain master key (or, under
SOVSEAL_KEY_FALLBACK=file, the fallback key file) without a backup makes remote snapshots permanently unrecoverable on the Hobby/Starter tiers and the local/MCP tier. Growth, Pro, and Enterprise plans include opt-in Managed Key Recovery — see Account & Device Security for the plan-by-plan breakdown.
Next steps
Verified Semantic Recall
The full two-check pattern and a ready-to-use implementation.
Cryptographic Trust Center
Consolidated threat model, honest compliance posture, and the unforgiving key-recovery boundary.
Deterministic Lineage
How sequence numbers make substitution structurally detectable.
Memory Model
The full record schema — which fields replicate and which stay local.