Air-Gapped AI for Defence and Intelligence: What Running Truly Offline Requires

Air-gapped AI for defence and intelligence means an AI system that runs with no path to the public internet at all: no outbound telemetry, no calls to a cloud model, and no update channel over any network. Running truly offline requires four things in practice: a zero-egress inbound perimeter, model provisioning and updates delivered on signed physical media, an audit trail that can be verified without a network, and hardware-attested identity bound to every recorded action. An air gap is only real when there is no route by which data can leave or instructions can arrive unseen.

The question matters more in 2026 than it did two years ago. Regulated buyers now treat any outbound connection as a data-egress and jurisdiction risk, not a convenience. Public cloud AI services such as ChatGPT, Claude and Gemini are useful, but a defence or intelligence operator cannot send classified or mission data to a third party under foreign jurisdiction. The market has moved from asking whether a model can reason to asking whether the operator can prove where every byte went, and that is an architecture question.

What does air-gapped actually mean here?

Air-gapped means physically and logically isolated from any untrusted network, including the internet. A true air gap has no default route out. It is not a firewall rule that can be relaxed, and it is not a private cloud tenancy. If a system phones home for licences, telemetry, model weights or safety filters, it is not air-gapped, whatever the marketing says.

We build Mickai as a Sovereign Intelligence Operating System, a SIOS, that runs entirely on operator-owned hardware. No vendor-side component must be reachable for it to function. The test is simple: unplug every network cable and pull every radio, and the system must still reason, act and record. If it degrades, it was never offline.

“An air gap is a claim about architecture, not a switch in a settings menu, and it holds only when every path for data to leave and every path for instructions to arrive has been designed out and can be shown to be absent.”

How does an offline system get its models and updates?

Through signed physical media, not a download. Offline model provisioning means the sovereign models are loaded once, on the operator's premises, from media the operator controls. Updates arrive the same way: a sealed package, carried in by hand, with a cryptographic signature the receiving system verifies before anything is applied.

The mechanism that makes this safe is a signature check the operator can perform without trusting the courier. Each update package is signed. The offline system holds the corresponding public key. If the signature does not verify, the package is rejected. This gives a chain of custody for weights and code that does not depend on any network being honest.

• A manifest of every file and its hash.
• A post-quantum signature over that manifest.
• A provenance record naming what changed and why.
• A version floor the system can refuse to downgrade below.

What can an auditor check without a network?

Everything that matters, from the media in front of them. Offline verifiability is the property that the record proves itself. Every action the system takes is written to an append-only ledger, and every entry is cryptographically signed at the moment it is created. An auditor holding a copy of the ledger and the public keys can confirm the record is complete and unaltered without contacting any server.

We sign that ledger using ML-DSA, the post-quantum digital signature standard published as FIPS 204. That choice matters for records that must stay verifiable for decades, because a signature made today should still resist a future quantum adversary. Key material for encryption at rest can use ML-KEM, the key-encapsulation standard published as FIPS 203, which protects keys but does not itself sign or prove the record. The signature is what gives the audit trail its standing.

Which rules make this necessary?

Several, and they now point the same way. The US CLOUD Act means data held by a US-linked provider can be compelled regardless of where the servers sit, which is why foreign-jurisdiction cloud is a live exposure for sovereign workloads. GDPR constrains where personal data may be processed. DORA, in force since January 2025, and NIS2 raise the bar on operational resilience and supply-chain assurance for essential and important entities. ISO/IEC 42001 sets expectations for a governed AI management system.

On the EU AI Act, the high-risk obligations under Annex III were once due to apply from 2 August 2026. The Digital Omnibus deferred them to 2 December 2027, with high-risk systems embedded under Annex I moving to 2 August 2028, while the Article 50 transparency duties are largely unchanged. We read that as a build window, not a reprieve. An architecture that records and proves its own behaviour offline supports these duties and reduces exposure. It does not by itself satisfy any of them, and a contractual promise from a cloud vendor is not a technical guarantee.

What does a zero-egress perimeter look like?

A perimeter that accepts nothing it cannot verify and emits nothing at all. Zero-egress means there is no outbound path by default: no analytics, no crash reporting, no licence check, no model call leaving the boundary. Inbound updates cross the boundary only as signed media, checked before use. Identity is hardware-attested, so the operator terminal proves what it is before it can act, and that attested identity is bound into the same signed audit chain that records the action.

Cross-model consensus runs entirely inside that boundary. Rather than trust a single model, we can route a decision through several sovereign models and record where they agree and where they diverge, offline, on the operator's hardware, with every step written to the sealed ledger. The architecture behind this isolation and sealed record is described across 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, all filed and patent pending.

Frequently asked questions

Is a private cloud the same as air-gapped AI?

No. Private cloud and on-premises tenancy usually keep outbound paths for telemetry, licensing or managed updates, and they often sit under a provider's jurisdiction. Air-gapped means no default route to any untrusted network and no vendor component that must be reachable to run. If unplugging the network stops the system, it was not air-gapped.

Can an air-gapped AI system still receive model updates?

Yes, through signed physical media rather than a network download. The operator carries in a sealed package whose signature the offline system verifies against a public key it already holds. If the signature does not verify, the package is rejected, which keeps the update path under the operator's control.

How do you audit an AI system that never connects to a network?

The record proves itself. Every action is written to an append-only ledger and signed at creation using ML-DSA, the post-quantum standard FIPS 204. An auditor with a copy of the ledger and the public keys can confirm it is complete and unaltered without contacting any server.

Does using a public cloud AI service breach data-protection law?

Not automatically, but it creates exposure. Sending regulated or mission data to a third party under foreign jurisdiction raises risk under GDPR and the US CLOUD Act, and a vendor's promise not to access data is not a technical guarantee. Whether it amounts to a breach depends on the data, the terms and the jurisdiction.

What is the EU AI Act deadline for high-risk AI now?

The Annex III high-risk obligations, 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. Article 50 transparency duties are largely unchanged. We read the deferral as a build window, not a reprieve.