← The ADLC library
Verticals · 6

What agentic delivery changes in defense and govtech

This is the one industry where the standard architecture is simply unavailable. No egress, no hosted model, and an accreditation boundary that treats new software as a change to be justified rather than a capability to be adopted.

Every other industry in this series adopts agentic delivery with modifications. Defense and government programmes frequently cannot adopt the standard version at all, because it assumes a network call to infrastructure outside the boundary and there is no boundary crossing available.

That is not a preference and it is not risk aversion. In a classified environment the constraint is physical, and no contractual assurance from a model provider addresses it.

What follows is what the life cycle looks like when you remove that assumption, and why the governance argument in this sector is stronger than the productivity one.

The accreditation problem comes first

Before any technical discussion there is an organisational one that determines the timeline, and engineering teams routinely underestimate it.

Introducing a new component into an accredited environment is a change to the accredited system. It has to be assessed, documented, and approved by whoever holds that authority. This is not a procurement step that runs in parallel; it is a gate, and it is measured in quarters.

The practical consequence is that the technical design is usually finished long before anything can run, and pilots happen on undersized hardware in a development enclave that does not resemble the target environment. Quality assessments made in that enclave are frequently misleading, and programmes that plan around them get surprised.

So the sequencing advice for this sector is unusual: start the accreditation conversation before the technical evaluation, because it is the long pole and its answer may change what you evaluate.

Everything has to come inside, not just the model

Teams reason about self-hosting inference and stop there. Inference is the visible dependency and rarely the one that blocks the programme.

InferenceThe expected one. Open-weight model on accredited hardware, served by something somebody now operates.
Package registriesEvery dependency resolution is a network call. Needs a populated internal mirror and a process to keep it current.
Container and base imagesSame problem, different registry, usually discovered second.
Documentation corpusAgents perform materially worse without current library docs. Nobody budgets for importing this.
Vulnerability advisoriesHow you learn a dependency became dangerous. Now a scheduled manual import with a staleness window you own.
Licence and telemetry callbacksThe one that bites. Components that quietly phone home work in test and hang in production.
The model is the first thing moved inside and the least likely to be what stops the programme. The last row is diagnosed in days because nothing logs "waiting on a call that will never complete."

That last row deserves emphasis. Any component intended for a disconnected environment needs to be evaluated empirically, by running it with egress blocked and observing what it reaches for. Vendor assurances here are usually sincere and frequently wrong, because the vendor has a dependency they did not write and have never tested in isolation.

Verification has to be stronger, not weaker

There is a natural assumption that a disconnected environment is a degraded one where you accept less. On the verification side the opposite is true, and this is the most important design point in the whole sector.

Self-hosted open-weight models are behind frontier hosted models. That gap is real, it narrows over time, and it is not uniform: bounded, well-specified work in a familiar language holds up well, while long-horizon multi-step tasks and reasoning across many files degrade noticeably.

The compensation is tighter criteria, smaller units of work, and more verification, not less. Which means an air-gapped programme needs a stronger checking apparatus than a connected one, and organisations that treat the disconnected deployment as a stripped-down variant have the relationship backwards.

Holds up well

Bounded changes, familiar language, good local context. Test generation. Mechanical refactoring.

Degrades noticeably

Long-horizon tasks, novel architecture, reasoning across many files at once.

Compensable

Weaker single-shot output, recovered with tighter criteria and smaller units.

Not compensable

Knowledge of an obscure framework the model never saw. Process does not recover what is not in the weights.

Scope to the left column and lean on the bottom-left. Programmes that expect the top-right from a self-hosted model are the ones that report disappointment.

Governance does not get easier when the internet goes away

Removing egress eliminates exfiltration to an external party. It eliminates nothing else, and several obligations intensify.

There are still multiple runtimes inside the boundary: a large model on the good hardware, a smaller one for fast iteration, perhaps something specialised. Which one processed which work is a question with an answer that needs recording, for reproducibility and because the accountability requirements in these environments are the strictest anywhere.

Provenance matters more rather than less. The reason a programme is disconnected is that the work is sensitive, which means “what changed, who authorised it, what verified it, who approved it” is asked more often and by people with more authority to act on an unsatisfactory answer.

And least privilege applies unchanged. An agent inside a classified boundary holding broad credentials is not safe because the boundary exists. The boundary addresses outside-in; almost everything an over-permissioned agent can do is inside-out.

The import process is the operating model

The feature that distinguishes a working disconnected programme from a stalled one is usually mundane: somebody owns the boundary crossing, on a schedule, with a security process attached.

Model updates, dependency updates, documentation, and above all vulnerability advisories all arrive through that one door. Everything about the environment’s currency depends on it running reliably. A programme importing quarterly is running with up to a quarter of blind spot on known vulnerabilities, which may be an entirely reasonable trade against the exfiltration risk eliminated, and should be a decision someone made deliberately rather than a property that emerged from nobody owning the process.

Where this breaks down

Hardware procurement sets the schedule and it is slow. Accelerators sufficient to serve a capable model to a development organisation are expensive and, in these environments, subject to cycles measured in quarters. The design is typically complete long before the hardware lands.

Somebody now operates an inference platform. Serving, quantisation trade-offs, memory management, throughput under concurrency. None of it exotic, all of it new work, and the pool of people who can do it inside a cleared environment is small.

Not every stated air-gap requirement is one. A meaningful share of programmes asking for this have a strict egress approval process rather than a physical air gap. The distinction is worth enormous amounts of money and effort, and it is worth establishing which constraint is real before committing to the expensive one.

Staleness is a security posture, not an inconvenience. An environment on a quarterly import has a known, quantified window of unaddressed advisories. That is defensible when chosen and indefensible when accidental.

And this capability is not self-serve. Disconnected and self-hosted deployment is an enterprise engagement with an accreditation conversation attached, not something a team switches on. Anyone describing it otherwise has not deployed into one of these environments.

The takeaway

This is the one sector where the standard architecture is unavailable rather than merely uncomfortable. The programme is defined by three things: an accreditation gate that runs in quarters and should be started first, an import process that somebody must own, and a verification apparatus that has to be stronger than a connected environment’s because the model is weaker.

Governance obligations do not relax when the network goes away. The runtimes multiply internally, provenance requirements are the strictest anywhere, and least privilege is unchanged because the boundary does nothing about inside-out risk.

If you take one thing into next week, and it applies even if you have no air gap at all: run one component of your pipeline with outbound network blocked and watch what it tries to reach. The list will contain something you did not know was there.