Air-gapped sovereign AI for a UK defence organisation

A delivered engagement. The client is not named, the use cases are not described, and no operational or capability detail appears here. What is published is the platform and the assurance pattern.

The constraint

Stricter than the government deployment, and different in kind. No transfer path the other way, no supplier connection, no telemetry, no vendor reaching in to fix things. If cleared staff standing in front of it cannot operate it, it does not work here.

That rules out most commercial AI platforms and much open-source tooling, which expects to fetch a tokeniser, config file or dependency at runtime. A component that silently reaches out on first run is a design failure, and it surfaces at the worst moment.

And under MOD Secure by Design the security case had to be live from day one, evidenced continuously by the delivery team.

Why HGX rather than a turnkey system

HGX B300 was chosen for reasons that have little to do with performance: freedom over the server vendor and physical build, with the NVIDIA reference architecture underneath. The chassis, rack, supply chain and installation must satisfy the accreditor as well as the engineers.

In defence, "who built this, and where" is asked seriously and answered in writing. Answering it without giving up the validated GPU platform decides HGX over a turnkey system more often than throughput does.

The transfer boundary is the design

On an air-gapped defence network, the security surface that matters is where artefacts come in: the only place anything can arrive. Every artefact is untrusted until proven otherwise, and the procedure was agreed with the accreditor before the build.

• Hashes recorded on both sides of the transfer and verified
• Model weights accepted only in formats that do not execute code on load, so no pickle-based checkpoints, however convenient
• Container images pinned by digest, scanned inside the boundary, rescanned against imported CVE data on a defined cadence
• Signature verification where supported, a recorded provenance position where not
• A one-way procedure with a named approver, so every transfer is an auditable event

Hardening and the security case

Hosts, container runtime and orchestration were built in code from DISA STIG baselines reconciled against CIS Benchmarks Level 2, and scanned before handover. Each deviation is documented with finding ID, reason and compensating control.

The Secure by Design security case was a living artefact through delivery, which changes the sequencing. Controls are evidenced as implemented, risks recorded as identified, and the risk position can be stated at any point.

Supply-chain expectations under Def Stan 05-138 and DEFCON 658 were treated as in scope for our own delivery, not just the client platform. Suppliers tend to discover that late, and at cost.

Model provenance as a first-class control

Here, open-weight models are often easier to defend than hosted ones, if the provenance work is done properly. Know exactly which artefact is running, prove it has not changed, and be able to rebuild the whole deployment from your own mirror with the wire cut.

In practice: weights held locally with recorded hashes, a pinned, reproducible serving stack, and an evaluation baseline for the artefact in service. Every new version repeats the full transfer, verification and evaluation sequence.

That answers the question defence programmes most often ask about open weights. The concern is rarely openness. It is provenance, and provenance can be solved.