Sealkeep architecture and data flow

Status: Published architecture summary
Reviewed: 2026-09-04
Scope: Sealkeep client, hosted service, and enterprise self-hosted modes

Security objective

Sealkeep preserves coding-agent session history while keeping archive plaintext and private decryption material at customer endpoints. The service processes ciphertext and the operational metadata required for storage, membership, retrieval, and audit.

This document describes the intended boundary. It is not an independent audit.

Common endpoint flow

Claude Code / Codex session
          |
          v
Local Sealkeep adapter and durable queue
          |
          v
Endpoint encryption + locally wrapped archive key
          |  plaintext ends here
          v
Ciphertext + opaque operational metadata
          |
          v
Selected control plane and object storage

The endpoint performs capture, encryption, local search, decryption, and recovery. The hosted service is not designed to receive a recovery phrase, device private key, plaintext archive key, customer storage credential, or session plaintext.

Deployment modes

Hosted or managed

Spala operates the account/control-plane service and may arrange encrypted object storage. The endpoint still encrypts session content before upload. Spala processes account, device, entitlement, membership, object-routing, ciphertext, checksum, and audit data needed for the selected service.

Connected self-hosted

The customer operates the application, PostgreSQL, logs, and object storage. A documented outbound licence-validation path to Spala may remain. Its fields, frequency, retention, and failure behaviour must be approved for the deployment.

Fully isolated self-hosted

The customer operates the application, PostgreSQL, object storage, identity, logs, backups, region, and network. The deployment uses an offline entitlement and has no mandatory Spala-hosted API, database, object store, authentication, telemetry, or licence request during ordinary operation.

Customer endpoint
  plaintext session + customer-held keys
          |
          | endpoint encryption
          v
Customer-operated Sealkeep service <--> Customer PostgreSQL
          |
          | encrypted archive objects
          v
Customer-controlled object storage

Spala may separately retain business-contact, contract, licence-delivery, update, or support data. Support material is received only when the customer elects to disclose it or authorises a time-bounded support path.

Data visibility

Ciphertext size, timing, identifiers, and operational metadata are not represented as anonymous. Source paths and local search content normally remain at the endpoint.

Key custody and access limits

• Each archive uses a fresh random 256-bit data-encryption key.
• Archive keys are wrapped locally for configured phrase and device recipients.
• Recovery phrases and device private keys are not sent to the service.
• Support cannot decrypt an archive or recover a lost phrase.
• Revoking a device blocks future service operations. It cannot withdraw a copy and

key already obtained before revocation.

• The current Team model preserves access through remaining accepted project members.

It does not yet claim a separate organisation recovery recipient or transferable project-owner role.

Known assurance limits

• The cryptographic format uses published authenticated-encryption primitives and

has deterministic vectors and tamper tests, but has not completed an independent cryptographic audit.

• JavaScript zeroisation is best effort.
• Ciphertext length and timing reveal operational information.
• Fully isolated delivery must pass a customer-observed egress-denied acceptance test.

Questions: security@spala.ai