How To Verify What Your AI Actually Did, Offline

You audit an AI agent by making every consequential action write one entry into an append-only, hash-chained record, then verifying that record offline with the operator public key alone. In Mickai, that record is the Open Audit Record. Each entry carries an index, a timestamp, the actor, a typed action, the target and a SHA-256 hash of its payload, and each entry commits to the hash of the entry before it, with the chain signed using FIPS 204 ML-DSA. Alter one field anywhere in that history and the hashes stop lining up and the signature stops verifying, which is what makes interference detectable rather than deniable.

• Every consequential action writes one entry: index, timestamp, actor, typed action, target, and a SHA-256 of the payload.
• Each entry commits to the hash of the entry before it, so the log is a chain, not a pile of independent rows.
• The chain is signed with FIPS 204 ML-DSA, the post-quantum signature standard. FIPS 203 ML-KEM is key encapsulation and never signs.
• Verification needs the record and the operator public key. No network, no vendor, no licence check.
• The record is tamper-evident, which means interference is detectable rather than quiet.
• Deterministic engines produce every number, so identical inputs give identical results and a re-run can be compared against the record.

What does a single audit entry actually record?

An entry is a small, fixed record of one act. It carries an index that pins its position in the sequence, a timestamp, the actor who performed the act, the typed action, and the target it was applied to. It carries a SHA-256 hash of the payload, so the entry commits to the full content without restating it.

Typed matters. The action is not free text a reviewer has to interpret, it is one of a defined set, so activity can be filtered, counted and compared without reading prose. The target is named, so an approval never floats on its own. Read the record and you have who did what, to which thing, in which order.

How does hash-chaining stop someone editing the past?

Each entry commits to the hash of the entry before it. Entry ten contains the hash of entry nine, nine contains the hash of eight, back to the first. That makes the log one continuous chain rather than a table of independent rows.

Change one character in entry nine (a different approver, a smaller amount, an earlier time) and its hash changes. Entry ten still holds the old hash, so the link breaks at exactly that point. Hiding the edit means recomputing every entry from nine to the head, and the break moves to wherever you stopped. Integrity stops being a claim about a locked database and becomes arithmetic anyone can repeat.

Why sign the chain when the hashes already link?

Hashes prove internal consistency. They do not prove who produced the chain, and an editor with write access could rebuild the whole chain so that it is internally perfect again. The signature closes that gap.

The chain is signed with FIPS 204 ML-DSA, the post-quantum signature standard. The private key belongs to the organisation running the deployment, not to us, because identity here is issued rather than federated: each organisation holds its own signing key and its own ledger. A rebuilt chain cannot be re-signed without that key, so a forged history fails verification while the key stays in trusted hands.

The two are routinely swapped, so one clarification. FIPS 203 ML-KEM is key encapsulation, used to establish keys. It never signs anything.

What do you need to verify the record offline?

Two things: the record, and the operator public key. A verifier walks the chain, recomputes each hash, checks that every stored predecessor hash matches, and checks the signature against the public key. Every step is local arithmetic on bytes you already hold.

None of it needs us, a licence server, or a connection. Mickai runs on hardware the customer owns, over loopback only, with no outbound path by default, so verification has to survive with the network unplugged. Hand an auditor the record and the public key, and they reach their own conclusion cold.

How strong is the guarantee on an AI audit log?

Strong enough to make interference visible, and honest about stopping there. Someone with sufficient access to the machine can delete a file, truncate the chain at yesterday, or stop entries being written. No cryptography prevents that, and a stronger claim would be marketing rather than engineering. The property also rests on key custody, since anyone holding the operator signing key could rewrite a history and re-sign it.

What the design does remove is quiet alteration. An edited entry breaks the hash link and the signature, and that break is arithmetic rather than opinion. Where signed checkpoints are written off the box and anti-rollback is in force, a shortened chain no longer matches the last checkpoint held elsewhere, so rolling the history backwards shows up as a mismatch rather than a silence. That comparison is only as good as the checkpoint practice behind it.

Tamper-evident is the accurate word. Interference becomes an event someone can see, provided the signing key stays protected and the checkpoints live where the machine cannot reach them.

Frequently asked questions

Can I verify the log myself, without involving Mickai?

Yes. Verification takes the record and the operator public key, and nothing else. The check is a walk down the chain recomputing SHA-256 hashes, followed by one signature verification against that public key. It runs offline, on a machine of your choosing, with no call to us.

What if someone simply deletes the last month of entries?

Where signed checkpoints are written off the box, the deletion shows. The remaining chain no longer matches the last checkpoint held elsewhere, so a verifier comparing the two sees a history that has moved backwards. The evidence is the mismatch, not the missing rows. Keeping those checkpoints out of reach of whoever administers the machine is what makes the comparison worth anything.

Does the record capture human approvals, or only machine actions?

Both. Consequential actions are staged for a person to approve or refuse, and that approval or refusal is itself an entry, with its own actor, timestamp and payload hash. For a reviewer the second half is usually the point: not only what was done, but who allowed it, and when.

Why use a post-quantum signature scheme today?

Because audit records are read years after they are written. A record signed now may need to hold up in a dispute long after today's assumptions about signature strength have been tested by better hardware. FIPS 204 ML-DSA is the signature standard built for that horizon, so we sign with it now rather than migrate a long history later.

How can I see this running on my own hardware?

Mickai is in closed beta at mickai.co.uk/beta. Access is selective and not every applicant is accepted, because each deployment runs on hardware the organisation owns and is set up with its own signing key and ledger. If auditability is the reason you are looking, say so in the application.