Evidence and audit

An audit trail you cannot quietly rewrite.

checkpoint 41 Merkle root · signed checkpoint 42 Merkle root · signed checkpoint 43 Merkle root · signed prev prev record · allowed record · denied record · allowed record · allowed record 18342 · denied record 18342 · allowed record · allowed record · denied record · allowed record · allowed edited with SQL Ledger check, run when the next evidence document is generated chain every checkpoint links to the one before signatures valid against the installation key records tampered_record_ids: [18342] intact: false
Flip one verdict in the database and the next document names that record.
What it does

Audit trail

Every admission decision is hashed when it is written and sealed under signed checkpoints that chain back to the first one. The signing key lives in a Secret in your cluster, not in the database, so rewriting history takes two different accesses.

Every evidence document re-checks the whole ledger and says whether it is intact. Changes made through the console, from policy edits and break-glass to triage and evidence exports, are kept in a separate audit log with who and when.

How it works

Step by step.

  1. Each record is hashed

    SHA-256 over its content, by the operator, when it is written.

  2. Records are sealed

    Hourly by default, or every 10,000 records: a signed Merkle root.

  3. Seals are chained

    Each checkpoint carries the hash of the one before.

  4. Every document re-checks

    Chain, record hashes, roots and counts, signatures.

  5. Tampering is named

    An edited record appears by id.

What it records

The ledger check's result, intact or not and why, is a section of every evidence package.

Evidence trust model

57 clauses across 11 frameworks cite at least one of these statements.

Install it yourself.

Create an account, confirm your e-mail with the code we send, take the free Community key from the Licenses page, and install with Helm.

Create an account