Sealkeep technical and organisational measures — inspectable sample

Status: Public control statement; scope completed for the selected deployment
Reviewed: 2026-09-04

This statement supports security review. It is not an independent certification. The applicable scope and customer-operated responsibilities are completed for the selected hosted or self-hosted deployment when incorporated into an agreement.

Implemented product controls

Data minimisation and cryptography

• Coding-agent session content is encrypted on the endpoint before upload.
• Each archive receives a random data-encryption key, wrapped locally for configured

phrase and device recipients.

• ChaCha20-Poly1305 or AES-256-GCM provides authenticated encryption through the

Node/OpenSSL implementation.

• Chunk metadata binds archive identity, suite, order, count, length, and finality.
• Recovery phrases, device private keys, plaintext archive keys, plaintext session

content, and customer storage credentials are not designed to enter hosted logs or configuration.

• Local HTTP APIs bind to loopback, require a local token for state, and do not expose

a decryption endpoint.

Access and tenant boundaries

• Devices use separate public/private key identities; the private key stays local.
• Control-plane device requests use signatures, timestamps, and replay-resistant

nonces in the documented self-hosted interface.

• Hosted records are scoped to the authenticated account or project.
• Destructive archive operations require separate authority and produce audit events.
• Team access uses project membership and keys wrapped for authorised members.
• Recalled historical text is treated as untrusted input.

Durability and recovery

• A local source is not eligible for reclamation until a remote encrypted copy has

been verified.

• Ordinary reclamation stages the local source through a recoverable boundary rather

than silently treating upload initiation as durability.

• Restore verifies authenticated chunks and the whole-plaintext digest.
• Loss of all recovery recipients is not support-recoverable by design.

Secure development evidence

• Type checking and automated tests cover crypto tampering, restoration, queue crash

recovery, upload verification, signed requests, tenant boundaries, and team flows.

• The repository contains deterministic cryptographic vectors, provider emulators,

acceptance scenarios, and live company-flow rehearsal records.

• Dependency versions are recorded in a lockfile.
• Release tooling can create SHA-256 manifests and supports signing when the release

key is deliberately supplied.

Operational measures requiring deployment evidence

The following must be verified for the actual production service or supplied by the customer in a self-hosted deployment:

• named administrative identities, MFA, least privilege, and periodic access review;
• network ingress and database exposure configuration;
• secret-management and rotation process;
• production change approval, rollback, and vulnerability-remediation targets;
• log access controls, retention, alerts, and on-call routing;
• backup frequency, RPO/RTO, region, expiry, and restore-test record;
• personnel security training and joiner/mover/leaver evidence;
• incident exercise record and customer-notification operation;
• production retention and deletion evidence;
• verified Subprocessor contracts, locations, and transfer safeguards.

These are intentionally not marked complete merely because corresponding application code or a written policy exists.

Customer-operated controls in fully isolated deployment

The customer operates runtime infrastructure, network, PostgreSQL, object storage, TLS, identity, administrator access, secrets, monitoring, backups, disaster recovery, regions, patch timing, endpoint custody, retention, and deletion. Spala has no standing administrator access. Customer-approved support access must be time-bounded, least-privileged, attributable, and revocable.

Assurance boundary

• No completed independent cryptographic audit is claimed.
• No SOC 2 or ISO 27001 certification is claimed.
• JavaScript zeroisation is best effort.
• Ciphertext length and timing reveal operational information.
• Release manifests do not equal an OS code-signing certificate.

Security questions: security@spala.ai