Audit chain

Every decision is written to an append-only, hash-chained log. Periodic checkpoints are published so a record cannot be altered after the fact without detection.

Compliance regimes are increasingly asking what an autonomous system did and who authorized it. "We have application logs" does not survive a control test — a record has to be structured, complete, and provably unaltered.

Append-only and hash-chained

Each entry includes the hash of its predecessor. Editing or deleting any record breaks verification from that point forward, and the break is detectable.

Audit recordJSON

{  "seq": 918442,  "ts": "2026-08-06T09:14:02.118Z",  "prev_hash": "sha256:41c9…8ea2",  "hash": "sha256:7bd0…19f4",  "decision_id": "dec_01JQ8F2K7M",  "agent": { "id": "agt_3H8N1P", "owner": "marcus@example.com" },  "action": "k8s.apply",  "resource": "production/checkout",  "verdict": "permit_after_approval",  "policy": "require-approval-prod-deploy",  "approval": {    "approver": "sam@example.com",    "channel": "slack",    "granted_at": "2026-08-06T09:13:44.902Z"  },  "checkpoint": "ckpt_2026-08-06T09:00Z"}

What tamper-evidence proves — and what it does not

Read this before you rely on the chain for anything

A hash chain proves records were not altered after they were written. It does not prove a record was written truthfully in the first place — that property comes from the enforcement path, not from the log. Tamper-evidence is also not tamper-proofing: someone with sufficient access can destroy a log, and the chain guarantees that doing so is visible, not that it is impossible.

Verifying independently

TerminalShell

$ cirvix audit verify --from 2026-08-01   Verifying decision chain  range       2026-08-01T00:00Z → 2026-08-06T09:31Z  records     918,442 → 962,117            (43,675 records)   recomputing hash chain…                  ok  checkpoint  ckpt_2026-08-01T00:00Z       matched  checkpoint  ckpt_2026-08-06T09:00Z       matched   chain intact · 0 gaps · 0 mismatches

Verification is independent — it recomputes the chain rather than asking the service whether it's intact, and checkpoint roots are published on a schedule so an auditor can witness them with a tool you do not control.

Exporting evidence

Exports are formatted to match what a SOC 2 or ISO 27001 control test, or the EU AI Act's logging expectations, actually looks for.

Note

No SOC 2, ISO 27001, or FedRAMP audit of Cirvix itself has been completed — see the Security page for the honest state of that roadmap. These exports are shaped to match the evidence a control test expects; they are not a certification of Cirvix.

Limits

Cirvix does not certify you against any framework. It produces evidence; an auditor reaches the conclusion.

Exporting audit evidenceVerify, scope, and export a range.Hardening checklistWhere audit fits in a production-ready deployment.

Edit this page on GitHub

Was this page helpful?