Air-Gapped AI Is a Ladder, Not a Checkbox

Ask an AI vendor whether their platform "runs air-gapped" and you will almost always hear yes. The word has become a checkbox — and a checkbox is exactly the wrong shape for it. Air-gap readiness is a ladder, and the difference between its rungs is the difference between a demo that happens to run offline and a system you can trust to command physical equipment while the network is down.

Here is the question that sorts vendors in the first five minutes, not the last:

What happens to identity and authorization on your platform when the WAN has been down for 30 days and an agent issues a command to physical equipment?

A vendor who can answer concretely has thought about industrial reality. A vendor who changes the subject is telling you their architecture assumes the cloud is reachable — which means "air-gapped" was a connectivity claim, not a security claim. The five levels below — we call them the Air-Gap Readiness levels, AGR-1 through AGR-5 — make that distinction precise. Use them on any vendor, including us.

One thing to be clear about before the rungs: no standard defines these levels — the AGR rubric is ours. The leveled schemes you already know grade different things: ISA/IEC 62443's Security Levels (SL 1–4) grade protection against attacker sophistication, and the Purdue model's levels (L0–L5) name network tiers. Neither — nor any open standard yet — grades the question this ladder grades: what is an autonomous system allowed to do, and how is that enforced, while disconnected? Until a standard occupies that gap, we offer this one so the question can at least be asked precisely.

AGR-1 — Runs without cloud egress

The platform operates with zero outbound calls: models local, storage local, execution local. Nothing phones home.

This is what most vendors mean by "air-gapped," and it is the easiest rung to reach — with open-weight models it is largely a deployment choice. It is necessary and radically insufficient: a system can run fully offline and still let any agent read anything, write anything, and command anything. AGR-1 says nothing about what the system is allowed to do once it's alone.

AGR-2 — Enforces authorization and audit, air-gapped

Authorization is enforced by the runtime while disconnected: who may read and write what, checked on every access, by role and by layer of knowledge — with the decisions recorded in an audit trail that is cryptographically chained, so it is tamper-evident and verifiable when the site reconnects.

This is the rung where "air-gapped" becomes a security claim. Least privilege that depends on a cloud policy service is least privilege that evaporates with the WAN. And an audit log that can be silently edited during a disconnect is not an audit log — for the weeks you ran dark, a hash chain is the difference between records and evidence a regulator or an incident review can rely on.

AGR-3 — Actuates safely, air-gapped

AGR-2, plus deterministic safety interlocks on any command toward physical equipment — enforced by a layer that is independent of the AI's reasoning. Identity, tool authorization, and parameter bounds are checked mechanically, and an out-of-envelope command is refused without consulting the model.

This is the rung industrial buyers should refuse to negotiate on, and government guidance agrees: CISA's principles for AI in operational technology call for exactly this separation. The test is simple: can the model talk its way past the safety layer? If the enforcement point shares the model's context — a system prompt, a guardrail model, a "constitutional" instruction — the answer is eventually yes. The model must never be the last line of defense.

AGR-4 — Identity operates at the OT tier

AGR-3, plus machine identity that holds up inside the plant: agents carry standing, locally verifiable workload identity; identity is rooted in hardware; and enterprise credentials terminate at the industrial DMZ, where OT-zone credentials take over. The result is a verifiable, non-forgeable chain of identity from the agent to the actuator, with no cloud identity provider in the loop.

No AI platform delivers this rung alone, and you should distrust one that claims to — these primitives belong to your identity infrastructure, and the platform's job is to consume them cleanly through open standards rather than a proprietary sidecar. This is also where the two worlds that shaped today's tooling visibly fail to meet: cloud-native agent identity assumes a reachable identity provider, while OT security assumes there isn't one. NIST's 2026 concept paper on agent identity points at the join, but no open standard occupies it yet.

AGR-5 — Identity survives the disconnect

AGR-4, plus the hard part: identity and authorization that keep working through a disconnect longer than a credential lifetime. Leases with grace periods, replay protection that tolerates clock drift, and authorization that is connection-aware — a broad envelope online, a pre-staged bounded envelope offline, and fail-safe to the bounded one when the system cannot tell which state it is in.

Nobody ships this turnkey. It is a co-design between the platform and the identity infrastructure, and it only matters if your operation genuinely must actuate through long disconnects — a ship mid-ocean, a remote site with satellite windows. If a vendor claims AGR-5 off the shelf, they have misunderstood the question. If they can discuss it honestly, you have found a serious partner.

Using the ladder

Three habits make the ladder useful. First, make every vendor name their rung — "we support air-gapped deployment" should immediately become "at which AGR level?" Second, match the rung to the operation: monitoring-only pilots can live at AGR-2; anything that touches equipment needs AGR-3 before it earns autonomy; long-disconnect actuation is the only thing that justifies paying for AGR-5. Third, watch for the fail-open tell: ask what happens when the connectivity monitor itself fails. The safe answer is that the system assumes it is disconnected and tightens. Any other answer means that somewhere in the stack, loss of signal grants permission.

Where does DanaOS stand? By construction, AGR-1 with local open-weight models. AGR-2 and AGR-3 are what the runtime's architecture is built to enforce — the access matrix, the deterministic enforcement point in front of equipment, the chained audit — and they are DanaOS's own seams, independent of any identity vendor. AGR-4 arrives with your identity provider, consumed through open standards; AGR-5 is co-designed when an operation truly demands it. We state it that precisely because the ladder only works if everyone answers it honestly — including the people proposing it.

Sovereignty is the reason this ladder exists at all. Your expertise stays inside your walls only if the system that runs it can enforce inside your walls — authorization, safety, and evidence, with no dependency that dissolves when the network does.