Public procurement evidence · reviewed 4 September 2026
Sealkeep threat model — public summary
Assets
Coding-agent transcripts may contain prompts, source code, commands, credentials, business context, and personal data. The primary assets are session plaintext and the recovery phrase or device private keys that can open an archive.
Trust assumptions
| Party | Trusted for | Not trusted for |
|---|---|---|
| Local client process | Plaintext handling, encryption, key generation | — |
| Local OS account | Reading its own agent files | Protection after account compromise |
| Control plane | Availability, identity, membership, operational metadata | Transcript confidentiality |
| Object storage | Durability | Confidentiality or authenticity |
| Network | Nothing | Confidentiality, integrity, availability |
| Local MCP client/model | Requesting authorised tools | Treating recalled historical text as trusted instructions |
Principal adversaries and controls
Breached control plane
The service can see account/device identifiers, archive identifiers, size, timestamps, checksums, object routes, and encrypted manifests needed for operation. It is not designed to receive archive keys, recovery phrases, device private keys, or session plaintext. It can deny service or lie about metadata, so clients verify downloaded objects and refuse reclamation on failed durability checks.
Stolen archive object
An object contains authenticated ciphertext under a fresh per-archive 256-bit key. Opening it requires an authorised recipient secret or compromise of the published cryptographic primitive. Object size and chunk count remain visible.
Archive tampering
Authenticated data binds format version, suite, archive identity, chunk position, total count, plaintext length, and finality. Tests cover bit flips, reordering, truncation, cross-archive splicing, suite downgrade, and rewritten cheap hashes.
Compromised endpoint or OS user
An attacker running as the developer can already read the original agent session. Endpoint compromise is therefore outside the archive's confidentiality boundary. Sealkeep avoids ordinary config storage for phrases and private keys, applies owner-only local permissions, and excludes secrets from normal logs. OS keystore access by processes running as the logged-in user remains a stated trade-off.
Lost or stolen device
Devices are separate X25519 recipients. Service revocation blocks future operations; recipient removal and key rewrapping remove future archive access. Revocation cannot withdraw ciphertext and key material an attacker copied beforehand.
Replayed transfer capability
Transfer leases are short-lived, single-object capabilities. Expiry is checked and object routes are server-selected. A stolen upload capability cannot be used to read another archive or freely choose a storage key.
Malicious recalled context or model request
The MCP service is local but model-driven. Search is bounded, recovered historical text is labelled untrusted, destructive actions require explicit authority, and native restore is constrained to supported transcript roots.
Cryptographic construction
- ChaCha20-Poly1305 by default or AES-256-GCM through Node/OpenSSL.
- Fresh random 32-byte key per archive.
- Per-archive random nonce prefix plus a 64-bit chunk counter.
- scrypt-derived phrase wrapping; X25519 and HKDF-SHA256 device wrapping.
- Per-chunk authenticated tags and hashes plus a whole-plaintext digest on restore.
No custom encryption primitive is claimed.
Known limitations
- Ciphertext length and timing reveal operational information; no padding is applied.
- Source path and selected metadata may exist in cleartext in the local vault record.
- A compromised recovery phrase can open every archive for which it remains a recipient.
- JavaScript memory zeroisation is best effort.
- Recorded scrypt parameters balance current endpoint responsiveness and can be raised
for new archives without changing old ones.
- Device revocation is not retroactive for copies already obtained.
- Current Team continuity depends on remaining accepted project members; there is no
claimed separate organisation recovery recipient or transferable owner today.
Open independent-assurance gates
- Independent third-party review of the archive format and implementation.
- External review of the key and organisation-recovery lifecycle.
- Public package/test-vector publication for the reviewed release.
- Independent application penetration test and remediation summary.
Security reports: security@spala.ai