How do you prove an AI agent's audit log was not altered, before EU AI Act Article 12?

How do you prove an AI agent's audit log was not altered?

You cryptographically sign every log record at the moment it is created, and chain each record to the one before it. That produces a mathematical proof: an auditor recomputes the signatures and hashes independently, and if a single byte was changed, added, reordered or deleted, verification fails. Access controls tell you who was allowed to touch the log. Signing tells you whether anyone actually did. Only the second answer survives a hostile audit, and that is the bar EU AI Act Article 12 is moving the market toward.

The direction is set by dates and by penalties. From 2 August 2026 the EU AI Act switches on its general-purpose AI enforcement powers and its penalty regime, with fines reaching up to 7 percent of global annual turnover. The standalone high-risk obligations under Annex III, which carry the detailed record-keeping duties Article 12 describes, have been deferred to 2 December 2027 under the Digital Omnibus. So the fines and oversight arrive first, and the full weight of the high-risk logging duties lands later. Either way, engineers increasingly treat cryptographic signing, using post-quantum schemes such as ML-DSA under FIPS 204, as the bar that access controls cannot clear. If your log can be edited by an administrator and still look intact, it is not tamper-evident. It is tamper-hopeful.

Why are access controls not enough?

Access controls are a gate. They decide who gets in. They record nothing about what a legitimate insider, a compromised credential or a privileged administrator did once inside. When your defence is "only three people can write to this table", the auditor's next question is obvious: what stops one of those three from editing a record and covering their tracks? With permissions alone, the honest answer is nothing you can prove.

This is the gap Article 12 exposes. The regulation does not ask you to promise your logs are trustworthy. It expects events to be automatically recorded over the system's lifetime and to support tracing in a way that holds up under independent examination. A log that only its owner can vouch for fails that test, because the owner is exactly the party an auditor cannot take on trust.

What does tamper-evident actually mean here?

Tamper-evident does not mean tamper-proof. Nobody can make data physically impossible to alter. It means any alteration is detectable, and detectable by someone who does not trust you. The mechanics are well established:

• Each record is hashed and cryptographically signed the instant it is written.
• Each record includes the hash of the previous record, forming a chain.
• The signature and the chain are verified with a public key, not a secret the operator holds.

Change one field in one old record and its hash changes, which breaks the chain for every record after it and invalidates the signature. There is no quiet edit. The failure is loud, specific and reproducible by any third party with the verification key.

Why ML-DSA and FIPS 204 specifically?

ML-DSA, standardised as FIPS 204, is a digital signature scheme designed to resist attack by quantum computers. Audit records for regulated AI are not short-lived. A defence, finance or healthcare decision logged in 2026 may need to be defensible for a decade or more. A signature scheme that is safe today but breakable by a future quantum machine is a weak foundation for records that must outlast the threat. Choosing a post-quantum scheme now means the proof you generate this year does not quietly expire when the cryptography behind it does. That is why engineers increasingly name ML-DSA as the expected standard rather than a nice-to-have.

What Article 12 does and does not require

Be precise here, because overstatement helps nobody. Article 12 requires high-risk AI systems to automatically record events over their lifetime, to a standard that supports traceability and post-market monitoring. It does not hand you a specific algorithm or a fixed retention period. It sets the outcome, not the recipe. Signing with ML-DSA is how mature operators meet the outcome, not a line item the text spells out.

Keep the timeline honest too. The 2 August 2026 date carries the general-purpose AI enforcement powers and the penalty regime. The standalone high-risk obligations under Annex III have been deferred to 2 December 2027 under the Digital Omnibus. So the fines and GPAI oversight switch on in August 2026, and the full weight of the high-risk duties lands later. The direction is fixed and the engineering lead time is short. Building verifiable logging after the deadline is not a plan.

How does Mickai fit, honestly?

We built our ledger to this exact shape. Every consequential action an agent takes inside Mickai is written to a real-time, append-only ledger and sealed with ML-DSA-65 under FIPS 204. The verification is independent: an auditor checks the records against a public key and confirms the chain without ever trusting our word, our staff or our infrastructure. Because Mickai runs inside your own walls, offline, on hardware you control, the ledger is yours, not a log held on someone else's cloud that you have to request access to. This sits inside a British sovereign platform backed by 104 filed UK patent applications and 2,340 formal claims.

Here is the limit, stated plainly. Mickai supplies the tamper-evident substrate: the signing, the chaining, the independent verification. We do not classify your system for you, and we do not set your retention policy. Whether a given deployment is high-risk under Annex III, and how long you must keep records, remains your legal call with your advisers. We make the proof mathematically sound. You still own the policy that decides what to prove and for how long.

That division is the honest one. A vendor who claims their product makes you compliant is selling you a liability, because compliance is a property of your whole operation, not a feature you buy. What you can buy is a log that an auditor cannot wave away. When someone asks whether your AI agent's record was altered, "trust us" is not an answer that survives 2026. A signature that anyone can verify is.

The practical takeaway

If your audit trail relies on permissions, a database that a privileged user can edit, or a promise that the logs are safe, you do not yet meet the bar the market is settling on. The fix is not more gatekeeping. It is signing each record as it is born, chaining it, and using a post-quantum scheme so the proof lasts as long as the obligation. Mickai gives you that substrate today, sealed with ML-DSA-65, verifiable by anyone, owned by you.

“Proving a log was not altered requires cryptographic signing and hash-chaining, not access controls, which only record who was permitted to touch the log and nothing about what they did.”

Frequently asked questions

When do EU AI Act Article 12 logging rules take effect?

The 2 August 2026 date brings the general-purpose AI enforcement powers and the penalty regime, with fines up to 7 percent of global annual turnover. The standalone high-risk obligations under Annex III, which carry the detailed Article 12 record-keeping duties, have been deferred to 2 December 2027 under the Digital Omnibus. The direction is fixed either way, and the engineering lead time is short.

Are access controls enough to meet tamper-evident logging requirements?

No. Access controls decide who may touch a log, but record nothing provable about what a privileged insider or compromised credential actually did. An auditor cannot take the operator's word that nothing was changed. Cryptographic signing is what turns a promise into a proof.

What does tamper-evident mean, and is it the same as tamper-proof?

No. Tamper-proof would mean data cannot be altered, which is not achievable. Tamper-evident means any alteration is detectable, and detectable by a third party who does not trust you. Signing and hash-chaining each record makes any edit break verification loudly and reproducibly.

Why use ML-DSA (FIPS 204) rather than a conventional signature?

Audit records for regulated AI may need to stay defensible for a decade or more. ML-DSA is a post-quantum signature scheme, so the proof you generate today does not quietly expire when a future quantum computer breaks older cryptography. That is why engineers increasingly treat it as the expected bar.

Does using Mickai make my organisation compliant with Article 12?

No, and we will not claim it does. Mickai supplies the tamper-evident substrate: real-time signing with ML-DSA-65, hash-chaining and independent verification against a public key. Classifying whether your system is high-risk and setting your retention policy remain your legal responsibility. We make the proof sound; you own the policy.

How can an auditor verify the log without trusting the operator?

Verification uses a public key, not a secret the operator holds. The auditor recomputes each record's hash, checks the chain to the previous record, and confirms the signature independently. If a single byte was changed, added, reordered or deleted, verification fails. No trust in the operator's staff or infrastructure is required.