ML-DSA-65 Post-Quantum Signing Explained: Why Your AI Audit Trail Must Survive Harvest-Now-Decrypt-Later
Regulators will not accept an AI audit trail a quantum computer can forge in a decade, and the fix has to be designed in at the evidence layer today, not retrofitted after an enforcement matter.
By Micky Irons, founder and CEO of Mickai
The evidence you sign today has to hold up in 2035
Most of the AI governance conversation is about what a model decides. The harder question, the one auditors and litigators actually care about, is whether you can prove what it decided, when, and on whose authority, years after the fact. That proof is a signature. And most signatures being written into AI systems right now use cryptography that a large fault-tolerant quantum computer will eventually break.
This is the harvest-now-decrypt-later problem. An adversary does not need a quantum computer today to hurt you. They need only to capture your signed records today and wait. When the machine arrives, every signature made with classical elliptic-curve or RSA cryptography becomes forgeable. For a chat log, that is embarrassing. For a regulated audit trail that a court, the FCA, or the PRA relies on as tamper-evident evidence, it is a structural failure. The integrity of the record was never real. It was borrowed against a clock you do not control.
Mickai signs every action in its audit record with ML-DSA-65, a post-quantum digital signature standard. This piece explains what that means, why it belongs at the evidence layer rather than the transport layer, and why the Head of Internal Audit and the General Counsel should be asking about it now rather than in the middle of an enforcement matter.
What ML-DSA-65 actually is
ML-DSA is the Module-Lattice Digital Signature Algorithm, standardised by NIST as FIPS 204 in 2024. It is the productionised form of the CRYSTALS-Dilithium scheme, and it is one of the first signature algorithms selected specifically to resist attack by both classical and quantum computers.
Its security does not rest on the difficulty of factoring large numbers or solving discrete logarithms, the problems Shor's algorithm dismantles on a quantum machine. It rests on the hardness of finding short vectors in structured lattices, a problem for which no efficient quantum attack is known. The 65 denotes the parameter set, NIST security category 3, roughly equivalent to a 192-bit classical security level. It is the sensible middle of the three ML-DSA parameter sets: stronger than the minimum, without the signature-size cost of the highest tier.
The practical trade you accept for that durability is size. ML-DSA-65 public keys and signatures are measured in kilobytes rather than the tens of bytes of an elliptic-curve signature. At the evidence layer that cost is trivial. You are not squeezing these signatures into a TLS handshake on a constrained device. You are writing them once, into a durable record, where the only property that matters over a fifteen-year horizon is that the signature cannot be forged.
Why signing belongs at the evidence layer, not the wire
A common and expensive mistake is to treat post-quantum readiness as a networking upgrade. Teams turn on a quantum-resistant TLS suite, tick the box, and move on. That protects data in transit. It does nothing for the record after it lands.
The audit trail is not a transport problem. It is an evidence problem. Its whole purpose is to be produced, intact and verifiable, long after the session that created it has ended, often to a party who was not present and does not trust you by default. That is exactly the artefact harvest-now-decrypt-later targets, because it is written once and then must survive untouched for years.
So the signature has to bind the content of each action at the moment it happens, inside the system of record, not around the pipe it travelled through. In Mickai, that record is the OAR, the tamper-evident audit record every action is written to. Each entry is signed with ML-DSA-65 at the point of creation, and each entry chains to the one before it, so the sequence itself is evidence. You cannot remove, reorder, or backdate an action without breaking the chain, and you cannot forge a replacement without the private key, which is bound to hardware and never leaves it. That last property, hardware-bound identity, is what stops a signature from being something a compromised process can quietly mint on its own.
What the CRO, the DPO and internal audit should ask
The technology is only half the point. The other half is that a signing choice made now is a governance position you will have to defend later.
Ask three questions of any AI system you run in a regulated function. First: when the model or an agent takes an action, is that action individually signed, or is signing bolted on at the log-aggregation layer where entries can be dropped or reordered before anyone signs anything? Second: is the signature algorithm quantum-resistant and standards-based, or is it the same elliptic-curve default that harvest-now-decrypt-later is built to defeat? Third: where does the signing key live, and can any software process reach it? If the honest answer to the first is no, or to the second is that nobody checked, you do not have an audit trail. You have a log that looks like one until the day it is challenged.
This matters across every regime that treats records as evidence. UK GDPR and a DPIA expect you to demonstrate integrity of processing, not assert it. The EU AI Act's high-risk obligations turn on record-keeping and traceability. DORA and operational-resilience expectations assume your incident and decision records will still be trustworthy when a regulator reads them after the fact. SM&CR pushes accountability to named individuals, which only works if the record of who authorised what cannot be quietly rewritten. In each case the underlying demand is the same: durable, non-repudiable evidence. A signature you know will be forgeable does not meet it.
Designed in, because you cannot retrofit integrity backwards
The uncomfortable truth about the audit trail is that you cannot upgrade the past. Records signed this year with breakable cryptography stay breakable forever. You can start signing correctly tomorrow, but everything already written under the old scheme carries the old risk for its entire retention life. That is why post-quantum signing is an architecture decision, not a patch. It has to be in the substrate from the first record, which is where Mickai put it.
The OAR is one part of a deliberately sovereign design. Mickai is an AI operating system that regulated businesses own and run inside their own walls, on-prem and air-gapped, with fifty specialist brains coordinated by a deterministic arbiter, air-gapped retrieval, compensating rollback for actions that must be unwound, and the post-quantum-signed OAR underneath all of it. It is built and live, and it is being built to scale. The estate behind it now runs to 104 filed UK patent applications and roughly 2,340 claims, held by Mickai LTD, a priority and prior-art position rather than a granted monopoly, but a deliberate one. As a dated third-party signal, in June 2026 Crunchbase ranked me fourth among its tracked founders and placed the company in the top one to two percent globally. I note it once and move on, because the argument here stands on the architecture, not the ranking.
The window
We are opening the current phase to a small number of selected partners in regulated finance, healthcare and the public sector, chosen for fit rather than filled for volume. If your obligations mean the integrity of your AI's record has to survive a decade of scrutiny, and a quantum machine that has not arrived yet, this is a conversation worth having early. Reach me directly at micky@mickai.co.uk.
FAQ
What is ML-DSA-65 in one sentence? It is a NIST-standardised post-quantum digital signature algorithm (FIPS 204, security category 3, derived from CRYSTALS-Dilithium) whose security rests on lattice problems that quantum computers are not known to break, making it suitable for signatures that must remain unforgeable for years.
What does harvest-now-decrypt-later mean for an audit trail? It means an adversary can capture your signed records today and wait for a quantum computer capable of forging classical signatures, at which point the integrity of everything you signed with breakable cryptography retroactively collapses. Records cannot be re-signed backwards, so the exposure is fixed at the moment of writing.
Why is this an evidence-layer concern and not just a TLS upgrade? Quantum-resistant transport protects data in motion; it does nothing for the record once stored. The audit trail must be produced and verified long after the session ends, often to a regulator or court, so the signature has to bind each action inside the system of record, at the point of creation, not around the network path it travelled.
Which regulations make this a live obligation rather than a nice-to-have? Any regime that treats records as evidence: UK GDPR and DPIA integrity duties, the EU AI Act's high-risk record-keeping and traceability rules, DORA and operational-resilience expectations, and SM&CR accountability, all of which assume the decision record will still be trustworthy when it is read back years later.
Does Mickai already sign this way, or is it on a roadmap? It is built and live. Every action written to Mickai's OAR is signed with ML-DSA-65 at the point of creation, chained to the previous entry, with the signing key bound to hardware, so post-quantum integrity is in the substrate from the first record rather than retrofitted.
Frequently asked questions
What is ML-DSA-65 in one sentence?
It is a NIST-standardised post-quantum digital signature algorithm (FIPS 204, security category 3, derived from CRYSTALS-Dilithium) whose security rests on lattice problems that quantum computers are not known to break, making it suitable for signatures that must remain unforgeable for years.
What does harvest-now-decrypt-later mean for an audit trail?
It means an adversary can capture your signed records today and wait for a quantum computer capable of forging classical signatures, at which point the integrity of everything you signed with breakable cryptography retroactively collapses. Records cannot be re-signed backwards, so the exposure is fixed at the moment of writing.
Why is this an evidence-layer concern and not just a TLS upgrade?
Quantum-resistant transport protects data in motion; it does nothing for the record once stored. The audit trail must be produced and verified long after the session ends, often to a regulator or court, so the signature has to bind each action inside the system of record, at the point of creation, not around the network path it travelled.
Which regulations make this a live obligation rather than a nice-to-have?
Any regime that treats records as evidence: UK GDPR and DPIA integrity duties, the EU AI Act's high-risk record-keeping and traceability rules, DORA and operational-resilience expectations, and SM&CR accountability, all of which assume the decision record will still be trustworthy when it is read back years later.
Does Mickai already sign this way, or is it on a roadmap?
It is built and live. Every action written to Mickai's OAR is signed with ML-DSA-65 at the point of creation, chained to the previous entry, with the signing key bound to hardware, so post-quantum integrity is in the substrate from the first record rather than retrofitted.






