What Hardware-Attested Identity Means for an AI Audit Trail

Hardware-attested identity means every entry in an AI audit trail carries cryptographic proof of three things at once: the exact machine that ran the action, the exact software build of the model, and the named operator who authorised it. It works because a hardware security element, a Trusted Platform Module or a secure enclave, signs a measurement of the boot state and the running code, and binds that measurement into each ledger line rather than a separate boot log. The result is that a single log line stops being a claim that something happened and becomes evidence of which device, build and person produced it.

This matters in 2026 because regulated buyers are being asked to prove not just what an AI system decided, but who and what stood behind each decision. The EU AI Act, DORA and NIS2 all push accountability down to specific actors and specific systems. Most guidance treats attestation and audit logging as separate topics; the value is in the join between them.

How does hardware-attested identity actually work?

Three components are measured and signed at the moment an action is recorded.

• The machine: a TPM or secure enclave produces a signed quote of the device identity and its boot measurements, so the hardware cannot be silently swapped.
• The model build: the running model and its configuration are hashed, so the record proves the approved build ran and not an altered one.
• The operator: the human is bound through a hardware-held credential, so the entry names a person, not a shared service account.

These three values are written into the audit entry itself, under one signature. Change the machine, the build or the operator and the signature no longer verifies.

What is the missing link most designs leave out?

Generic guidance treats attestation as a boot-time event and the audit trail as a separate concern. A device attests once at startup, then hours of AI actions are logged with no cryptographic tie back to that attestation. If the log and the boot record live in different systems, an auditor cannot prove the two belong together.

The missing link is binding. Each ledger entry must embed the attestation and the operator identity, and the whole entry must be signed as one unit. Then every line is self-proving: it does not depend on trusting a separate log to remain intact.

“An audit trail that cannot say which machine and which named person produced a line is a record of events, not a record of accountability.”

What can an auditor actually check?

A well-formed attested entry lets an auditor verify a short list without trusting the operator's word.

• That the signing hardware is the specific device it claims to be.
• That the model build hash matches an approved, catalogued build.
• That the named operator credential was present and valid at that moment.
• That the entry has not been altered since it was written, because the post-quantum signature still verifies.
• That the entry sits in an unbroken chain, so no line was removed or reordered.

The test is simple: take a line, verify its signature offline, and read off the device, build and person. If that works offline, the trail is portable evidence.

Which rules make this necessary?

Several 2026 duties point the same way, towards traceability to a specific system and a specific actor. Under the EU AI Act, the high-risk obligations in Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with high-risk systems embedded 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. Record-keeping and human oversight still assume logs that tie an output to the system and the responsible people.

DORA, in force across EU financial entities since January 2025, requires an audit trail robust enough to reconstruct events. NIS2 and GDPR push accountability towards identifiable actors and defensible records, and ISO/IEC 42001 asks for evidence that an AI management system operated as described. None of these is satisfied by hardware alone, but attested identity supports each duty by making the record harder to forge and easier to reconstruct.

How does this differ from a cloud audit log?

A public cloud AI service writes its audit logs inside the provider's own environment, so the customer receives a log the provider generated and controls. That can create exposure for regulated buyers: the record depends on the provider's integrity, and depending on where the provider is domiciled, that record can be reached by legal process in another jurisdiction, outside the customer's control. A contractual promise about log handling is not the same as a technical guarantee.

A Sovereign Intelligence Operating System inverts this. Mickai is a SIOS that runs offline on operator-owned hardware behind a zero-egress inbound perimeter, so no action leaves the machine to be logged elsewhere. Every action is sealed locally into a post-quantum signed ledger using ML-DSA, the signature standard defined in FIPS 204, with hardware-attested identity bound into that chain and cross-model consensus recording which sovereign models agreed on an output. The binding methods sit within 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; never granted or patented. The evidence is offline-verifiable, checkable without asking us for access.

What does attested identity not prove?

Attestation proves provenance, not correctness. It shows which device, build and person produced an output, not whether that output was right, and it confirms only that an operator credential was present, not the person's intent. Treat it as the accountability layer beneath model quality controls, not a replacement for them. This is where a compliance claim should stop: the architecture supports a duty of traceability and reduces the risk of a disputed record, but certifies nothing on its own.

Frequently asked questions

Is a TPM enough to trust an AI audit trail on its own?

No. A TPM or secure enclave proves the device and its boot state, but says nothing on its own about which model build ran or which person acted. Trust comes from binding the attestation, the build hash and the operator credential into each signed ledger entry. The hardware is one input of three, not the whole answer.

Can hardware-attested identity work if the system is fully offline?

Yes, and offline is where it is strongest. The signatures are generated and verified locally, so no network or provider is needed to prove a line. An auditor can verify a single entry on a disconnected machine and read its device, build and operator.

Does hardware-attested identity make our AI logs compliant with the EU AI Act?

No architecture makes logs compliant by itself, and any vendor claiming otherwise is overstating. Attested identity supports the record-keeping and traceability duties by making each entry harder to forge and easier to reconstruct. Compliance still depends on governance, model controls and how the system is operated.

What happens to the audit trail if quantum computers can break today's signatures?

This is why the ledger is signed with a post-quantum algorithm, ML-DSA, standardised as FIPS 204. A record signed with a classical algorithm could be forged once a large quantum computer exists, undermining years of past evidence. Signing now with a post-quantum standard is designed to keep old entries verifiable in that future.

How is this different from signing logs with a normal digital certificate?

A normal certificate proves a key signed a log, but not that a specific, unaltered machine and a named person produced it. Hardware-attested identity ties the signature to a measured device state and a hardware-held operator credential, so the proof covers the whole context, not just possession of a key. It also chains entries so lines cannot be quietly removed.