Durable State Backup (AICEP v0.2 draft)

AICEP v0.2 DRAFT. Published 2026-10-26. Key words MUST / SHOULD / MAY per RFC 2119. Touches §10 Bus, §14 Classification, §18 Conformance.

10.5.1 Rule (MUST). A deployment whose agents keep working state on a shared or hosted computer MUST take a backup of that state at least once every 24 hours, store at least one copy off that computer, and verify restore on a schedule (10.5.6). Working state includes drafts, reports, notes, prompt and configuration files, and uncommitted or unpushed code.

10.5.2 Exclusions (MUST). Before any data is read for backup, implementations MUST exclude credentials, API keys, tokens, cookies, passwords, private keys, environment files, and any file containing a private-key header, plus caches, virtual environments and dependency folders. Key values MUST NOT appear in arguments, logs or status output; only key locations MAY be logged.

10.5.3 Format (MUST).

1. Manifest. One signed, encrypted backup.manifest envelope per stream per day. Manifest time-to-live MUST be ≤ 24 h.
2. Chunks. Data is split into chunks below the store's per-object limit, compressed, encrypted to the stream's recipients, and named by a keyed hash of the plaintext so equal content deduplicates without exposing plaintext hashes. The manifest pins every chunk by ciphertext hash. A daily differential writes only new chunks.
3. Compartments. A never_publish stream MUST use its own compartment; publish surfaces MUST refuse any object from it (§14).

10.5.4 Storage (MUST). Manifests and chunks MUST be written atomically into a store that survives a reset of the working computer. An off-box mirror MUST receive ciphertext only, over HTTPS with certificate verification, with opaque object names and no descriptive metadata. The backup client MUST NOT delete; pruning is the storage lifecycle's job. Where the store supports object locks, objects MUST be write-once. Retention SHOULD be 14 days; unreferenced chunks MAY be pruned only after a fully successful run.

10.5.5 Keys (MUST). Encryption and signing keys MUST live outside every backed-up path with owner-only permissions; key paths under a backup root MUST be refused. The owner MUST hold an escrow copy of the keys off the working computer. Production MUST use a native, pinned cryptographic implementation; test doubles MUST NOT be reachable outside tests.

10.5.6 Restore and verification (MUST). Restore MUST run full ingest on the manifest (registry, signature, sequence chain, ciphertext hashes) before fetching any chunk, verify each chunk's ciphertext hash before decrypting, verify each file's plaintext hash after reassembly, and restore into a scratch folder unless the operator chose in-place. Expiry and revocation MUST be evaluated at the live time and fail closed. Restore of an expired manifest is a manual-only archival mode requiring explicit human confirmation and an audit-log warning (§10); it MUST NOT be reachable from automated paths.

10.5.7 Operation (SHOULD). The nightly SHOULD be one deterministic command requiring no model reasoning: bounded by a time budget, checkpointed and resumable, non-interactive, and emitting exactly one status line on every exit path. A separate daily dead-man check MUST fail if there was no successful run in 26 h, a manifest is missing, the restore check is overdue, or a stale lock remains.

10.5.8 Failure handling (MUST). Automated recovery is limited to a fixed table of bounded, non-destructive actions (take over a stale lock; resume a killed run; retry transient I/O with backoff; quarantine, never delete, a corrupt chunk and re-send it from source). Any other failure MUST alert a named human. Escalation MUST go to a human, not to a higher model tier.

Rationale (non-normative). Hosted agent workspaces can be reset or rolled back as routine maintenance. Work that exists only on the working computer is lost with it, and agents often don't notice the loss. Daily caps the loss at one day; off-box survives the reset; encryption keeps sensitive state private; tested restore turns a backup from a hope into a guarantee.

10.5.9 Conformance. An implementation claiming "durable" conforms (§18) only if it can show a passing restore-verify within the last 50 h and a passing dead-man check within the last 24 h.

Background (non-normative): Why Your AI Agents Need a Daily State Backup. Related: Security: External Intake Gate.