Air-Gapped AI: How AI Systems Work Without Internet or Cloud Access

Air-gapped AI is an AI system deployed inside a security domain that has no physical network connection to the external systems it is separated from, with any transfer across that boundary performed through deliberately controlled, non-automated procedures. The AI model, runtime, data, retrieval indexes, tools and operational dependencies required for inference must therefore be available inside the isolated environment. Air-gapped AI is not simply “a local model” or “an on-premise server”: the defining property is the network and transfer boundary around the complete system.

What air-gapped AI really means

The word AI does not change the basic security concept. An air gap is a boundary between security domains. AI simply makes the isolated side more operationally demanding because modern AI stacks normally assume downloadable models, package registries, telemetry, APIs, model hubs and frequent software updates.

The isolated environment can still contain many connected machines. An internal cluster may have GPUs, application servers, storage, databases, identity services and monitoring connected to each other. The air gap exists between that enclave and the outside domain.

The relevant question is therefore not “Does this GPU have Wi-Fi?” but “Can this AI environment exchange information with the external domain through an automated physical or logical path?”

The simplest example

Imagine a company wants an internal assistant for confidential technical documents, but the environment is not permitted to send those documents to the internet.

The company downloads an approved LLM, embedding model, container images and software packages in a connected staging environment. After validation, approved artifacts are transferred into the isolated environment.

Inside the enclave, the model server, document parser, vector database, application and identity services run locally. Users can ask questions and use RAG against internal documents without a cloud model or public model registry.

When an update is required, the update passes through the controlled import process again rather than being downloaded directly by the production AI server.

Where the simple example stops

A production air-gapped environment can be much larger than one workstation. It may include Kubernetes/OpenShift, internal registries, object storage, identity providers, vector databases, observability, backup infrastructure and several model-serving nodes.

The more services exist inside the enclave, the more the organization must reproduce capabilities that connected environments normally consume from the internet.

Air-gapping therefore shifts complexity. It reduces direct external connectivity but increases artifact-management, patching, dependency, supply-chain and operational responsibility inside the isolated domain.

Air-gapped vs offline vs local vs on-premises vs private vs sovereign AI

These terms can overlap but are not synonyms. A local Ollama server connected to the internet is local AI, not air-gapped AI. An on-premises RAG platform that calls a cloud model is on-premises application infrastructure with cloud inference, not air-gapped AI.

An air-gapped system is often private by design because data remains inside the enclave, but privacy also depends on authorization, logging, data handling, physical security and operational policy.

Strict air gap vs practical disconnected deployment

A practical air-gapped AI architecture

A complete architecture should be able to start and operate without DNS lookups, license checks, package downloads or API calls to public services unless those dependencies have approved internal replacements.

A useful design test is to disconnect the deployment from every external service and cold-start the stack. Hidden dependencies tend to appear during startup, model loading, authentication, package resolution or telemetry initialization.

Models must be pre-staged

Cloud model APIs are unavailable by definition if the isolated workload has no path to them. The enclave therefore needs locally runnable model artifacts or an internally hosted inference service.

NVIDIA's current NIM air-gap documentation explicitly uses a two-phase pattern: download and prepare model assets on a connected machine, transfer them, then run the isolated NIM from local storage without outbound registry access or cloud API keys.

Model weights are only part of the dependency set. Tokenizers, configuration files, adapters, quantization metadata and any required runtime code must also be present.

Models with remote-code dependencies are an air-gap hazard

Some model repositories contain custom Python code or runtime hooks that normally fetch additional code or assets.

Current Red Hat AI Inference documentation explicitly warns that some Hugging Face models requiring remote code cannot operate normally in disconnected environments because the library attempts network access even when offline mode is configured.

The practical lesson is to test a model's entire loading path offline before approving it for an isolated deployment. “I downloaded the weights” is not proof that the model is self-contained.

Containers, packages and drivers become local supply-chain artifacts

Connected environments routinely pull container images, Python packages, OS updates and GPU components from public registries. An air-gapped environment cannot assume any of those services.

Red Hat's disconnected AI deployment model uses internal mirror registries for container images and operator catalogs. Models can be mirrored as OCI artifacts or transferred to persistent storage.

For broader stacks, the same pattern often applies to language packages, Linux repositories, JavaScript packages and internal binaries: approved artifacts enter once through the transfer process and are then served from trusted internal repositories.

Know the complete dependency bill

Internal mirrors are infrastructure, not a convenience

A disconnected deployment becomes maintainable when the isolated domain has known internal sources for approved artifacts.

Red Hat's documented approach uses a mirror registry available to the disconnected cluster so workloads do not need public registries.

The same architectural idea can be applied to model stores and package repositories. The objective is to make artifact origin, version and approval explicit rather than copy random files manually to each server.

RAG can work fully air-gapped

RAG does not require the public internet. It requires a retrievable corpus, an ingestion/indexing pipeline and a model that can use the retrieved context.

Inside an air-gapped environment, the document store, parser/OCR, embedding model, vector or lexical index, reranker and generation model can all run locally.

What changes is source acquisition. Live web search and cloud document connectors are unavailable unless equivalent data is imported through the controlled boundary.

The corpus therefore becomes a governed artifact. Every import should preserve source identity, date/version and provenance so users know what knowledge the isolated system actually contains.

Agents can run air-gapped — but only with reachable tools

An agent loop can run entirely inside an isolated enclave if the model/runtime and required tools are local or reachable on the internal network.

A tool that depends on GitHub, public web search, cloud email or an external SaaS API will fail unless the architecture provides an approved internal equivalent or controlled asynchronous exchange process.

This is why air-gapped agent design should begin with a capability inventory: every tool endpoint must be classified as internal, imported, unavailable or deliberately excluded.

MCP does not bypass the air gap

MCP can expose local tools and resources inside an isolated AI environment, but the protocol does not create connectivity through the security boundary.

A local MCP server that reads internal documents can work perfectly offline. A remote MCP server on the public internet cannot be reached from a strict air-gapped enclave.

The same principle applies to any connector protocol: interoperability is separate from network authority.

Identity and authentication must also work offline

An AI application can be locally hosted while still depending on a cloud identity provider. That hidden dependency breaks truly disconnected operation.

Air-gapped designs therefore need an identity architecture that functions inside the enclave: local directory, internal identity provider, internal PKI, local service credentials or another approved mechanism.

Authorization remains necessary even though the internet is absent. Air gaps do not replace RBAC, tenant isolation or least privilege.

Time, certificates and trust stores become local dependencies

Many authentication and logging systems depend on reliable time. Certificates expire. Trust stores change. Signed artifacts need validation.

A disconnected enclave should therefore have internal time synchronization and a certificate/trust lifecycle that does not depend on reaching public services during ordinary operation.

These are ordinary infrastructure concerns that become visible only when an architecture is tested without internet access.

Telemetry and crash reporting need explicit policy

Many modern libraries attempt analytics, update checks or error reporting by default.

In an isolated environment those calls should either be disabled or redirected to internal observability. Repeated failed telemetry attempts can create delays, noisy logs and unexpected startup behavior.

An air-gapped deployment should know which components attempt egress even if the firewall would block them.

Air-gapped systems still need patches

Network isolation does not stop software from developing vulnerabilities. It only changes how patches reach the system.

NIST frames patch management as preventive maintenance: organizations still need to identify, acquire, prioritize, install and verify patches and updates.

Air-gapped operations therefore need a repeatable import cadence for OS packages, container images, drivers, AI runtimes and security updates. The trade-off is between isolation stability and vulnerability exposure from stale software.

A controlled update path

The transfer boundary is the most sensitive operational interface

If external information must enter an air-gapped system, the import channel becomes a major security control point.

The NSA Cybersecurity Technical Cyber Threat Framework explicitly recognizes replication through removable media as a path adversaries can use to cross into disconnected or air-gapped networks.

That is why controlled media handling, inspection, provenance, encryption where required, malware scanning and role separation can matter as much as the AI stack itself.

Removable media is not a neutral pipe

USB drives and other portable media can carry both legitimate model/data artifacts and malicious content.

NIST's media-sanitization guidance treats storage media as a confidentiality lifecycle object that may require clearing, purging or destruction according to sensitivity and reuse needs.

The exact transfer procedure is organization-specific, but the architectural principle is stable: cross-boundary media should be governed as a security asset, not treated as an informal convenience.

Air-gapping increases supply-chain importance

An isolated system receives fewer live external inputs, but every imported binary, model, container and package becomes more consequential because the enclave may trust it for a long time.

NIST software-supply-chain guidance emphasizes provenance, supplier risk, vulnerability management, software verification and SBOM-oriented practices. These concerns become directly relevant to offline AI artifact import.

Model supply chain deserves the same attention as application supply chain: model origin, license, hash, format, required code, tokenizer, adapters and evaluation status should be known before import.

Air-gap readiness should be tested, not assumed

Cached once is not the same as air-gap ready

A system may appear offline because the model and packages are already cached from earlier internet access.

Deleting caches or deploying to a clean node can reveal missing tokenizer files, Python packages, model manifests or remote-code dependencies.

Air-gap readiness should therefore be validated from clean internal artifacts, not only from a developer workstation that was previously connected.

What threats remain inside an air gap?

What an air gap actually improves

A genuine air gap can materially reduce attack paths that depend on direct remote connectivity: external command-and-control, cloud credential misuse, internet-facing service exploitation and accidental data exfiltration through ordinary outbound APIs.

It also makes data residency simple in one narrow sense: inference data cannot be sent to an external cloud service if no path exists.

Those benefits are strongest when the transfer boundary and internal access controls are equally disciplined. A poorly managed USB process can undermine the intended isolation.

What an air gap makes harder

Air-gapped AI vs private AI

Private AI is primarily about controlling sensitive data and AI processing. A private AI platform may be on-premises and still access approved cloud models or external services.

Air-gapped AI is stricter on connectivity. A system can be private without being air-gapped, and an air-gapped system can still have poor privacy if every internal user has unrestricted access.

The security objective should determine the architecture: confidentiality, sovereignty, resilience and isolation are related but distinct requirements.

Air-gapped AI vs sovereign AI

Sovereign AI concerns control over the broader dependency chain: data, models, infrastructure, operators, jurisdiction and strategic dependencies.

An air gap can support sovereignty by reducing external runtime dependency, but it does not guarantee sovereign control. The enclave may still depend on foreign hardware, proprietary model licenses or external update suppliers.

The next canonical article separates those control dimensions explicitly.

Original implementation evidence: what the Aaasaasa AI Client proves — and what it does not

The AI Hub separates agent/client, provider, model and connection location. It supports local Ollama inference and local-provider Codex operation as distinct choices rather than assuming that every AI request goes to a cloud model.

The repository explicitly notes that a local runtime can still use a cloud model, while Direct Ollama chat is local inference. This distinction is directly relevant to air-gap architecture: local execution does not prove that the model or surrounding dependencies are disconnected.

Provider abstraction, local model discovery and local inference are therefore building blocks for an air-gap-capable product architecture, but the network boundary, offline dependency mirror, controlled transfer process and offline identity/operations must still be engineered separately.

When is air-gapped AI justified?

Air-gapping should be a requirement derived from a threat model or policy, not a prestige feature. It has real security value when the eliminated connectivity path is itself unacceptable.

For many enterprise use cases, a tightly controlled private network with egress restrictions, local inference and approved update channels may provide a better balance of security and maintainability than a strict physical air gap.

A practical air-gapped AI design sequence

Air-gapped AI architecture checklist

Common air-gapped AI failure modes

Common misconceptions

Limitations

Strict air gaps make external knowledge freshness slower because every new source must pass through a transfer process.

They can constrain model choice when licenses, remote-code requirements, hardware needs or provider-only APIs cannot be satisfied offline.

They increase operational cost because infrastructure normally consumed as cloud services must be owned and maintained internally.

They can also create patch latency: stronger change control may keep systems stable while delaying urgent vulnerability remediation.

Air-gapped AI should therefore be evaluated as one security architecture among several, not assumed to be universally superior.

What would change this answer?

Vendor support for disconnected operation changes quickly. New model formats, signed OCI artifacts, offline license mechanisms and integrated model registries can reduce operational friction.

The distinction between strict air gap and disconnected deployment will remain important even if vendors continue using the terms loosely.

The stable principle is that genuine air-gap claims depend on the system boundary and transfer mechanism, not on whether the LLM happens to run locally.

Related canonical knowledge

Air-Gapped AI is a deployment/security architecture node. Private AI, Sovereign AI and provider abstraction answer different questions about confidentiality, control and dependency.

MLOps/LLMOps becomes more demanding inside a disconnected environment because model, package and update lifecycles must operate through internal repositories and controlled transfer.

RAG and Agentic AI remain valid patterns inside the enclave as long as their data and tools are internally available.

Frequently asked questions

Glossary

Conclusion

Air-gapped AI is not a special kind of model. It is an AI architecture operating inside a deliberately isolated security domain.

The model can be the easy part. Production readiness depends on whether every surrounding dependency — model assets, packages, registries, identity, RAG, tools, monitoring, updates and recovery — can function without an automated external path.

The shortest reliable rule is: local inference proves where the model runs; air-gap evidence proves how the complete system is separated and how every permitted transfer crosses that boundary.

Primary sources and current implementation references

The sources below establish the security definition, current disconnected AI deployment patterns and lifecycle risks. Vendor use of “air-gapped” is intentionally distinguished from the stricter NIST definition.