MICKAI
Article · 8 July 2026

Tamper-Evident Logging for AI: What Forensics and Audit Actually Need

Tamper-evident logging binds every AI action into a hash-chained, signed, append-only ledger so any later change is detectable by an independent examiner offline.

Tamper-Evident Logging for AI: What Forensics and Audit Actually Need
Author
Micky Irons
Published
8 July 2026
Follow Micky Irons
LinkedInX
tamper-evident loggingai auditforensicsfips 204ml-dsa

Tamper-evident logging for AI means every log entry is cryptographically bound so that any later change, deletion or reordering is detectable by an independent party. It is achieved by three mechanisms working together: hash-chaining that links each entry to the one before it, a per-entry digital signature that proves who wrote the entry and that its content is unaltered, and append-only storage that admits new records but never silent edits. The single reason this works is that a forensic examiner can recompute the chain from the raw records and see, mathematically, whether the sequence is intact, without trusting the system that produced it.

This is a specialist requirement, not a general one. If you carry a real audit obligation under DORA, NIS2, GDPR or an emerging AI governance regime, a log the operator can quietly rewrite is worth little in an investigation. As AI systems take consequential actions, a regulator or a court will ask you to prove what the system did, when, and on whose authority, and tamper-evident logging is how you answer with evidence rather than assurances.

What is the difference between tamper-evident and tamper-resistant?

Tamper-resistant means an attacker finds it hard to alter the record: hardened storage, restricted access, sealed hardware. Tamper-evident means that if the record is altered, the alteration cannot be hidden, because the change leaves a mathematical mark anyone can detect. Resistance raises the cost of tampering; evidence removes the ability to tamper silently. Forensics and audit care most about evidence, because an examiner has to prove integrity after the fact, and the two properties are complementary rather than interchangeable.

Tamper-Evident Logging for AI: What Forensics and Audit Actually Need, illustration 1

How does tamper-evident logging actually work?

Three primitives, layered together:

  • Hash-chaining: each entry stores a cryptographic hash of the previous entry, so entries form a chain. Change, reorder or delete a record and the chain breaks at that point.
  • Per-entry signing: each entry is signed with a private key when it is written. The signature proves the entry came from a specific identity and that its contents have not changed since.
  • Append-only storage: the medium accepts new records but refuses in-place edits and deletes, so the only route to changing history is to break the chain, which is detectable.

Add periodic anchoring: publish the latest chain hash to an independent witness at fixed intervals, so even the log owner cannot rewrite the past without contradicting a value recorded elsewhere. The strongest designs bind the signing identity to hardware attestation, so a signature is tied to a specific attested machine, not merely to a copyable key.

Tamper-Evident Logging for AI: What Forensics and Audit Actually Need, illustration 2

What can a forensic examiner prove after the fact?

From the raw records, an examiner can establish four things:

  • Integrity: the sequence has not been altered, or precisely which entry was.
  • Authenticity: each entry was signed by a named identity and, where hardware attestation is used, by a specific device.
  • Completeness: no entry was silently removed, because a deletion breaks the chain.
  • Ordering and timing: entries occurred in the recorded sequence, corroborated by the anchor points.

Crucially, the examiner need not trust the operator's word or the running system. Verification is offline and independent: given the records and the public keys, anyone can recompute and check. Offline verifiability is what separates real evidence from a dashboard that merely reports all is well.

A log is only evidence if a stranger can verify it without trusting the system that wrote it.

Tamper-Evident Logging for AI: What Forensics and Audit Actually Need, illustration 3

Which rules make this necessary?

Several regimes now expect a trustworthy record of automated decisions. DORA has applied to financial entities since January 2025 and demands rigorous incident and operational-resilience evidence. NIS2 imposes similar duties on essential and important entities, GDPR requires accountability when a breach is investigated, and ISO/IEC 42001 sets management expectations for AI systems. Under the EU AI Act, the high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve. A tamper-evident ledger supports these duties by making the record independently checkable, but no architecture by itself certifies compliance.

Tamper-Evident Logging for AI: What Forensics and Audit Actually Need, illustration 4

Where does FIPS 204 fit, and why post-quantum?

Audit records outlive the systems that make them. A ledger you sign today may need to stand up in a dispute a decade from now, by which time a classical signature could be forgeable by a quantum adversary. FIPS 204 standardises ML-DSA, the post-quantum digital signature algorithm; it is what signs the ledger, so the signatures stay verifiable and unforgeable against a future quantum attacker. FIPS 203 is a different standard: it specifies ML-KEM, a key-encapsulation mechanism for establishing shared keys. ML-KEM does not sign anything and provides no verifiability, so crediting it with signing is a common and consequential error. For tamper-evident logging you want FIPS 204 signing the chain; FIPS 203 belongs to protecting data in transit, not to proving a record is intact.

How does an AI deployment change the requirement?

Public cloud AI services send prompts and outputs to infrastructure the buyer does not control. For a regulated buyer that creates exposure: the record of what the model saw and did sits with a third party, potentially reachable under foreign law such as the US CLOUD Act, and a contractual logging promise is not a technical guarantee. Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs offline on operator-owned hardware behind a zero-egress inbound perimeter, and every action is sealed into a post-quantum signed, hash-chained ledger at the moment it happens. Identity is hardware-attested and bound to the chain, so an entry names not just a user but the attested machine, while cross-model consensus records where independent sovereign models agreed or diverged on a decision. Our approach to sealing autonomous actions is described across 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, filed and patent pending, never granted or patented. The design supports an audit duty by keeping the record verifiable offline; it does not, and no architecture can on its own, certify compliance with any regulation.

Frequently asked questions

Is tamper-evident logging the same as a blockchain?

No. A blockchain is one way to distribute and anchor a tamper-evident log across many parties. Most audit needs are met by a simpler hash-chained, signed, append-only ledger with periodic anchoring to an independent witness. You get detectability without the cost and complexity of a public consensus network. Blockchain is a design choice, not the underlying requirement.

Can an administrator with full access still fake the logs?

They can try, but they cannot do it silently. Any edit breaks the hash chain, and any forged entry fails signature verification unless the attacker also holds the signing key. If that key is bound to hardware attestation and the chain is anchored to an outside witness at intervals, even a full administrator cannot rewrite history without leaving a detectable contradiction.

Does using a cloud AI service breach your audit obligations?

Not automatically, and it would be wrong to state it as settled fact. But sending regulated data to a service you do not control creates exposure: the evidence lives outside your custody and a contractual logging promise is not a technical guarantee. Running inference on your own hardware with a tamper-evident ledger keeps the evidence and its verification in your hands.

Why post-quantum now, when quantum computers cannot yet break signatures?

Because audit records must stay provable for years or decades. A signature you rely on today could be forgeable by the time a dispute reaches a court. Signing the ledger with FIPS 204 ML-DSA now means the evidence remains verifiable and unforgeable against a future quantum adversary, without re-signing everything later.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/tamper-evident-logging-for-ai-what-forensics-and-audit-actually-need. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles