Attestkeep
Language: English
Sign up
Evidence and audit

An audit trail you cannot quietly rewrite.

Create an accountEvidence trust model
checkpoint 41Merkle root · signedcheckpoint 42Merkle root · signedcheckpoint 43Merkle root · signedprevprevrecord · allowedrecord · deniedrecord · allowedrecord · allowedrecord 18342 · deniedrecord 18342 · allowedrecord · allowedrecord · deniedrecord · allowedrecord · allowededited with SQLLedger check, run when the next evidence document is generatedchain every checkpoint links to the one beforesignatures valid against the installation keyrecords 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 what this feature records.

Install it yourself.

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

Create an account