Home  /  Blog  /  AI Governance & Evidence  /  Tamper-Evident Audit Logs: Why Signed Beats Logged
AI Governance & Evidence

Tamper-Evident Audit Logs: Why Signed Beats Logged

A hash chain and signature make changes to recorded, checkpointed events detectable when the verifier trusts the key. They cannot prove that omitted events were captured or that the current deployment is covered.

SPOKETarget: tamper-evident audit logPublished 2026-06-19

What is a tamper-evident audit log?

A tamper-evident audit log lets a reviewer detect changes to recorded events after a trusted checkpoint. An ordinary log can be rewritten by someone with access; a linked log gives a reviewer a way to test whether the recorded sequence still matches a previously held head.

It does not prevent tampering or prove every event was captured. If one party controls both the log and its only checkpoint, that party can replace both. The useful property comes from a verified hash chain, a signature, and a checkpoint or key reference held separately from the publisher.

How does a hash chain make tampering detectable?

A hash function maps an input to a fixed-size digest. In a hash chain, each entry includes the digest of the previous entry, so changing one recorded event changes every later link.

A verifier can walk the entries, recompute their digests, and compare the final head with a trusted earlier checkpoint. A mismatch exposes a change to the recorded sequence. Internal consistency alone cannot show that the publisher did not rewrite the whole chain or omit events before checkpointing.

What does the signature add that the hash chain doesn't?

A hash chain links records; a signature binds a particular chain head to the holder of a private key. The verifier checks the exact signed bytes against the matching public key. This is a local calculation, but identifying the publisher still requires a public key trusted through a separate channel.

A valid ed25519 signature does not prove when the record was made, whether every action was captured, or whether the current hosted system matches it. Those questions need timestamp, capture, and deployment evidence beyond the signature.

Why “signed, not logged”, and can you verify ours?

A signed, checkpointed log offers a checkable claim about a recorded sequence when the verifier has a trusted key and a separately held checkpoint. It does not, by itself, establish a complete operational history.

The site currently publishes a dated ed25519-signed record and declaration hash. Its browser check uses a same-site key; it does not walk the audit stream, verify the current deployment, or establish independent key authenticity. Treat it as a limited example of the signature check. See the governed control-plane model and the release evidence boundaries for the wider requirements.

Request updates

One system at a time.

Request occasional mechanism teardowns by email. This form sends your request through Web3Forms; email hello@kineticgain.com to withdraw it.

Start the conversation Email