Air-gapping removes direct internet exposure; it does not remove software vulnerabilities. Isolation can slow remediation because production cannot reach package repositories, registries, vulnerability feeds, or vendor update services. An urgent fix must cross a controlled boundary without turning media or an import gateway into a supply-chain shortcut.
The right operating model treats patching as a governed product pipeline. NIST SP 800-40 Revision 4 describes enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades. For an air-gapped AI platform, each verb occurs in a different trust zone and must produce evidence before the next step.
Inventory the whole AI dependency chain
The AI application is only the top layer. A model server depends on an accelerator runtime, driver, kernel, and firmware. An update to one layer may be incompatible with the next.
Maintain a versioned inventory covering:
- server, accelerator, storage, and network firmware;
- hypervisor, operating system, kernel, and host configuration;
- Kubernetes, container runtime, device plug-ins, and base images;
- GPU drivers, CUDA or equivalent libraries, and collective-communication components;
- model servers, model adapters, tokenizers, quantization libraries, and custom code;
- embedding and reranking services, vector databases, parsers, and OCR engines;
- agent runtimes, tool gateways, connectors, identity clients, and policy services;
- user interfaces, APIs, logging agents, backup software, and administrative tools.
Record the deployed digest, environment, owner, support status, advisory source, and dependencies. An SBOM identifies components inside an image, but configuration, firmware, model-side code, and live deployment state still need coverage.
Bring intelligence in without bringing trust with it
Use a connected acquisition zone to collect vendor advisories, CISA’s Known Exploited Vulnerabilities Catalog, vulnerability records, signatures, release notes, SBOMs, and update artifacts. This zone is not production and should not directly publish into the restricted network.
Prioritize using several factors:
| Factor | Question |
|---|---|
| Exploitation | Is the vulnerability known to be exploited? |
| Exposure | Is the affected component reachable from users, tools, or imported content? |
| Privilege | What identity or host authority could an attacker obtain? |
| Data impact | Could prompts, documents, embeddings, logs, or credentials be exposed? |
| Operational risk | What could the patch disrupt in the accelerator and model stack? |
| Compensation | Can the component be disabled, isolated, or shielded until deployment? |
A CVSS score alone does not capture the environment. A parser flaw reachable by every uploaded document may be more urgent than a critical flaw in a disabled component. Combine CISA KEV evidence with local reachability and mission impact.
Build an immutable offline release bundle
Acquire artifacts from approved sources and retain the original signatures, hashes, licences, release notes, and SBOMs. Pin every package and container by digest. Scan the bundle and its unpacked contents in a disposable quarantine environment with no production credentials.
The bundle should include:
- the exact firmware, packages, and container images being promoted;
- a manifest of component names, versions, digests, and source locations;
- signatures and verification material available inside the restricted zone;
- installation order and compatibility constraints;
- configuration migrations and database changes;
- acceptance, smoke, security, and rollback tests;
- the previous approved artifacts required for recovery;
- vulnerability decisions, approvers, and exception records.
Sign the final manifest using the enterprise release process. Transfer it through the approved cross-domain solution, data diode, or removable-media workflow. Verify the signature and every digest again after transfer, then publish to an internal package or container repository. Production hosts should never install directly from the media device.
This extends the secure model-artifact pipeline from model weights to the software and firmware that execute them.
Test compatibility, security, and recovery together
An AI patch can pass a basic health endpoint and still fail under a real workload. Use representative hardware and production-like configuration. Test:
- node reboot and cold model load from internal repositories;
- each approved model format and quantization;
- embedding, reranking, retrieval, OCR, and document parsing;
- agent planning, tool calls, approval gates, and audit export;
- authentication, certificate rotation, and permission enforcement;
- GPU memory pressure, concurrency, timeout, and failover behavior;
- backup, restore, downgrade, and configuration rollback;
- disconnected operation with all unapproved egress denied.
Compare security configuration before and after installation. Package upgrades can re-enable telemetry, add repositories, change service accounts, reset policy files, or introduce new network destinations. Run the egress blackout test against the patched stack.
Define a rollback boundary. Firmware, database migrations, model registries, and indexes may not all support simple downgrade. Snapshot or back up the required state, document irreversible steps, and establish the latest point at which rollback remains safe.
Promote through rings and measure the delay
Move the same immutable bundle through laboratory, integration, pre-production, limited production, and broad production rings. Do not rebuild it for each zone. Start with non-critical workloads on representative hardware, observe, then expand. Emergency patches can shorten observation periods, but they should not skip digest verification, basic compatibility, recovery readiness, or approval.
Track metrics that reveal operational risk:
- time from advisory receipt to applicability decision;
- time from decision to a tested bundle;
- time from transfer to complete deployment;
- percentage of assets with known version and owner;
- failed installations and rollback rate;
- overdue exceptions and compensating-control age;
- difference between connected-zone and restricted-zone vulnerability views.
An exception should name the affected asset, reason, business impact, compensating controls, owner, review date, and expiry. “Air-gapped” is not a compensating control by itself—users, administrators, imported documents, media, and connected upstream systems still create attack paths.
Offline maintenance with VDF AI
VDF AI supports deployment on customer-managed infrastructure, including restricted and air-gapped environments. The platform’s local model endpoints, orchestration, knowledge storage, and audit path can operate without a public AI control plane. VDF AI Router can restrict routing to approved local models, while VDF AI Networks keeps workflow traces and governance inside the perimeter.
The surrounding platform team still owns firmware, operating systems, accelerator software, registries, transfer controls, vulnerability intake, testing, and release approval. The air-gapped deployment guide covers the wider architecture. An offline patch pipeline is what keeps that architecture supportable after day one.
Sources and further reading
- NIST SP 800-40 Revision 4: Guide to Enterprise Patch Management Planning
- CISA Known Exploited Vulnerabilities Catalog
- NIST SP 800-218: Secure Software Development Framework
- NIST Secure Software Development, Security, and Operations Practices
- Air-gapped AI deployments in restricted networks
Need an update path for AI infrastructure that cannot connect to public services? Book a VDF AI architecture review to design the transfer, verification, test, promotion, and rollback process.