How do you update an air-gapped AI system safely?

Safely means treating every update as the most security-critical workflow an air-gapped site has, because the air gap exists to keep things out, and an update is deliberately letting something in. The procedure that resolves that paradox has six parts: signed artefacts verified against pinned keys, one controlled import path, staged testing before promotion, the update event sealed to the audit ledger, preserved rollback, and a deliberate, risk-assessed patching cadence rather than an accidental one.

The question matters because an air gap is only as strong as its one deliberate opening. Every other security control on the site assumes nothing new arrives without scrutiny, which makes the update path the single place where that assumption is tested for real, on every occasion, by definition.

Why must every update arrive as a signed artefact?

Because an air-gapped site has no continuous connection to verify provenance the way an internet-connected system can check a live certificate chain, so the verification has to be front-loaded into the artefact itself. Models, software and policy packs should arrive signed, checked against publisher keys pinned and held inside the boundary, with hashes verified before anything executes. If the signature or the hash does not check out, the artefact does not run, no exceptions for urgency.

Why does the transfer path matter as much as the artefact?

Because an ad-hoc USB stick from someone's laptop defeats every other control in the chain regardless of how well the artefact itself was signed. Transfers should cross exactly one controlled path: dedicated scanned media handled under a defined process, or a data-diode style one-way import mechanism, never an improvised route chosen for convenience on the day. The controlled path is what makes the signing verification meaningful; a signed artefact carried in on an unscanned, unlogged device has already broken the chain of custody before verification even begins.

Why does an update need to be staged before it is promoted?

Because verifying an artefact's authenticity confirms where it came from, not that it behaves correctly inside your specific environment. The update should land in an isolated staging area first and be exercised against a golden test set before promotion to production, connecting directly to the acceptance-test discipline covered elsewhere: an update that has not been tested against your own golden set has not actually been proven safe for your environment, only proven authentic.

Why must the update event itself be sealed to the audit ledger?

Because provenance has to be provable after the fact, not just true at the moment of installation. What arrived, its hashes, who approved it, and when it was promoted should all be sealed to the audit ledger as the update happens, so that the system's own history proves its provenance chain later, without anyone needing to reconstruct it from memory or scattered logs months afterwards.

Why does rollback need to be preserved, not just possible in theory?

Because an update you cannot reverse is a gamble, not a change. The prior model version and software state should remain restorable and version-pinned after every update, so that if the new version behaves unexpectedly in production, the site can return to the known-good prior state rather than being stuck accepting the consequences of an update that cannot be undone.

How should patching cadence be decided on an air-gapped site?

Deliberately, not accidentally. Air-gapped sites inherently trade update immediacy for control: there is no automatic patch pushed overnight, which is a security strength, but it also means patching only happens when someone decides it should. That means security patching needs a defined, risk-assessed cadence and windows, rather than happening whenever convenient or, worse, not happening because nobody owns the decision. Cyber Resilience Act vendor duties around update integrity and support periods are relevant background here and are covered in depth by a sibling article; this piece notes them only in passing.

“On an air-gapped system, provenance is the patch.”

How signed artefacts, a sealed update ledger and preserved rollback fit into the wider air-gapped architecture is set out at /sovereign-ai, and the film at /film shows the interface in operation.

Frequently asked questions

Can we use a standard USB stick to bring an update into an air-gapped site?

Only if it is part of a defined, controlled process, dedicated scanned media handled under a documented procedure, not an ad-hoc stick from an unmanaged laptop. The control is the process around the media, not the media type itself.

What happens if a signature check fails on an incoming update?

The artefact should not be permitted to run. A failed signature or hash check means the artefact's authenticity or integrity cannot be confirmed, and executing it anyway defeats the entire purpose of the verification step, regardless of how urgent the update feels.

Do we need a full replica environment to stage updates before promotion?

An isolated staging area exercised against a golden test set is the requirement; whether that requires a full production replica or a smaller representative environment depends on the deployment's scale and risk profile, and is not specified universally here.

How far back should rollback capability extend?

At minimum, to the immediately prior version and software state, kept restorable and version-pinned after each update. Organisations with stricter evidential or regulatory requirements may choose to retain a longer chain of prior versions; no single retention period is asserted as universal here.

Does an air gap mean we can skip patching altogether for better security?

No. Skipping patching accumulates unaddressed vulnerabilities regardless of network isolation, since an air gap protects against remote compromise, not against known flaws in software already running. The trade-off air-gapped sites make is deliberate, risk-assessed patching cadence, not the absence of patching.

Who should hold sign-off authority for promoting an update from staging to production?

A named accountable owner rather than an informal team decision, so the promotion event itself has a clear approver recorded in the audit ledger alongside the artefact hashes and the staging test results. Without a named approver, the ledger records that something was promoted, but not who accepted responsibility for the decision.