Tamper-evident vs tamper-proof: a verifiable LLM audit trail
Tamper-proof prevents change; tamper-evident makes it detectable. Only one is achievable for software logs. How a hash chain + RFC 3161 anchor + offline verifier get you there.
Two words that are not synonyms
"Tamper-proof" and "tamper-evident" get used interchangeably in security marketing. They mean opposite things, and the difference matters when an auditor is reading your claims.
- Tamper-proof means change is prevented. For software logs this is essentially unachievable: whoever runs the system can, in principle, alter what it stored. Anyone who tells you their application logs are "tamper-proof" is overclaiming.
- Tamper-evident means change is detectable. You cannot stop a motivated insider from editing a record, but you can make any edit impossible to hide. That is a claim you can keep — and it is what a regulator needs, because a record that can be silently changed is not evidence.
So the honest target for an audit trail is tamper-evident. Here is how you get there.
Step 1: chain the records with a hash
Give every audit record a row_hash computed over its stable fields plus the hash of the previous record:
row_hash = SHA256( prev_hash + newline + canonical(record) )
Because each hash folds in the one before it, the records form a chain. Change a single field in record 13 — flip a blocked attack's score from 0.86 to 0.06, say — and record 13's recomputed hash no longer matches what was stored. The break is localised and obvious. To verify, you recompute every hash from a fixed genesis value and compare it to what is recorded. One byte changed anywhere lights up.
That already buys tamper-evidence within the exported set. But it has a gap.
Step 2: anchor the head to an independent clock
A hash chain you control proves internal consistency, but nothing stops you from rebuilding the whole chain after the fact with different contents — the new chain is also internally consistent. You need an outside reference that says "this chain head existed no later than time T", and you must not be the one holding the clock.
That is what an RFC 3161 timestamp provides: you send the hash of the chain head to an independent Time-Stamp Authority, which returns a signed token binding that hash to a time. Now you cannot silently backdate or rewrite history that predates the anchor without producing a token the authority never issued. A valid timestamp on a broken chain does not rescue it either — the verdict is still "broken".
In production the right anchor is a qualified eIDAS timestamp (a QTSP), which carries legal weight under the eIDAS Regulation. For a public demo, a free authority such as freeTSA works and uses the identical mechanism — it simply is not eIDAS-qualified. Do not let anyone pass off a demo timestamp as a qualified eIDAS one.
Step 3: let anyone verify, offline
The point of all this is to remove yourself from the trust equation. So the verifier has to run without your database and without your servers: a small program that takes the exported bundle, recomputes the chain, checks the timestamp token against the authority's public certificate, and prints a verdict. Your auditor runs it on their own laptop. "Verify, don't trust" is only true if they don't have to call you.
What it proves — and what it doesn't
Be precise, because over-claiming here is how you lose a technical buyer:
- Proves: integrity — the exported records form an unbroken chain that was not silently rewritten before the timestamped anchor.
- Does not prove completeness: a bundle is a snapshot; records that were never exported are invisible. The chain verifies over what is shown.
- Does not prove origin: that the records came from your system rather than someone else's needs a signature, which is a separate (later) step.
Try it
You can run this yourself on a real (synthetic) Senthex bundle: recompute the chain in your browser, tamper one byte, and watch chain_ok flip from true to false — then re-run the offline Python verifier for the identical verdict. For the regulatory framing of why you keep this record at all, see EU AI Act Article 12 & 19 logging. One honest caveat: Senthex's verifiable chain is a pilot capability today, not the published release.
By Yohann Sidot