security: hardening backlog — journal integrity, checkpoint at-rest encryption, API rate limiting #35

Backlog record from the 2026-07 whole-project review — secondary hardening items, none blocking, each with its reopen trigger. The primary posture (trust boundaries, deployment assumptions) is documented in docs/security.md.

1. Audit/usage journal integrity + shipping. audit.jsonl/usage.jsonl are local JSONL with size rotation — a host compromise can rewrite history, and a full disk silently ends the audit trail. Options when triggered: hash-chained records (cheap, tamper-evident) and/or a documented ship-off-node pattern (vector/fluent-bit tail → object store). Trigger: a compliance requirement, or the first deployment where the journal is the billing source of truth across trust domains.

2. Checkpoint at-rest encryption. A checkpoint embeds full guest memory, including any secret the workload held at capture. Today the mitigation is operational (S3 SSE / encrypted mount, docs/security.md #5). Native envelope encryption (per-checkpoint key, KMS-wrapped) would remove the operator dependency. Trigger: multi-tenant deployments where the store operator is not trusted with tenant data, or a customer asks.

3. API rate limiting. The control plane's only guards are capacity caps (max_claims, per-tenant caps → 429). A misbehaving-but-authorized client can hammer non-claim endpoints (listings, checkpoint create) freely. Cheap shape when triggered: per-token token-bucket on the resource-creating verbs, config-off by default. Trigger: the first shared deployment where a tenant's automation loop degrades a node, or exposure to semi-trusted callers.

Hot-path cost when implemented: 1 and 3 are control-plane only; 2 adds encrypt/decrypt to checkpoint/restore (off the claim path, measurable at implementation time).