What an Auditor Can Independently Check in a Cryptographically Sealed AI Trail

From a cryptographically sealed AI trail, an external auditor can independently verify four things without trusting the operator: that the chain is unbroken, that each recorded action was signed by an attested device and a named operator, that nothing was inserted or removed, and that no entry could have been altered after it was written. Each is settled by recomputing hashes and checking signatures against public keys, so the record holds because the mathematics holds, not because the vendor says so.

This matters in the 2026 market because assurance is no longer enough; regulated buyers in finance, health, defence and critical infrastructure are told to show, not tell. DORA has applied since January 2025, NIS2 raises the bar for operational resilience, and the EU AI Act sets logging and traceability duties for high-risk systems. Auditors now arrive expecting to check the evidence themselves, and a trail only the operator can interpret is one they must take on faith.

What exactly can an auditor check without trusting the operator?

Four independent properties, each provable from the record alone. First, integrity of sequence: every entry carries the hash of the one before it, so recomputing the chain fails at the exact point any byte was changed. Second, authenticity of origin: each action carries a signature that verifies against a public key, confirming who and what produced it. Third, completeness: monotonic counters and linked hashes mean a deleted entry leaves a gap the maths exposes. Fourth, immutability in time: a sealed, timestamped entry cannot be back-dated or rewritten without breaking every signature after it. The auditor runs each check with public keys and open algorithms, needing nothing from the operator beyond a copy of the ledger.

How does the sealing actually work?

In our SIOS, every action is written as an entry in an append-only ledger. Each entry contains the payload, a timestamp, the identity of the acting device and operator, and the cryptographic hash of the previous entry. That last field makes it a chain: change an entry and its hash changes, breaking every downstream link.

Each entry is then signed. Our SIOS uses post-quantum signature schemes standardised as FIPS 204, so the signatures stay verifiable and hard to forge even against a future quantum adversary. Anyone with the public key can confirm a signature is genuine, but only the sealed private key inside the attested device could have produced it. The auditor checks but cannot forge.

How can an auditor be sure who signed each action?

Because identity is bound to hardware, not to a login. The signing key lives inside a hardware security element on the operator-owned machine, and the device attests its own state before it is trusted to sign, with that attestation recorded in the same chain. So each entry does not merely say an action happened; it proves that a specific attested device, operating under a named human operator, produced it. That is the difference between a log and a proof: a log records a claimed username, a hardware-attested chain a signature only one physical device could make, tied to a named person.

“A sealed trail replaces the auditor's question of whether to believe the operator with a calculation whose answer the operator cannot influence.”

Which rules make this necessary?

Several converging obligations bear on this. DORA requires financial entities to maintain traceable, resilient records of their information systems and has applied since January 2025. NIS2 extends security and accountability duties across essential and important sectors. GDPR demands demonstrable accountability for automated processing, ISO/IEC 42001 sets out auditable AI management, and the EU AI Act imposes logging duties on high-risk systems.

On timing, read the current position carefully. The high-risk Annex III obligations, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve: the systems that can prove their trail to an auditor in 2027 are the ones architected now.

Why can this only be trusted if it runs offline on owned hardware?

Because a trail is only independent evidence if the operator cannot quietly rewrite it and the vendor cannot reach in from outside. Our SIOS runs offline on operator-owned hardware behind a zero-egress inbound perimeter, so nothing leaves the machine and no external party holds a key to the record. When public cloud AI services process your data, that data sits under a provider's control and, for providers based outside your jurisdiction, potentially within reach of overseas disclosure law. An auditor cannot treat a record as tamper-evident if the audited party or a third party can alter it at source. Sealing on owned hardware closes that gap, keeping the machine, the attested keys and the verifiable output with the audited operator.

What does the verification test look like in practice?

A named, repeatable procedure the auditor runs themselves. Take the ledger, recompute the hash of entry one, confirm entry two references it, then walk the whole chain; any mismatch localises the tampering to a single entry. For each entry, verify the FIPS 204 signature against the device public key and confirm the attestation at that point, then check that the sequence has no gaps and timestamps increase in the sealed order.

For high-stakes decisions, our SIOS also seals a signed cross-model consensus record, so the auditor can see that independent sovereign models agreed before an action was taken. The architecture reflects a body of 104 filed UK patent applications with approximately 2,340 claims, owned by Mickai LTD, and it is patent pending. The auditor does not need to take that on trust either: every claim above is a check they can run for themselves.

Frequently asked questions

Can an auditor detect if a single log entry was deleted from a sealed AI trail?

Yes. Each entry carries the hash of the previous one and a monotonic sequence number, so removing an entry breaks the hash link and leaves a gap in the count. Recomputing the chain fails at the exact point of the deletion, showing the auditor not only that something was removed but where.

Do you have to trust the vendor to verify a cryptographically sealed audit trail?

No, and that is the point. Verification uses public keys and open, standardised algorithms such as FIPS 204, so anyone holding the public verification keys and a copy of the ledger can confirm integrity, authenticity and completeness independently. Neither the operator nor the vendor can influence the result of the calculation.

How does hardware attestation prove which operator performed an AI action?

The signing key is held in a hardware security element on the operator-owned device, which attests its own state before signing. Each entry records a signature that only that physical device could produce, bound to a named operator, with the attestation written into the same chain. An auditor confirms both from the record alone.

Why can public cloud AI services not offer the same auditor guarantees?

Because the data and the record sit under a provider's control rather than yours. When a third party can process, store or reach the record, an auditor cannot treat it as tamper-evident at source, and providers based outside your jurisdiction may fall within reach of overseas disclosure law. A trail sealed offline on owned hardware keeps the evidence and keys with the audited operator.

Is the EU AI Act high-risk deadline still 2 August 2026?

No. The high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and Article 50 transparency duties largely unchanged. We treat this as a build window rather than a reprieve.