How Do You Verify That an AI Is Genuinely Air-Gapped and Not Just Restricted Egress?

You verify a genuine air gap by proving five things are absent from the machine, not by reading a vendor claim. Confirm there is no network address translation, no external DNS resolution, no outbound certificate-authority trust, no two-way link of any kind, and no update path that is not signed physical media. Restricted egress still routes packets and still resolves names, so a firewall rule can be changed in seconds. A real air gap has no reachable path in either direction, which is why the strongest form to test for is a zero-egress inbound perimeter where nothing can be dialled inward at all.

This matters in 2026 because regulated buyers can no longer use public cloud AI services such as hosted assistants for their most sensitive work, and the market has filled with systems that call themselves air-gapped while quietly holding a metered link open. Under the US CLOUD Act, any data reachable by a US-controlled provider is legally reachable by a US warrant regardless of where the server sits. DORA has been in force since January 2025, NIS2 raises the bar on critical-sector resilience, and the EU AI Act high-risk obligations under Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk to 2 August 2028 and Article 50 transparency largely unchanged. We read that deferral as a build window, not a reprieve. The question a buyer should ask has shifted from does it work to can you prove nothing leaves and nothing gets in.

What is the difference between an air gap and restricted egress?

Restricted egress means a live network connection exists and a policy limits what may travel over it. The wire is connected. The name servers answer. The certificate store trusts external authorities. Someone with administrator rights, or a supply-chain implant, can widen the policy without touching the hardware. An air gap means the path itself is absent: no route, no resolver, no trusted outbound anchor. The distinction is not a slider. It is the difference between a locked door and a wall. Restricted egress is a locked door, and locks have keys.

What can an auditor physically check?

An auditor should verify absence, not configuration, because configuration can be reverted. The checks are concrete and each one is falsifiable:

• No network address translation on the host or its segment, so there is no mechanism to map an internal address to an external one.
• No external DNS. The machine cannot resolve a public name, so it cannot find a destination to reach even if a route appeared.
• No outbound certificate-authority trust. The certificate store contains no public root, so no external TLS endpoint can be authenticated and no silent callback can establish trust.
• A one-way data diode only, if any ingress path exists at all. Data can enter over hardware that is physically incapable of carrying a return signal.
• Signed physical media for every update. Firmware, models and policy arrive on media whose signature is verified offline, and nothing is fetched.

Each item is a test with a yes or no answer. A vendor who cannot let you run all five is describing restricted egress.

Why is a zero-egress inbound perimeter a stronger claim than nothing leaves?

Nothing leaves outward is a claim about data exfiltration, and it is the claim most vendors make. It is weaker than it sounds, because a system that can be reached from outside can be instructed, updated or exfiltrated through later. A zero-egress inbound perimeter inverts the guarantee: nothing is reachable inward. There is no listening service, no inbound route and no credential that resolves to the machine from any external network. If nothing can dial in, no remote party can command the system, plant an update or open a channel that then carries data out. Zero inbound is the parent property. Get it right and outbound containment follows, because a channel that cannot be opened cannot be used in either direction.

“An air gap that anyone can verify by testing for the absence of a path is worth more than a stronger-sounding policy that only the vendor can see.”

How does Mickai build and prove this?

Mickai is a Sovereign Intelligence Operating System, a SIOS, that runs offline on operator-owned hardware with every action cryptographically sealed. It is built for the zero-egress inbound posture described above rather than retrofitted with a firewall. Sovereign models run locally, so no prompt or answer needs to leave the box. Machine identity is hardware-attested and bound to the audit chain, so the running instance can prove which physical device it is without contacting any external authority. Every action is written to a post-quantum signed audit ledger using the FIPS 204 (ML-DSA) signature standard, so the record of what happened is tamper-evident and verifiable long after the fact. Where higher assurance is needed, cross-model consensus lets several sovereign models check each other offline. The point is offline verifiability: the operator can prove the properties without our involvement and without a connection to us. The estate behind this posture comprises 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; these are filed applications, never granted or patented.

Which rules make this necessary?

Several regimes converge on the same requirement. The US CLOUD Act makes any provider-reachable data legally reachable, which is precisely what a genuine air gap removes. DORA obliges financial entities to control third-party and network dependencies. NIS2 extends resilience duties across critical sectors. GDPR constrains where and how personal data may be processed. ISO/IEC 42001 sets the management-system expectation for AI governance, and an auditable offline system maps cleanly onto its controls. FIPS 204 (ML-DSA) defines the post-quantum signatures that keep an audit ledger trustworthy against future decryption. None of these is satisfied by a policy that a privileged account can quietly change. They are satisfied by an architecture where the risky path does not exist.

What is the single test to ask a vendor for?

Ask to run the machine on a bench with no uplink and watch it work at full function. Then ask to inspect the certificate store for external roots, the resolver for public name resolution, and the segment for network address translation. If the system needs any of those to operate, it is restricted egress. If it runs fully with all of them absent, and updates arrive only on signed media over a one-way path, it is air-gapped. The test costs an afternoon and it cannot be faked with documentation. We think every serious buyer should demand it.

Frequently asked questions

Can a firewall rule alone make an AI air-gapped?

No. A firewall sits on a live connection and enforces a policy over it, which means the path exists and the policy can be changed by a privileged account or a compromised update. That is restricted egress. An air gap is the absence of the path itself: no route, no external DNS and no outbound certificate-authority trust, so there is nothing for a rule to permit or deny.

How do updates reach a genuinely air-gapped AI?

Through signed physical media that is verified offline, or over a one-way data diode that is physically incapable of carrying a return signal. The signature is checked on the isolated side before anything is applied, so a tampered update is rejected without any network call. If a vendor updates the system by fetching from the internet, it is not air-gapped.

Is zero-egress the same as air-gapped?

They overlap but are not identical. Zero-egress usually describes preventing data from leaving, which can still allow the system to be reached inward. A genuine air gap requires both directions to be absent, and the stronger property to test for is a zero-egress inbound perimeter, where nothing is reachable inward at all. If nothing can dial in, no remote party can open a channel that later carries data out.

Why can regulated firms not just use a hosted AI service in a locked-down mode?

Because those are public cloud AI services and the data they process is reachable by the provider, which under the US CLOUD Act makes it legally reachable by warrant regardless of server location. A locked-down mode still runs on infrastructure the buyer does not own and cannot air-gap. For DORA, NIS2 and GDPR exposure, the deciding factor is whether anyone outside the operator can reach the data, and with a hosted service the answer is yes.

Does an air-gapped AI still produce an auditable record?

Yes, and it can be stronger than an online one. Mickai writes every action to a post-quantum signed audit ledger using the FIPS 204 (ML-DSA) signature standard, with machine identity hardware-attested and bound to that chain. The record is tamper-evident and can be verified offline, so an auditor confirms what happened without the system ever needing a network connection.