An architecture review can look complete: the model runs on an internal GPU server, the application stays inside the network, and no internet route appears on the diagram. Then the first cold start reaches for a remote model artifact. A license check waits on an external service. Telemetry queues data for a destination the deployment was never supposed to contact.
That gap between the diagram and the running system is the real air-gap test. An air-gapped LLM deployment is ready for production only when one representative workflow can start, run, reconstruct, deliver, fail safely, and be maintained without an unapproved outbound connection. The review therefore has to follow the full operating lifecycle: every asset admitted to the environment, every dependency used at runtime, every operational record created, and every result allowed to leave.
Key takeaways
- Define the air gap around the complete workflow, not only the model server.
- Pre-stage and verify every model, runtime, package, policy, certificate, and test asset the workflow needs.
- Test cold start, restart, failover, logging, and recovery with outbound access denied.
- Keep original values, the protected mapping, Reconstruction, and the authorized destination inside the customer-controlled environment.
- Approve update and export paths separately; neither should create a permanent outbound route.
Define the air gap around the complete workflow
An air-gapped deployment establishes a network condition: the runtime environment has no external network connection. The current LLM Capsule Architecture describes this mode as fully internal and limited to the on-prem Path B execution route. The local model, LLM Capsule runtime, protected mapping, Reconstruction step, and workflow destination remain inside the customer-controlled environment.
That definition is narrower than “on-prem.” An on-prem system can still call a cloud model, download packages, send telemetry, check a license, or reach an external support endpoint. It also differs from a controlled cross-domain transfer, where selected data moves between isolated and connected environments through an approved channel. For adjacent concepts such as sovereign AI and execution paths, the LLM Capsule glossary provides a useful map. The operating test in this article remains specific: fully internal, no external network, and Path B only.
The operating boundary should name all of the following:
- the source system and triggering workflow;
- the LLM Capsule runtime and policy set;
- the local model server and inference dependencies;
- the protected mapping and Reconstruction service;
- the internal destination that receives the reconstructed output;
- logging, monitoring, queues, caches, and administrative services; and
- the controlled intake and export processes used over the deployment lifecycle.
If one of these components requires an undocumented external connection, the workflow has not passed the no-outbound test.
Build the intake bundle before the network closes
A disconnected runtime cannot fetch missing assets on demand. The team must assemble a complete, approved bundle before deployment. The exact contents depend on the chosen model and platform, but the review should cover model weights and manifests, inference images, packages, drivers, policies, certificates, test fixtures, configuration, and rollback assets.
NVIDIA’s air-gap deployment guidance for NIM LLM makes the lifecycle visible. Its connected phase downloads and prepares model assets. The isolated phase mounts those pre-staged assets and runs without outbound access or model-hub credentials. This is a vendor-specific procedure, not proof of an LLM Capsule deployment, but it exposes a general requirement: the runtime must have a complete local dependency set before the network is closed.
Red Hat’s guidance for disconnected OpenShift environments describes a similar pattern for platform content. Required images are mirrored into a registry available to the disconnected environment. The transfer mechanism and security review remain the operator’s responsibility.
For each intake bundle, retain:
- the exact source, version, and cryptographic digest of every artifact;
- the approved transfer method and responsible owner;
- license, malware, vulnerability, and provenance review results;
- compatibility evidence for the target hardware and runtime;
- the policy and configuration version packaged with the release;
- a known-good rollback bundle; and
- the date and approval record for admission to the disconnected environment.
Do not make latest the deployment identity. A reviewer should be able to reproduce the running system from the retained manifest without reaching a public registry or model hub.
Test hidden dependencies with egress denied
The most revealing test is a cold start with egress denied. Clear any nonessential cache, restart the workflow from its documented local assets, and observe every attempted connection. A successful warm restart can hide a missing model file, manifest, package, or credential that was downloaded earlier.
Inspect dependencies that are easy to overlook:
- container and package registries;
- model hubs and remote manifests;
- license or entitlement checks;
- DNS and time synchronization assumptions;
- update and certificate-revocation checks;
- telemetry, crash reporting, and support collection;
- external embeddings, rerankers, search, grounding, and safety services;
- agent tools, MCP servers, webhooks, and notification endpoints; and
- object storage, identity, key, or secret services outside the approved enclave.
Run the same observation during restart, failover, scale-out, backup recovery, and degraded operation. Record blocked calls instead of dismissing them as harmless. An optional feature that retries an external request can create delay, log noise, or queued data even when inference eventually succeeds.
Internal observability also needs a boundary. Logs and traces should go to approved internal collectors. They should identify the workflow, model build, policy version, request state, and failure without copying original values into unnecessary operational records. Support bundles require an explicit export review; they should not become a hidden path around the air gap.
Keep the protected workflow inside the boundary
In the current LLM Capsule target architecture, the source record enters the protection step inside the customer-controlled environment. LLM Capsule creates a protected working version while the original values and protected mapping remain local. The approved local model processes that working version. Reconstruction then reconnects supported values inside the environment before an authorized application receives the reconstructed output.
This local route changes where the model operates. It does not eliminate the rest of the control model. The deployment still needs to define:
- which fields and operational markers the policy protects;
- which caller and workflow may use a mapping;
- how repeated references and relationships remain stable;
- how long mapping and intermediate state may remain;
- which destination may receive reconstructed values; and
- how unknown, altered, expired, unauthorized, or out-of-scope references fail.
Local placement should not be presented as a security or compliance conclusion. It removes an external model route from this topology. The team must still prove access control, data handling, retention, recovery, and downstream authorization for the actual deployment.
Prove the return path with one real workflow
Use one representative workflow rather than a synthetic health check. Start with an internal source record, invoke the approved local model, perform Reconstruction, and write the result to the real authorized destination. Give every artifact a shared test-run ID so reviewers can follow the decision without storing original values in the evidence package.
Run valid and failure cases for:
- repeated and distinct protected references in one response;
- an unknown, partial, duplicated, altered, or expired reference;
- a caller outside the approved identity or mapping scope;
- a timeout before or after Reconstruction;
- a duplicate message or downstream write;
- loss of an internal queue, cache, model server, or mapping store;
- a rejected destination write and controlled retry; and
- rollback to the prior model, runtime, or policy bundle.
The evidence should connect the source request, model and runtime version, policy version, Reconstruction decision, delivery event, final stored result, and rollback action. A model response displayed in a test console does not prove that the workflow returned the correct authorized result to the intended system.
Separate update and export controls
Air-gapped systems still change. Model builds, runtime images, security fixes, certificates, policies, and application integrations all need maintenance. The approval design should make those changes possible without turning an emergency update into an improvised network exception.
Define an intake cadence and owner. Apply the same provenance, integrity, malware, compatibility, and rollback checks used for the initial release. Stage the bundle in a representative environment before admission. After installation, repeat the cold-start, inference, Reconstruction, delivery, logging, and failure tests that could be affected by the change.
Exports need their own classification. A workflow may allow selected reconstructed results to reach another approved internal zone, or it may permit sanitized audit summaries to leave through a controlled process. That decision should name the allowed artifact, destination, reviewer, transfer mechanism, and retained evidence. It should not create an always-on route that the runtime can use.
Treat a new model, runtime image, dependency bundle, policy, observability service, output destination, or transfer procedure as a review trigger. The physical network may remain unchanged while the effective operating boundary changes.
Air-gapped LLM deployment acceptance matrix
Use the matrix after the team has mapped the real workflow. Replace generic labels with the deployment’s actual service, artifact, policy, and owner identities.
This table is an acceptance contract, not product proof. A deployment passes only when the named owners can reproduce the evidence for the running build.
Go/no-go decision
Approve one named workflow, model build, runtime image, dependency bundle, LLM Capsule policy, internal destination, and transfer process. Confirm that the system starts and recovers with outbound traffic denied. Verify that original values, the protected mapping, Reconstruction, logs, and downstream writes remain within their approved boundaries.
Stop the deployment if routine startup, maintenance, observability, support, or recovery needs an undocumented external connection. A complete air gap is an operating property of the whole workflow, not a label attached to the server rack.
