Security Operations

Status: v1.4 control summary. Effective at general availability.

Aletheia uses a local-first design and treats customer binaries as hostile.

Core Controls

• Production binary selection is available only in the signed desktop. Binaries are encrypted in an OS-keychain-bound local vault and decrypted only into an owner-only ephemeral session directory.
• Analysis runs in a signed, pinned, networkless Docker worker on the user's device with a read-only root, all capabilities dropped, no Docker socket, scrubbed credentials, and bounded memory, CPU, PIDs, file descriptors, time, and output.
• The cloud is a control plane for authentication, billing, tenant authority, model orchestration, continuation, and bounded derived evidence. Every local tool call is bound to an enrolled device, lease, tenant, run, binary hash, signed worker image, and signed tool catalog.
• Production HTTP and WebSocket binary-ingress paths reject before reading or decoding customer bytes. The browser cannot analyze a binary without an online enrolled desktop node.
• Customer binaries are never natively executed by the cloud service. Guest execution, when included in a licensed build, is emulator-only.
• Raw customer binaries cannot enter the cloud control plane, model prompts, production Postgres, R2 backups, or the external purge registry.
• Derived evidence expires after 30 days and can be deleted earlier. Purge tombstones are replayed across database restore boundaries.
• Account purge stops local execution before deleting the vault and native vault/device keys, deletes cloud enrollment/device authority, disconnects every tenant-owned local tunnel, and only then purges derived evidence. Unknown vault entries or any shutdown, keychain, or authority-deletion failure prevents a false successful completion.
• Provider spend has tenant and global circuit breakers. Security events use a bounded vocabulary and pseudonymized tenant identifiers.
• Releases are built from frozen revisions, signed, notarized, accompanied by checksums/SBOMs/licence inventories, and promoted without rebuilding.

Operational Response

Security events cover authentication failure, tenant-boundary denial, binary-ingress rejection, local-worker identity/protocol/limit failures, sustained rate limiting, webhook failure, backup/purge failure, and provider-spend rejection. Alerts and runbooks cover readiness, connected-worker failures, webhook errors, backup age, purge failures, and provider budget.

Backups are encrypted before upload and hash-verified. Monthly drills restore to a disposable database and replay the external purge registry before use.

Vulnerabilities should be reported under the Security Disclosure Policy. The service makes no claim that automated analysis is complete; machine-checkable replay and proof status remain part of the product's evidence model.

Last reviewed: 2026-07-28.