DEV Community

Micky Irons
Micky Irons

Posted on • Originally published at mickai.co.uk

AI That Runs With the Cable Pulled

Across 2025 and into 2026, sovereign AI moved from conference panels into procurement documents. UK and European government and defence buyers began writing data-residency, model-integrity and supply-chain conditions directly into their requirements, and they started asking a harder question than where the data sits. They began asking whether the supplier can show, rather than state, that a given workload ran in isolation.

That shift matters because the dominant pattern, AI delivered from someone else's cloud, cannot answer it. A customer renting inference from a hyperscaler is given a contractual assurance and a compliance certificate. The customer cannot inspect the isolation boundary, cannot watch the network counters, and cannot replay what the machine did while it held their classified or regulated data. For a defence ministry, a nuclear engineering programme, or an operator of critical national infrastructure, an assurance is not the same thing as evidence.

The honest position for the most sensitive work is older than the cloud. Pull the cable. Run the model on a machine with no path to a network, in a room you control. The difficulty has never been the disconnection itself. The difficulty is proving, afterwards and to a third party, that the gap was real, that it held for the whole window, and that nothing crossed it. An air gap you merely assert is a policy. An air gap you can replay is evidence.

Mickai is a Sovereign Intelligence Operating System, a SIOS designed to run on operator-controlled silicon rather than rented infrastructure. Two of its subsystems address the air gap directly, and both rest on filed UK patent applications in the wider portfolio of fifty-seven filed UK applications, named inventor Micky Irons, recorded on the UK IPO register from GB2607309.8 onward. The first establishes the gap at the point of deployment. The second proves the gap holds for as long as it is meant to.

Bootstrapping a trust root with the cable already pulled

The first subsystem addresses a specific and awkward problem. How do you stand up a verifiable trust root on a machine that will never see a network, in a place a network cannot reach? A submarine on patrol, a forward operating base, an Antarctic research station, a classified ministerial facility. There is no certificate authority to call and no clock to sync against.

The filed application GB2611900.8, Sovereign Air-Gap Workstation Bootstrap, describes pre-loading a structured set of audit anchors into operator-personalised silicon before the machine leaves the building. The description names four: a trusted-timestamp seed, a public-key pin set, a model-fingerprint registry, and a software-bill-of-materials hash chain. These are written in under a pre-deployment signing ceremony, so the machine carries its proof of provenance inside the hardware before it is ever sealed and shipped.

At first power-on in the field, the workstation performs mutual attestation with the operator through a voiceprint challenge and a one-shot fuse-burn. From that moment it runs offline for months, accumulating a locally signed audit chain anchored to the pre-loaded seeds. The model-fingerprint registry matters here against supply-chain anxiety. The machine can confirm that the model it is running is the one that was signed at the ceremony, not a substituted or tampered set of weights, without phoning home to check.

The closing claim is the one a procurement officer cares about. On later reconnection, the accumulated chain replays end-to-end against the issuing authority. The months of disconnected operation are not a gap in the record. They are a signed, ordered, verifiable chain that an auditor can walk from the first power-on to the moment the cable went back in.

Proving the gap held, tick by tick

A trust root established at boot answers one question. It does not, on its own, answer the question that haunts the whole air-gap idea: did the gap actually stay sealed the entire time, or did something cross it for thirty seconds in week six?

The filed application GB2611902.4, Continuous Air-Gap Attestation Token, addresses exactly that. A continuous attestation engine wakes on each tick of a configurable cadence and does the same disciplined work every time. It reads the hardware ingress and egress counter deltas across every communications interface the machine has, and the description is explicit about the list: Ethernet, Wi-Fi, Bluetooth, USB, Thunderbolt, PCIe. It hashes the active process set. It reads a hardware time-of-attestation value.

From those readings it constructs a signed attestation token, chained to the token before it, and signs it under FIPS 204 ML-DSA-65 in the operator-personalised silicon. The choice of a post-quantum signature primitive is deliberate. A token that must remain verifiable for the lifetime of a classified record cannot rest on a signature scheme expected to fall to a future machine.

A regulator given the export, the operator public key, and the silicon identity can replay the chain and prove with cryptographic certainty that the device ingested, emitted, or transferred no traffic across any defined boundary during any specified subwindow.

That sentence is the whole argument. The proof is not a quarterly self-attestation. It is a hardware-emitted chain fine enough to interrogate any slice of the window after the fact. The same application names its intended ground beyond defence: nuclear engineering, Chinese-wall separation in regulated finance, and anti-money-laundering controls, settings where the cost of an unproven boundary is measured in sanctions or worse.

Why a record nobody can quietly edit

Both subsystems write into an audit substrate rather than a private log. The Open Audit Record, the OAR, is Mickai's hash-linked, signed record format, and an attestation chain is only as trustworthy as the ledger it lands in. A log the operator can silently rewrite proves nothing. A chained, signed record where every entry binds to the one before it cannot be quietly edited after the fact without breaking the chain, which is what lets an outside party trust the export at all.

This is the structural difference from cloud AI, and it is worth stating plainly. In the rented model, the provider holds the logs, the keys, and the boundary, and the customer holds a promise. In the model these two applications describe, the operator holds the silicon and the keys, the device emits its own signed evidence, and the customer, or their regulator, can verify it without trusting the operator's word at all.

What the procurement shift actually demands

The sovereign-AI conversation is often framed around geography, which datacentre, which jurisdiction, whose law. Geography matters, but it is not sufficient. A workload inside the right border, on infrastructure the user still cannot inspect, satisfies a residency box and leaves the integrity question open.

The harder requirement now appearing in defence and critical-infrastructure procurement is verifiable isolation: not a statement that a system was air-gapped, but a record that survives independent replay. The two filed applications behind these Mickai subsystems are an attempt to meet that requirement at the level of the hardware rather than the level of the contract.

For the classified, the regulated, and the genuinely critical, the conclusion is not a slogan. It is an engineering position. The cable should be pulled, and the gap should be a thing you can prove, not a thing you are asked to believe.

Top comments (0)