The air-gapped ADLC

Air-gapped environments have a reputation for being a niche concern, invoked by vendors as a checkbox and by buyers as a hypothetical. In practice there are quite a lot of them: defence programmes, classified government work, certain national infrastructure, parts of the payments world, pharmaceutical research where the intellectual property is the entire company, and a growing set of environments that are not literally air-gapped but are operationally treated as such because the approval to open an egress path takes eighteen months.

These environments want agentic development for the same reasons everyone else does, and in some cases more, because they tend to run older codebases with fewer engineers and longer change cycles. What they cannot do is adopt the standard architecture, because the standard architecture assumes a network call to somebody else’s infrastructure.

This piece is about what actually changes. Not the marketing version, where you self-host a model and everything else is identical, but the list of things that turn out to depend on connectivity in ways nobody documented.

What genuinely has to move inside

The obvious one is inference. A model running on hardware inside the boundary, which today means an open-weight model, quantised to fit whatever accelerators the programme could get approved, served by an inference runtime someone has to operate.

Less obvious, and this is where most first attempts stall: essentially every other network dependency in the pipeline.

InferenceThe expected one. Open-weight model, local accelerators, an inference server somebody now owns.

Package registriesEvery dependency resolution is a network call. Needs a full internal mirror, populated deliberately.

Container imagesBase images, build tooling, everything the pipeline pulls. Same problem, different registry.

Documentation and referencesAgents read docs. With no internet, the corpus has to be imported and kept current by hand.

Vulnerability dataAdvisory feeds are how you know a dependency became dangerous. Now a manual import on a schedule.

Licence and identity servicesAnything that phones home to validate. Frequently discovered at the worst moment.

The one that catches teams is the last row. A surprising amount of infrastructure software performs a silent outbound call at startup, for licence validation, telemetry, or update checks. In a connected environment nobody notices. Inside the boundary it manifests as a component that works in testing and hangs in production, and the diagnosis takes days because nothing in the logs says “waiting on a network call that will never complete.”

Any component intended for an air-gapped deployment needs to be evaluated for this specifically, and the evaluation is empirical: run it with egress blocked and watch what it tries to reach. Vendor assurances are frequently sincere and wrong, because the vendor’s own build has a dependency they did not write.

The capability gap, stated honestly

Self-hosted open-weight models are meaningfully behind frontier hosted models. This gap narrows over time and it is real right now, and pretending otherwise sets up a programme to fail against expectations set by a demo someone saw at a conference.

What is more useful than a general claim is a sense of where the gap bites.

Holds up well

Bounded, well-specified changes in a familiar language with good local context. Test generation. Mechanical refactoring.

Degrades noticeably

Long-horizon tasks requiring many steps held together. Novel architecture. Reasoning across many files at once.

Compensable

Weaker single-shot quality, recovered through tighter criteria, smaller units of work, and more verification.

Not compensable

Deep knowledge of an obscure framework the model never saw. No amount of process recovers what is not in the weights.

The compensation strategy is the interesting part, and it argues for something slightly counterintuitive: air-gapped environments need stronger verification infrastructure than connected ones, not weaker. If the model is less reliable, the criteria have to be tighter and the checking more thorough. Organisations that treat the air-gapped deployment as a stripped-down version of the connected product have it backwards.

Governance does not get simpler

A persistent misconception is that removing the internet removes the governance problem. It removes one class of it, which is exfiltration to an external party. Everything else remains and some of it intensifies.

There are still multiple internal runtimes: a large model on the good hardware, a smaller one for fast iteration, possibly a specialised one for a particular language. Which one processed which piece of work is still a question with an answer that needs recording, both for reproducibility and because in the environments that require air gaps, the accountability requirements are usually the strictest anywhere.

Provenance matters more, not less. The whole reason a programme is air-gapped is that the work is sensitive, which means the question “what changed, who authorised it, what verified it” is asked more often and by people with more authority to act on an unsatisfactory answer.

And least privilege applies identically. An agent inside a classified boundary with broad credentials is not safe because the boundary exists; it is a lateral movement problem waiting for something to go wrong. The boundary protects against outside-in, and most of the damage an over-permissioned agent can do is inside-out.

What the operating model looks like

The practical shape of an air-gapped ADLC has a few consistent features across the programmes I have seen described.

ImportScheduled, reviewed transfer of models, packages, advisories and docs across the boundary.

ServeInternal inference with per-runtime identity, so which model did what is recorded.

VerifyCriteria and checks run entirely inside. Tighter than connected environments, deliberately.

ProveSigned chain from intent to merge, held internally, produced for audit without egress.

The import process deserves more attention than it usually gets. It is a recurring, reviewed operation with a security process attached, and it is the single point where the boundary is deliberately crossed. Everything about the environment’s currency depends on it running reliably: model updates, dependency updates, and above all the vulnerability advisories that tell you a library you shipped last year is now a problem. A programme that does this quarterly is running with a quarter of blind spot, which for some threat models is fine and for others is not.

Where this breaks down

The hardware is a real constraint and a slow one. Accelerators sufficient to serve a capable model to a development organisation are expensive, and in the environments that need air gaps they are also subject to procurement cycles measured in quarters. The technical design is often finished long before the hardware arrives, and pilots run on undersized machines that produce misleading quality assessments.

Somebody now operates an inference platform. This is a specialist skill set that most engineering organisations do not have and cannot easily hire into a cleared environment. Model serving, quantisation trade-offs, memory management, throughput tuning under concurrency: none of it is exotic, and all of it is new work for a team that previously consumed an API.

Staleness is a security posture, not just an inconvenience. An environment that imports quarterly has, by construction, up to three months of unaddressed advisories. That may be an entirely reasonable trade against the exfiltration risk it eliminates, but it should be a decision someone made explicitly rather than a property that emerged from an import process nobody owns.

The documentation corpus is a hidden dependency. Agents perform substantially worse when they cannot consult current documentation for a library. Importing and maintaining a documentation corpus is unglamorous, nobody budgets for it, and its absence shows up as “the model is not very good” rather than as the missing-input problem it actually is.

Not every “air-gapped” requirement is one. A meaningful share of programmes asking for this have a strict egress approval process rather than a genuine physical air gap. The distinction matters enormously for cost: a reviewed, monitored, allow-listed egress path to a single regional endpoint is a fraction of the effort and satisfies many of the same concerns. It is worth asking which constraint is real before committing to the expensive one.

The takeaway

An air-gapped agentic life cycle is achievable and several organisations are running one. It is not the connected architecture with the network removed; it is a different operating model with an import process at its centre, an inference platform someone owns, and a verification layer that has to be stronger than usual because the model is weaker than usual.

Governance does not get easier. The runtimes multiply internally, provenance requirements are stricter than average in exactly these environments, and least privilege applies unchanged because the boundary does nothing about inside-out risk.

If you take one thing into next week, and this applies even if you have no air gap anywhere: run one component of your pipeline with outbound network blocked and see what breaks. The list will contain at least one thing you did not know was there.

The next piece stays with the boundary but turns it around, looking at what flows outward in the ordinary case: prompts, context, and the leak surface that did not exist three years ago.