A practical air-gapped AI model update lifecycle is a controlled release process: define the need, acquire artifacts through an approved intake boundary, establish provenance and integrity, scan and inspect, test compatibility and mission behavior, authorize the exact release, transfer it into the isolated environment, deploy in stages, monitor, and retain a tested rollback path. No single signature, scan, or model benchmark replaces the other steps.
This process belongs inside a broaderair-gapped agentic AI implementationand itsair-gapped agentic AI architecture. The update boundary connects external supply chains to an internal system of models, agent software, retrieval components, tools, policy, and infrastructure. A model update can change outputs even when the application code does not, so it should be governed as a system change, not handled as a file-copy task.
Why does an air-gapped AI system need a formal update lifecycle?
Isolation reduces some network exposure, but it also removes the convenience of continuous vendor feeds, hosted registries, and online verification services. Models and their supporting components still accumulate vulnerabilities, compatibility constraints, expiring dependencies, and operational lessons. Delaying every change can leave known risk in place; accepting changes informally can introduce unverified artifacts or unmeasured behavior.
NIST SP 800-40 Revision 4frames patching as preventive maintenance and defines the work as identifying, prioritizing, acquiring, installing, and verifying updates. The same management idea applies to isolated AI estates, with additional evaluation for model behavior. Meanwhile,NIST SP 800-161 Revision 1treats supply-chain risk as a lifecycle concern involving how products are developed, integrated, deployed, and sustained. Together, those principles support a repeatable release train rather than emergency, one-off transfers.
What should be included in the controlled release?
The release should be larger than the model weight file. Define an immutable release bundle that identifies the model, tokenizer, configuration, adapters, inference runtime, agent platform version, tool interfaces, policy files, system prompts, retrieval or embedding components, required libraries, evaluation package, and operator notes. Record cryptographic digests for the artifacts and assign one release identifier that follows the bundle through evaluation and deployment.
A software bill of materials can make the software portion inspectable. CISA’sSBOM resourcesdescribe component transparency as a building block for software supply chain security. Open formats such asSPDX andCycloneDX can represent software components and dependencies. Use the format that integrates with the program’s existing inventory and vulnerability workflows; producing an unused document is not the objective.
How should intake, provenance, and scanning gates work?
1. Open an update record before acquiring artifacts
Start with the reason for change. Identify the current baseline, the proposed release, its source, affected systems, urgency, expected benefit, known limitations, and decision owner. Capture supplier release notes and relevant licenses. This prevents an attractive new model from entering the process without a mission or maintenance need.
2. Establish origin and integrity
Verify that each artifact came from an approved source and arrived unchanged. Compare hashes through an authenticated channel and validate available signatures or attestations against locally maintained trust material. Provenance should connect the artifact to the expected source, build process, and dependencies—not merely show that somebody signed a file.
The SLSA specificationprovides a model for build provenance and artifact verification.Sigstore’s policy-controller documentationalso describes verifying signatures and attestations with trust roots provided out of band for air-gapped use. These are implementation options, not universal mandates. The program should select mechanisms that fit its approved public-key infrastructure and assurance requirements.
3. Quarantine, scan, and inspect
Place incoming media and artifacts in a controlled staging environment, separate from production. Apply the organization’s approved media, malware, vulnerability, archive, and content inspection controls. Inspect the bundle structure and compare its declared composition with observed packages and files. Route any mismatch, unsigned artifact, unexpected executable content, or failed scan to review instead of automatically waiving the gate.
NIST’s Secure Software Development Frameworkrecommends protecting release components from tampering and collecting provenance for release components. The joint CISA and NSAguidance for managing open-source software and SBOMsdiscusses software composition, static, runtime, and vulnerability scanning as complementary ways to understand a release. A clean scan is evidence for one gate; it is not proof that the model is appropriate or safe.
What must be evaluated before approval?
Evaluate the exact bundle that will be transferred. Repacking or rebuilding after evaluation breaks the connection between evidence and deployment unless the changed artifact is reverified. The test plan should cover three distinct questions: can the release run, does it preserve system controls, and does its behavior remain acceptable for the intended mission use?
| Gate | Question | Representative evidence |
|---|---|---|
| Compatibility | Does the bundle run on the approved compute, drivers, runtime, storage, and interfaces? | Installation results, dependency checks, resource observations, integration tests |
| Security controls | Do identity, permissions, tool restrictions, logging, and data boundaries still behave as designed? | Control tests, denied-action tests, audit-log review, interface verification |
| Mission behavior | Does the updated system meet defined acceptance criteria on representative tasks and failure cases? | Versioned evaluation set, error analysis, human review, comparison to baseline |
| Operations | Can operators deploy, observe, support, and reverse the release? | Runbook exercise, monitoring check, backup validation, rollback rehearsal |
Compare the candidate with the current production baseline. Do not restrict the comparison to average model quality: examine critical errors, task completion, groundedness where relevant, tool-use behavior, resource demand, latency, and human intervention. The guide toevaluating AI beyond a demonstrationexplains how to turn claims into representative evidence, whileprototype versus pilot evidencehelps distinguish a controlled technical test from operational learning.
How should approval and transfer be controlled?
The approval record should name the exact release identifier and digests, systems authorized to receive it, evidence reviewed, limitations, deployment window, responsible operators, monitoring conditions, and rollback trigger. Mission, platform, security, and operations stakeholders may hold different responsibilities; the program should document who recommends, who authorizes, and who executes.
Transfer only the approved bundle through the organization’s established cross-boundary and removable-media procedures. Recheck integrity on the receiving side before the artifact enters the internal registry or repository. Preserve the distinction between a staged artifact and an authorized production release. This guide intentionally stays at the governance and architecture level: site-specific transfer controls should come from the responsible security and authorizing organizations.
How should deployment, monitoring, and rollback operate?
Deploy progressively where the environment and mission allow. Begin with a non-production validation, then a bounded user or workload group, and expand only after the defined observations remain acceptable. Keep the previous approved release available and protect its configuration, because restoring only the old model may not reverse related changes to prompts, adapters, runtimes, or agent policies.
Monitor both technical health and mission behavior. Technical signals include availability, resource consumption, errors, integration failures, and control enforcement. Mission-oriented review looks for changes in output quality, critical failure patterns, human overrides, and unexpected tool actions. Define in advance which observations pause expansion, trigger investigation, or require rollback.
A rollback is a controlled change, not an admission of failure. Test the procedure before the release, confirm that dependent data and configurations remain compatible, and record the restored baseline. If rollback occurs, retain the evidence needed to understand whether the cause was the model, a dependency, an integration, or the deployment process.
For a DT deployment, begin with the platform’sdeployment and operating responsibilities. Identify who manages the application, model inference, storage, and execution services. Use that allocation to assign each component’s update, validation, recovery, and support work in the lifecycle record.
What documentation makes the lifecycle defensible?
Maintain a linked record of intake, hashes, provenance, SBOM or component inventory, scan results, exceptions, evaluation configuration, results, approvals, transfer custody, deployment locations, monitoring decisions, incidents, and rollback outcomes. The record should answer four questions without reconstructing the process from memory: what changed, why was it accepted, where is it running, and what should happen if it fails?
Documentation also improves the next update. Repeated compatibility failures can shape platform standards; recurring evaluation gaps can improve test assets; emergency exceptions can reveal where the regular release cadence is too slow. Teams selecting the underlying platform can use the companion guide toevaluate an open-source agent platform for air-gapped use.Forward-deployed engineering for defense AIcan help connect these controls to the people operating the mission workflow.
A minimum update decision package
Keep the release identifier, artifact digests, source and provenance, composition record, security findings, compatibility results, mission evaluation, approvals, deployment scope, monitoring conditions, and rollback procedure together. If one item changes, determine whether the approval and evaluation still apply.
Frequently asked questions
How often should an air-gapped AI model be updated?
Use a risk-based cadence rather than an arbitrary interval. Consider mission need, vulnerabilities, support status, model improvement, operational burden, and the time required to evaluate and authorize a release. Maintain a routine path for planned releases and a governed path for urgent changes.
Does a valid signature mean a model is safe to deploy?
No. A valid signature can support authenticity and integrity, depending on the trust model. It does not establish that the artifact is free of vulnerabilities, compatible with the environment, within policy, or effective for the intended mission. Those require separate evidence.
Should model weights, runtimes, and agent software be updated separately?
They may have different release cadences, but every approved configuration should identify the compatible versions that form the system baseline. If one component changes, evaluate the effect on the integrated system and preserve a rollback bundle that can restore the complete prior baseline.
Can updates be rebuilt inside the isolated environment?
Sometimes, if the organization has an approved internal build process and the necessary source, dependencies, trust material, and tooling. The resulting artifacts still need provenance, integrity, composition, testing, approval, and configuration records. An internal build changes the supply-chain design; it does not remove lifecycle controls.