How do you know an offline AI model has not been tampered with or swapped?

You know an offline AI model has not been swapped or tampered with because its weights are cryptographically signed, the machine proves which exact file it loaded through a hardware attestation, and that load event is written into the same signed, append-only ledger that records every other action. If the running weights do not match the signed hash on record, the load fails or the mismatch is visible in the ledger. Because that ledger is sealed and append-only, a swapped or poisoned build cannot be hidden after the fact: it is detectable and provable.

This matters because the 2026 threat is no longer only an external breach. It is the quiet insider swap and the compromised supply chain: a model file changed between download and deployment, a fine-tune poisoned upstream, or a build substituted on an unwatched machine. Regulated buyers in finance, defence and healthcare must prove, not assert, that the model answering a question is the one they approved. A system that cannot show its own provenance is now a liability.

How does offline model integrity actually work?

The chain has three links. Break any one and the guarantee is gone.

• Signed weights. Every model file is hashed and signed before it is allowed on the machine. The signature covers the exact bytes of the weights, the tokeniser and the configuration, so a single changed parameter produces a different hash and an invalid signature.
• A hardware-attested load event. When the model loads, the hardware root of trust measures what was actually loaded and attests to it. The identity of the machine and the identity of the loaded model are bound together, so the system can prove which weights ran, on which node, at which moment.
• A sealed ledger entry. That attested load is written into an append-only audit ledger, signed with post-quantum signatures. The same ledger records every inference and every action, so the model load sits in the same tamper-evident record as everything the model then did.

“Integrity you cannot verify is only a promise, and a promise is not a control.”

What can an auditor check after the fact?

An auditor need not trust an operator's word; they check four things independently.

• The hash of the deployed weights against the signed hash on record.
• The attestation the hardware produced when the model loaded.
• The ledger entry that recorded that load, and whether the ledger's signature chain is intact.
• Whether any inference in the period was served by a model whose hash does not appear in the approved set.

If a model was swapped, one of these checks breaks. A different hash, a missing attestation, or a gap in the ledger points to the same conclusion. This is verification, not assurance.

What stops an insider from swapping the model quietly?

The insider is the hard case, because the insider has access. Three design choices remove the quiet path. First, the system runs offline behind a zero-egress inbound perimeter, so there is no silent channel to pull an unsigned model in or push data out. Second, identity is hardware-attested, not password-based, so a person or process acting on the machine is bound to a recorded, hardware-rooted identity and a swap is not anonymous. Third, the ledger is append-only, so an insider can attempt a swap but cannot erase the evidence. The record of the unsigned load survives, turning a hidden act into a caught one.

Why do the signatures have to be post-quantum?

A signed ledger is only as durable as its signatures, and a record trivial to forge in ten years is not evidence when audit and legal timelines are long. We sign the audit chain with post-quantum algorithms standardised as FIPS 204 and FIPS 205, so a signature made today still holds when a future adversary has more capable hardware. Integrity that must survive a decade of scrutiny cannot rest on cryptography a decade may break.

Which rules make this necessary?

Several regimes now expect provable model provenance rather than stated policy.

• DORA has been in force across EU financial entities since January 2025, and it expects operational resilience and traceability of the systems that make decisions.
• NIS2 raises the bar on supply-chain security for essential and important entities, which includes the integrity of the software and models they run.
• GDPR requires that automated decisions can be accounted for, which is hard without a record of which model produced them.
• ISO/IEC 42001 sets out AI management-system controls that assume you can evidence what your models are and how they change.
• 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 Annex I high-risk moved to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve.

How is this different from a public cloud AI service?

A regulated buyer cannot point a hardware attestation at a third-party cloud model. The weights sit on someone else's infrastructure, the load event is not theirs to measure, and the audit record is not theirs to hold or seal. Under the US CLOUD Act, data held by a US provider can also be reachable by legal process regardless of where it is stored. This is not a criticism of those services, but an architectural fact: verifiable integrity of this kind requires weights, hardware and ledger under the operator's own control. In Mickai, our Sovereign Intelligence Operating System, those three sit inside one offline boundary on operator-owned hardware. The mechanisms described here are the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, and are filed applications, never granted or patented.

Frequently asked questions

How can you prove which AI model actually answered a question?

Every inference is written into an append-only, post-quantum signed ledger alongside the attested identity of the model that served it. Because each model load carries a hardware attestation and a signed weight hash, you can trace any answer back to the exact model file that produced it. If no approved model matches the recorded hash, the answer is flagged.

Can an offline AI model be poisoned during fine-tuning?

Yes, if poisoning happens before signing, a signature only proves the file is the approved file, not that the approved file is safe. That is why signing is paired with evaluation gates before approval, and with cross-model consensus at run time, where divergent outputs flag behaviour worth investigating. Signing catches a swap. Behavioural checks catch a poison introduced upstream.

What is a hardware attestation for an AI model?

A hardware attestation is a measurement, produced by a hardware root of trust, of exactly what was loaded onto a machine. For a model it binds the loaded weights to the physical node, so the system can later prove which file ran where. It is what turns "we think this is the right model" into "the hardware recorded that this was the model".

Does an air-gapped model still need a signed audit ledger?

Yes. Air-gapping stops a remote attacker, but it does nothing to prove which model loaded or to catch an insider with physical access. A signed, append-only ledger records the load event and every action after it, so the record of a swap survives even on a disconnected machine. Isolation and verifiability solve different problems.

Is a checksum enough to detect a tampered model?

A checksum tells you the bytes changed, but on its own it is not evidence: whoever can swap the model can often swap the stored checksum too. Integrity holds when the hash is cryptographically signed, the load is hardware-attested, and both are written into a sealed ledger an insider cannot rewrite. The signature and the ledger are what make the check trustworthy.