Zero-Knowledge Guarantees

sovseal is architected on a zero-knowledge security model. Cryptographic keys and plaintext payloads never cross the local device boundary. The replication endpoint (whether managed Platform or Self-Hosted) acts purely as an opaque ciphertext store.

What the Server Sees vs. Cannot See

                      ┌─────────────────────────────────┐
                      │  Replication Server's View      │
                      ├─────────────────────────────────┤
SEES         ►        │  • AES-256-GCM ciphertext bytes │
                      │  • SHA-256(path) — opaque hash  │
                      │  • project_id (auth scope)      │
                      │  • content length               │
                      │  • timestamp                    │
                      ├─────────────────────────────────┤
CANNOT SEE   ►        │  • plaintext content            │
                      │  • path / key name              │
                      │  • embedding vector             │
                      │  • the encryption key           │
                      │  • metadata fields              │
                      └─────────────────────────────────┘

Formal Threat Model

We design our system to maintain confidentiality and integrity against four primary attacker profiles:

1. Passive Network Observer (MITM)

• Attacker Goal: Intercept sync packets on the public network to read agent memory.
• Mitigation: All sync requests run over HTTPS. Even if TLS is terminated or compromised, the payload is encrypted with AES-256-GCM client-side. The network observer only sees opaque ciphertext.

2. Malicious or Compromised Replication Server

• Attacker Goal: Read stored memories or inject false state variables to poison the agent's context.
• Mitigation: The server does not hold the decryption keys. Payload integrity and chronological substitution are audited via Verified Semantic Recall (VSR). Any attempt to return modified or replayed snapshots is immediately detected by the client.

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 — so a stolen disk or cold backup yields ciphertext, not memories. A fully compromised live host (root / code execution as your user) can still read the running agent's process memory or unlock the keychain. Zero-knowledge protects transit and storage; it cannot protect a live, fully-owned device.

4. Wholesale Ciphertext Substitution

• Attacker Goal: Swap out a valid ciphertext record with a different valid ciphertext record that was captured from an older write.
• Mitigation: The client-side re-derivation of the snapshot_id (incorporating the parent hash) detects substitution immediately. The client will identify that the received snapshot is out of sequence or belongs to a different lineage path, failing closed.

Path Hashing & Non-Enumeration

To allow the replication server to enforce sync state and deduplicate snapshots without learning the structure of your database paths:

• Paths are hashed locally before transmission: path_hash = sha256(path).
• If you store a record at "user.preferences.testing", the server only sees 4f3ad801....
• Because SHA-256 is one-way, the server cannot guess key names or reconstruct your database schema. However, since the hash is deterministic, the server can still route updates to the same logical record path, enabling efficient state replication.

AES-256-GCM Auth Tags vs. SHA-256 Audit Closure

sovseal uses a dual-verification strategy to validate incoming records from the replication server:

Fail-Closed Behavior

When the client detects a verification error (either a decryption tag mismatch or a snapshot ID lineage discrepancy):

• No Fallback: The SDK throws a VsrFailureError (or DECRYPT_FAILED error) and halts the read lifecycle. It does not fall back to serving raw ciphertext or unverified stale local database records.
• Halting / Quarantine: Your agent process must catch this error. The default behavior is to fail closed, protecting the agent's logic from acting on poisoned, outdated, or corrupted memory states.

Technical Limitations

While zero-knowledge is highly secure, it does not defend against the following conditions:

• Passphrase Entropy: If you configure your key derivation based on a weak, guessable passphrase, the derived AES-256 key is vulnerable to offline brute-force attacks.
• Metadata Traffic Analysis: A server observer can still analyze request frequency, sync volume, packet timings, and total ciphertext size to infer general activity levels.
• Device Loss: If you delete the configuration file containing your encryption key without keeping a backup, the remote snapshots become permanently unrecoverable.

Next

• Cryptographic Trust Center — Detailed overview of our threat model, key custody boundaries, and compliance posture.
• Verified Semantic Recall — Detailed overview of how we cryptographically verify recalled memories.