Provable Offline: Verifying a Device Stayed Disconnected From a Public Key Alone

On 2 August 2026 the EU AI Act reaches full application, bringing obligations that assume systems can be audited after the fact rather than merely described in advance. The UK Sovereign AI programme, ISO/IEC 42001 adoption, and sustained NHS concern over data sovereignty have shifted the question a serious buyer asks. The old question was whether a vendor promised that data would not leave the building; the new one is whether anyone can prove it did not.

These are not the same question. A promise is backed by trust in the party making it; proof is a property a third party can check without trusting that party at all. When a machine handles classified or clinical data in an air-gapped enclosure, an assurance that it stayed offline is worth little if the only evidence is the operator word.

What offline should mean, and why saying it is not enough

Offline is usually treated as an operational condition: a cable unplugged, a firewall rule, a network the machine was never joined to. All of these are real, and all of them are invisible to anyone standing outside the room a week later. An auditor cannot inspect a state of not-having-happened, and absence of network traffic leaves no artefact unless the machine recorded its connectivity in a form that cannot be forged.

A claim of offline operation is a claim about the entire history of a device, and history is what conventional logging fails to secure. Log files can be edited, timestamps rewritten, and gaps quietly closed. A vendor dashboard reporting that a fleet stayed disconnected simply relocates the trust to the dashboard and its supplier. The reframing that matters is to ask what a device could sign that lets an outsider reconstruct its connectivity history. If the device holds a private key it never reveals, and every relevant event is bound into a chain that key seals, the public key becomes the anchor for verification.

Identity rooted in silicon, not a certificate a vendor issued

Verification from a public key is only as strong as the link between that key and the physical machine. A software-generated keypair proves that some process signed something; it does not prove which device did, or that the key was not copied to a second machine that quietly held a modem. Hardware-attested identity closes that gap by generating the private key inside a secure element, where it never leaves. The silicon then produces a signed statement that the public key was generated inside a genuine hardware root, and a verifier checks that statement against the manufacturer roots, which sit outside our control. This removes both the operator and us from the trust path.

Within a Sovereign Intelligence Operating System, this hardware-rooted identity is the foundation everything else is measured against. Mickai runs offline on operator-owned hardware, and the identity that seals its records is bound to that hardware, not to any account or cloud tenancy. Several of the mechanisms described here sit within the 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; never granted or patented.

Sealing the history: post-quantum signed audit chains

A signed audit chain is a sequence in which each entry records an event, references the cryptographic hash of the entry before it, and is signed by the device key. Any attempt to alter, remove or reorder an entry breaks the chain at that point and every point after it, because the hashes no longer reconcile. For a device asserting it stayed offline, the entries that matter are boot events, the state of every network interface, any peripheral capable of communication, and each attempt by a process to open an outbound socket. A disconnected device produces a chain showing interfaces held down and no egress succeeding, sealed across the whole period. A device that touched the network cannot conceal it, because that requires editing sealed history, which rejects edits by construction.

“Offline stops being a promise the moment a device can hand a stranger the sealed record of its own connectivity and let that stranger check it against a public key alone.”

Post-quantum signature schemes are used for this sealing deliberately. Audit records outlive the systems that produce them, so a chain that is sound today must remain sound against an adversary with a quantum computer a decade from now. Lattice-based schemes standardised for this purpose mean the evidence does not expire as cryptography advances.

The inbound perimeter: refusing to let anything reach out

Signed history tells you what happened; architecture determines what can happen. A zero-egress inbound perimeter accepts data brought to it but originates no outbound connection of its own. Requests arrive, nothing is dialled out, and there is no channel by which processed data, model weights or telemetry can leave.

This inverts the assumption behind most connected software, which reaches out constantly to fetch updates and call services. A zero-egress design has no such reflexes, and its audit chain reflects that absence directly. For a regulator assessing whether patient data or classified material could have escaped, this is a categorical rather than a probabilistic answer, because the question is no longer how likely a leak was but whether the architecture contains a mechanism for one at all.

Cross-model consensus, and why offline does not mean unaccountable

A reasonable objection to disconnected operation is that it removes the oversight a connected system enjoys: if a machine answers to no external service, what stops a single model inside it from producing an unchecked result? Accountability can be internalised rather than outsourced. Cross-model consensus runs a decision past several independent sovereign models and treats agreement, or its absence, as a signal. When models trained and prompted differently converge, confidence is warranted; when they diverge, the disagreement is sealed into the audit chain rather than smoothed over. This is an internal check that requires no outbound call. Governance of agentic behaviour, much discussed in 2026 around ISO/IEC 42001, depends not on connectivity but on whether the system records its reasoning in a form that survives scrutiny.

What the verifier actually does

The third party task is deliberately simple. The verifier obtains the device public key and the attestation binding it to genuine hardware, checks that attestation against the silicon manufacturer roots, then walks the sealed audit chain, confirming each hash matches, each signature verifies under the public key, and the connectivity events show the interfaces down and no egress across the period claimed.

At no point does the verifier contact us, trust a dashboard, or take the operator word for anything. If the maths holds, the device stayed disconnected; if it does not, the claim fails visibly, pointing at the exact entry where history was disturbed. That falsifiability is what separates evidence from assurance.

Where this is heading

The direction of travel through 2026 and beyond is towards procurement and regulation that ask for proof rather than paperwork. As the EU AI Act moves into full application and sovereign-AI expectations harden across the UK public sector and healthcare, the operators who clear these bars are those who can hand an auditor a device and a public key and invite them to check for themselves. We build a Sovereign Intelligence Operating System on the assumption that this shift is permanent: running offline on operator-owned hardware, with hardware-attested identity and post-quantum signed audit chains, is the precondition for a verifiable claim rather than a limitation to apologise for.