Why should an AI audit trail be sealed with post-quantum signatures?

An AI audit trail should be sealed with post-quantum signatures because the records must stay provable for longer than today's cryptography will survive. A digital signature lets a third party confirm, years later, that a log entry was not altered and that a specific system produced it. Classical signatures such as RSA and ECDSA are expected to fall to a cryptographically relevant quantum computer, and at that point every seal they ever produced becomes forgeable. Sealing with the post-quantum standard FIPS 204 keeps the audit trail unforgeable and verifiable across its full retention life.

This matters now because regulated buyers are being asked to prove, not merely assert, what their AI systems did. Audit obligations under DORA, NIS2 and GDPR run for years, and automated decision records are often kept for a decade or more. An adversary can copy a signed log today and wait: that is the harvest now, decrypt later strategy, and it turns a record sealed in 2026 into one anyone can forge once the underlying mathematics breaks.

What does sealing an audit trail actually mean?

Sealing is not the same as logging. A log records events. A hash chain links each entry to the one before it, so any later edit breaks the chain and is detectable. A signature binds that chain to a cryptographic key held by a specific system, so an outside auditor can confirm it is authentic without trusting the operator.

Ledger claims often stop at the hash chain. That proves the entries are internally consistent, but not who sealed them, and it does not stop a determined party reissuing the whole chain. The signature is what makes an audit trail evidence rather than an assertion, so weakening it weakens every integrity claim downstream.

Why will today's signatures not outlive the records?

The problem is a mismatch of timelines. RSA and ECDSA rest on mathematical problems a large quantum computer is expected to solve. A signature relied on for twenty years does not need that machine to exist today: it needs the machine to never exist across the whole window, which is not a bet a regulated operator should make.

“A record is only as trustworthy as the signature that will still verify on the day someone finally needs to check it.”

Once a classical scheme is broken, the damage is retroactive. An attacker who recovers the key can forge a signature dated to any past point, so an auditor cannot tell a genuine 2026 entry from a fabricated one. Post-quantum signatures close that door before it opens, so the sealing decision belongs at the point of writing, not migration.

Which standard does the sealing, and why FIPS 204?

NIST published the first post-quantum signature standards in 2024. FIPS 204 specifies ML-DSA, a lattice-based signature scheme, and is the primary standard for signing and verifying records. FIPS 205 specifies SLH-DSA, a hash-based scheme, held in reserve as a conservative alternative built on different assumptions.

A separate standard, FIPS 203, specifies ML-KEM for key encapsulation. It protects keys in transit and never signs anything, so it plays no part in sealing or verifying a ledger. Sealing comes from FIPS 204, or FIPS 204 and FIPS 205 together where two independent assumptions are wanted. Any claim that a ledger is sealed by FIPS 203 is a category error worth checking in vendor documentation.

What can an auditor check without trusting us?

The point of a sealed trail is that verification does not require good faith. Given the public verification key, an auditor can confirm several things offline, with no live connection to the system that produced the records:

• Each entry carries a valid FIPS 204 signature over its content and chain position.
• The chain is unbroken, so no entry has been inserted, removed or reordered.
• The signing identity is bound to attested hardware, naming the machine that acted.
• The same verification succeeds today and after any quantum transition, because the signature is already post-quantum.

Offline verifiability is the test. If a ledger can only be checked by asking the vendor's live service, the vendor remains a trusted party, not an independent check.

Which rules make this necessary?

No single regulation says the words post-quantum signature, but the direction of several does. DORA has applied to financial entities since January 2025 and demands demonstrable operational resilience and evidence trails. NIS2 extends comparable duties across critical sectors, and GDPR requires automated-decision records to stay defensible while they carry legal effect.

The EU AI Act's high-risk obligations under Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded high-risk systems under Annex I moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve. ISO/IEC 42001 sets the same expectation for AI management systems: keep records a certifier can inspect. The US CLOUD Act is why the seal's location matters: records held by a public cloud AI service can be compelled from the provider wherever the customer sits.

How does a sovereign system seal the ledger in practice?

Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs offline on operator-owned hardware, so the audit trail is never subject to a foreign disclosure order the way a hosted service is. Regulated buyers who cannot route evidence through hosted public cloud AI services need the seal produced and held inside their own perimeter.

Every action is cryptographically sealed as it happens, and hardware-attested identity binds each entry to the machine that produced it. A zero-egress perimeter means data enters for processing and nothing leaves, so the ledger records a closed system. The ledger is signed with post-quantum signatures, and cross-model consensus records which sovereign models agreed and where they diverged. Verification runs offline against the public key alone. This work sits within a portfolio of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD. These filings are patent pending and never granted or patented. The mechanisms matter more than the count: a record a stranger can verify years from now, without trusting us, is the objective.

Frequently asked questions

Does a blockchain or immutable ledger already solve this?

Not on its own. A hash chain proves the entries are internally consistent, but the ledger's authenticity still rests on the signatures that anchor it. If those use classical cryptography, a future quantum attacker can forge them and reissue the chain. The ledger and the post-quantum signature are complementary, and the signature is the part that survives.

Is FIPS 203 used to sign an AI audit trail?

No. FIPS 203 specifies ML-KEM, which is key encapsulation for protecting keys in transit, and it never produces a signature. Signing and verifying an audit trail is the job of FIPS 204, which specifies ML-DSA, optionally alongside FIPS 205. A vendor that credits FIPS 203 with sealing or verifiability has described the wrong standard.

When do we need to migrate to post-quantum signatures?

For records with long retention, the answer is before they are written, not after quantum computers arrive. Any log signed with classical cryptography today can be captured now and forged later, so the exposure begins at signing. Sealing new records with FIPS 204 from the outset avoids a retroactive re-signing exercise that may not be possible.

What is harvest now, decrypt later?

It is the strategy of copying encrypted or signed data today and storing it until the cryptography that protects it can be broken. For audit trails the concern is signatures rather than secrecy: an attacker who later recovers a classical signing key can forge entries dated to the past. Post-quantum signatures defeat it because the seal does not rely on mathematics quantum computers are expected to break.