Evidence governance

Use signatures, audit chains, archive recovery, and retention to prove operations records.

opsctl distinguishes runtime logs from verifiable evidence. The audit chain orders actions, signed checkpoints bind its head, and archive drills prove evidence can be recovered and verified again.

Create an evidence key

opsctl registry drift cleanup-request evidence-keygen \
  --key-id <key-id> --execute --json

Keys are never generated or rotated automatically. Operators control private material, while public keys receive explicit trust lifetimes.

Sign and verify

opsctl registry drift cleanup-request audit-checkpoint \
  --key-id <key-id> --execute --json

opsctl registry drift cleanup-request evidence-verify-all --json

Production should have at least two independent trusted keys and checkpoints from both. Revocation preserves historical public-key material.

Archive drill

The complete evidence archive chain is:

Sign a manifest.
Export a create-new audit bundle.
Sign the bundle separately.
Write it to a controlled Restic/rustic repository.
Restore into isolation and verify the bundle and detached signature.
Remove staging and record the drill result.

Retention attestation

A signature is not immutability

opsctl can verify an operator-signed retention attestation, but an external object store must actually enforce and independently confirm Object Lock or WORM policy.

A valid attestation needs the exact repository, a fresh observation, future retain-until, enabled Object Lock, independent verification, and two distinct reviewers. Missing any condition remains blocked.

MCP boundary

MCP exposes read-only reports and dry-run tools. Trust mutation, signing, archive writes, and retention import are not automatic MCP operations.