Field Notes · Private AI August 21, 2026 · 7 min read

Air-gapped does not mean governed.

Isolation is a strong control against one specific thing: reachability from untrusted networks. In sensitive deployments it is frequently the correct choice and sometimes a requirement. What it does not do is answer any governance question. Who holds authority inside the enclave, how software and models got there, how the environment stays current, and what evidence exists if something goes wrong are all unchanged by the gap. Treating isolation as a complete answer produces environments that are hard to reach and difficult to govern.

What isolation actually buys

The claim in favor of isolation is real and should be stated precisely before it is qualified. Removing routable connectivity between a sensitive environment and untrusted networks eliminates the most heavily exercised access paths in commodity intrusion: internet-exposed services, phishing that lands directly on a workstation with reach into the enclave, and opportunistic scanning against known-vulnerable software. That is a substantial reduction in the probability of a certain class of compromise, and it is why isolation persists in operational technology, classified environments, and increasingly in private AI deployments handling material that cannot leave the organization.

Guidance for operational environments treats segmentation and isolation as important layers within defense in depth rather than as standalone solutions, which is the accurate framing. Isolation is one control with one effect. The failure is not using it. The failure is concluding that having used it, the remaining questions have been answered.

The questions the gap does not touch

Six governance questions survive isolation completely, and in several cases isolation makes them harder:

• Identity and authorization inside the enclave. Isolation is a perimeter property. Inside, the questions are unchanged: who has accounts, what can each of them reach, are privileges separated, is there any record of who did what. Isolated environments frequently drift toward shared credentials and flat authorization precisely because the perimeter is doing the reassurance work.
• Administrative access. Someone administers the enclave, and that person crosses the boundary by definition. Their workstation, their credentials, and the jump hosts or management interfaces they use are part of the security model whether or not the diagram shows them.
• Provenance of everything inside. Every binary, container, dependency, firmware image, and model weight got in somehow, and the transfer mechanism is the real trust boundary. What was verified before crossing, against what reference, by whom? Supply chain risk does not require network connectivity to arrive; it arrives with the thing you carried in deliberately.
• Update cadence. Isolation raises the friction of patching, and friction reduces frequency. The predictable consequence is that known vulnerabilities have a longer half-life inside the enclave than outside it. An isolated environment three years into deployment is often running software with well-documented issues that would have been remediated automatically in a connected estate.
• Evidence and observability. Centralized logging typically works by sending telemetry somewhere, which is the thing isolation is designed to prevent. Unless collection and retention were designed for the isolated case, the environment produces less usable evidence than a connected one. That degradation lands hardest exactly where consequences are highest, and it is the condition described in Evidence Gaps Are Findings: an investigation is bounded by what was recorded.
• Data movement by other channels. Isolation removes network egress. It does not remove removable media, printed output, photographs of screens, or the people authorized to be in the room. Where the concern includes insider risk or exfiltration by a determined actor, the gap changes the channel rather than closing the question.

Most air gaps are managed crossings

There is also a definitional problem worth naming, because it affects how the control should be evaluated. Environments described as air-gapped usually have deliberate crossings: a data diode, a staging or transfer system, a vendor maintenance path, a licensing or activation check, scheduled export of results. Each crossing exists because the organization needs it, and each is a designed interface with its own authorization, validation, and logging properties.

This is not hypocrisy; a genuinely sealed environment is useless for most purposes. It does mean the honest description is a strictly controlled boundary rather than an absence of one, and the security question shifts accordingly. What crosses, in which direction, under whose authority, validated how, recorded where. A board or executive told "it is air-gapped" has been given the name of an architecture, not an answer about its interfaces.

Why this matters for private AI specifically

Isolated deployment is a common answer to a legitimate concern: an organization wants a capable model to work with material that cannot be sent to a third party. Isolation genuinely addresses the third-party disclosure risk. The problem is that the AI system brings its own governance surface with it, and none of it is affected by the gap. The retrieval store still contains a copy of the sensitive corpus, with whatever authorization it inherited or failed to inherit. The prompt and output logs still accumulate the most concentrated record of what people asked and what the system returned. Model weights still came from somewhere and were verified or not. Administrators still have access to all of it. That system decomposition is the argument of Private AI Is a Custody Model, Not a Hosting Model, and isolation changes the network exposure of that system without changing its internal governance at all.

Questions to ask before accepting isolation as the answer

1. What exactly crosses the boundary, in each direction, and who authorized each crossing to exist?
2. Who administers this environment, from what device, and what record exists of their actions?
3. How does software, firmware, and any model artifact get in, and what is verified before it does?
4. What is the patch cadence in practice, not in policy, and what is the oldest unpatched component currently running?
5. If misuse occurred inside the enclave next quarter, what evidence would exist, and for how long would it be retained?
6. Which of our actual concerns does isolation address, and which concerns remain fully in force? Insider risk, credential misuse, supply chain compromise, and configuration error are all unaffected.

The sixth question is the one that reframes the decision. Isolation should be selected because it addresses a threat the organization has actually identified, and the remaining threats should be addressed by something else, deliberately.

The strongest objection

The serious counterargument comes from practitioners in high consequence environments: isolation is not merely one control, it is the control that makes an entire class of attack economically impractical, and treating it as equivalent to other controls understates it. That is correct, and this note does not claim equivalence. Isolation is frequently the single highest-value architectural decision available, and in some regulated and operational contexts it is mandatory rather than optional.

The argument is narrower: isolation buys a probability reduction in one attack class while accepting a detectability reduction and a patch-latency increase in exchange. That is a different risk profile, not a strictly superior one, and it deserves to be chosen with both sides visible. An organization that isolates and then invests the savings in internal identity governance, provenance verification, and enclave-appropriate logging has made isolation pay. An organization that isolates and then relaxes has traded visible risk for invisible risk and told itself it improved.

A boundary condition on the other side: for genuinely low-value environments, this analysis is over-engineered. If the isolated system holds nothing consequential, the governance questions matter proportionally less, and the effort belongs elsewhere.

What good looks like

A well-governed isolated environment is recognizable from its documentation. The crossings are enumerated, each with an owner and a validation step. Administrative access is named, separated from general use, and recorded. There is a written procedure for how software and model artifacts enter, including what is checked against what. Patching has a schedule that someone reports against, with known exceptions listed rather than discovered. Logging is designed for the isolated case, with defined retention and a defined way to get evidence out when an investigation needs it. And leadership can state which threats isolation handles and which ones it does not, without consulting the architecture team.

Conclusion

An air gap is a control with a specific, valuable effect on remote reachability, and it is silent on identity, administration, provenance, currency, evidence, and non-network data movement. Environments that treat isolation as the governance answer tend to accumulate weak internal authorization, aging software, thin telemetry, and undocumented crossings, all under a label that implies safety. The corrective is neither to abandon isolation nor to defend it, but to state plainly what it was chosen to solve, and then to govern everything it was never going to touch.

← All Field Notes