Air-Gapped AI: Running Code Intelligence Without Internet Access

Air-gapped AI is an AI system designed to operate without a network path to the public internet. For code intelligence, the code, repository indexes, models and inference stack stay inside an isolated environment instead of sending context to an external API.

A real air gap goes much further than running an LLM on a local server. Licensing, telemetry, model assets, software updates and dependencies also need to work when internet access disappears.

That distinction matters for defense, critical infrastructure and any organization where sensitive source code can't leave a controlled environment.

What does air-gapped AI mean?

An air-gapped environment has no normal network route between the protected system and the public internet.

It isn't the same as a private cloud, a VPC or an application running internally while calling an external model API. It also isn't the same as a self-hosted agent that sends inference requests to a vendor's cloud.

NVIDIA's air-gap deployment documentation provides a useful practical example. Model assets are prepared while internet access is available, transferred into the isolated environment and then loaded locally. Once deployed, the NIM can run without a connection to external model registries such as NGC or Hugging Face Hub.

For AI systems working with source code, the same rule needs to apply beyond the LLM.

Repository data, embeddings, indexes, rerankers and the services used to retrieve code context become part of the offline stack.

That's where the difference between local AI and air-gapped AI starts to matter.

Air-gapped AI isn't a theoretical requirement anymore

Defense organizations are already deploying generative AI in protected environments.

Poland is a useful example. The Polish Armed Forces have developed AIRON, an AI platform operating inside Ministry of National Defence infrastructure. A presentation discussed at the Polish Senate's Digital Skills Summit 2026 described AIRON as supporting tools including chat, translation and software development inside MILNET-I and MILNET-Z, including work with classified information up to the zastrzeżone level.

The military's own AI work is also moving toward local inference at the tactical level. In July 2026, Poland's Cyber Defence Component Command described AIRON TACTIC as using Edge AI to run LLMs locally.

The interesting problem, then, isn't simply where the model runs.

A locally deployed LLM can still know almost nothing about the architecture, dependencies and implementation history of a particular software estate.

For software engineering teams, there are at least two different layers:

Model layer: where inference happens.

Code context layer: how the model gets accurate knowledge about the organization's repositories and systems.

That second problem becomes especially important when an organization has dozens or hundreds of repositories that can't be sent to an external service.

Five problems air gaps create for AI systems

1. A local model can still have hidden online dependencies

An application may use a local LLM and fail the moment its internet connection disappears.

Dependencies can hide in:

• license validation
• telemetry and crash reporting
• authentication
• package managers
• model registries
• extension marketplaces
• remote embedding APIs

Some inference systems may also download missing model assets when they first start.

NVIDIA's air-gap workflow requires model assets to be prepared before the isolated phase specifically so the deployed system doesn't depend on NGC or Hugging Face Hub.

So instead of asking:

“Does our source code leave the environment?”

ask:

“Would everything still work if we disconnected the cable for twelve months?”

That's a much harder test.

It exposes products that support local inference but still rely on an external license server, telemetry endpoint, package repository or model registry.

2. Updates become part of the security architecture

Air-gapped software still needs patches.

The update process simply looks different.

A typical workflow is:

Internet-connected staging environment → download artifacts → validation → approved transfer → internal registry → offline deployment

Red Hat documents a comparable process for OpenShift deployments in disconnected environments. If the internal registry can't be reached from an internet-connected host, content can be mirrored to a filesystem or removable media, physically moved into the restricted environment and then imported into the internal registry.

For AI systems, the release bundle may contain more than the application itself:

• application containers
• model weights
• tokenizer files
• embedding models
• rerankers
• system packages
• GPU drivers and libraries
• database migrations
• release metadata

A deployment that requires docker pull latest after installation isn't really designed for an isolated network.

Model weights, tokenizer, embeddings and dependencies need to travel with the application.

3. Hardware sizing gets complicated quickly

“Run a 14B model locally” isn't a hardware specification.

A 14-billion-parameter model in BF16 requires roughly 28 GB for the model weights alone. Actual memory use grows once the inference engine, KV cache, context window and concurrent requests are included.

A good real-world example comes from NVIDIA NIM's DeepSeek-R1-Distill-Qwen-14B notes. NVIDIA warns that running its vLLM profile with less than 48 GB of GPU memory can exhaust the available KV cache at the model's maximum sequence length and recommends reducing the maximum model length to 32,768 tokens in that situation.

Even a 7B deployment can run into the same class of problem on a 24 GB A10G when context requirements grow.

Quantization helps. For example, vLLM supports FP8 KV-cache quantization, reducing the cache's memory footprint and allowing more tokens to stay in memory.

So hardware planning has to consider:

• model size and quantization
• maximum context
• simultaneous users
• embeddings and reranking
• indexing workloads
• storage for current, next and rollback versions

A workstation-class GPU can be enough for smaller deployments. Multi-user production environments can require much more.

4. Observability can't quietly depend on SaaS

Many modern applications assume they can send logs, crashes and telemetry to an external service.

That assumption breaks inside an isolated network.

Air-gapped systems need local equivalents for:

• application logs
• model metrics
• audit trails
• administrative events
• error diagnostics

The organization can then pass relevant information into its own internal monitoring or SIEM systems.

Telemetry also needs a genuine off switch.

“Anonymous telemetry” is still network traffic if it leaves the environment.

5. Models become part of the patch lifecycle

Traditional software already has dependencies and security updates.

AI adds more moving parts:

• new model weights
• embedding models
• tokenizer changes
• inference engines
• agent frameworks

Each new artifact needs to follow the same controlled import path.

Air-gapped AI therefore benefits from small, deterministic and clearly versioned release bundles rather than installations that discover dependencies dynamically.

A practical architecture for air-gapped code intelligence

A useful design separates the external preparation environment from the isolated runtime.

The external side prepares, validates and packages software.

Only approved artifacts cross the boundary.

Inside the protected environment, services that would normally live on the public internet need local equivalents.

A simplified architecture could look like:

INTERNAL SOURCE CONTROL

GitLab / GitHub Enterprise / Bitbucket / Azure DevOps / Perforce

              ↓

       CODE INDEXING

              ↓

    LOCAL KNOWLEDGE STORE

              ↓

 SEMANTIC RETRIEVAL / CONTEXT

              ↓

        LOCAL LLM

              ↓

 DEVELOPER / MCP / INTERNAL UI

The important point is that the model is only one component.

For code intelligence, the retrieval layer decides what the model knows about the organization's actual software.

Where Tentaro fits into an air-gapped code intelligence stack

Tentaro is an AI-powered code context platform built around that retrieval layer rather than another general-purpose coding model.

It indexes an organization's private source code and builds an internal knowledge base that can be queried in natural language. Unlike search limited to one repository at a time, Tentaro is designed for multi-repository environments and says it can work across more than 100 repositories.

That matters in large software estates where a developer asking “Do we already have a service that handles this?” may need an answer spanning multiple teams, shared libraries and services.

Tentaro's existing product architecture includes several pieces relevant to isolated environments.

On-premise deployment

Tentaro can run on the customer's own infrastructure or a dedicated cloud environment, giving the organization control over the deployment and configuration. Its public product information also states that customers can choose their own LLM rather than relying on one mandatory vendor-hosted model.

That model flexibility matters because an organization can pair the code context layer with an inference stack already approved for its environment.

Repository indexes without internet access

Tentaro states that repository indexes are stored inside isolated containers with no internet access. It also says stored contents, analysis results and responses are encrypted using AES-256.

For an on-premise deployment, Tentaro says customer data stays inside the organization rather than being sent to an external code intelligence service.

Multi-repository context

The platform semantically indexes code across repositories and retrieves relevant implementations instead of relying on the LLM's general knowledge.

Tentaro can point users back to the files involved in an answer and enrich those references with explanations highlighting relevant lines. It also supports incremental indexing so changed files can be reprocessed without rebuilding the entire index.

For more detail on that layer, Tentaro has a separate guide to AI-powered code search for enterprise teams.

MCP integration

Tentaro exposes an MCP server for integration with developer tooling.

In an isolated deployment, that creates a useful pattern:

Developer tool → Tentaro MCP → local code context → local model

The code-intelligence layer can provide repository-specific context without requiring the developer's assistant to retrieve that context from an external SaaS service.

What still needs to be validated for a full air-gap deployment

On-premise deployment and internet-isolated repository indexes are strong building blocks, but air gap describes the complete operating lifecycle, not one product feature.

For any specific deployment, teams should still validate details such as:

• offline license behavior
• installation dependencies
• update package transfer
• rollback procedures
• model distribution
• telemetry settings

Those are exactly the questions that separate “can run locally” from “can operate indefinitely without an external network path.”

Offline licensing matters more than it sounds

Licensing is one of the easiest ways to accidentally break an air-gapped deployment.

A product that needs to reach its vendor every few days to confirm its subscription can't operate independently inside a disconnected enclave.

One common solution is a cryptographically signed offline entitlement.

For example, Coder's licensing system uses signed JWT license keys that are validated locally. Coder explicitly says no outbound connection to its servers is required, including in offline and air-gapped deployments.

Other implementations use signed license files containing customer information, entitlements, expiration dates or machine identifiers. Keygen documents signed license files specifically for offline and air-gapped environments.

Possible designs include:

• perpetual licenses
• time-limited signed licenses
• machine-bound licenses
• local floating license servers
• controlled challenge-response renewal

The key question isn't simply:

“Do you offer offline licensing?”

It's:

“What happens to the product after six or twelve months without any communication with your infrastructure?”

A data diode isn't the same thing as an air gap

The terms sometimes get mixed together.

NIST defines a data diode as a device that allows data to travel in only one direction. It's also called a unidirectional gateway.

That means a data diode still creates a communication path.

An air-gapped network may have no such path at all.

For example, an organization could use a diode to export logs:

CLASSIFIED NETWORK

        ↓

    DATA DIODE

        ↓

MONITORING NETWORK

Nothing can travel back through the same channel.

But that doesn't mean every air-gapped system receives its updates through a data diode. Many environments use controlled physical transfer instead.

Local doesn't automatically mean secure

Removing internet access eliminates a major class of external communication paths.

It doesn't eliminate security risk.

A local AI agent can still have:

• filesystem permissions
• shell access
• access to internal tools
• access to source repositories
• permission to modify files

The question therefore shifts from only “Can source code leave the network?” to “What can the AI do inside the network?”

Physical transfers create another attack surface.

CISA's Cybersecurity Performance Goals explicitly warn that attackers can use removable media such as USB drives to introduce malware into disconnected or air-gapped systems.

That's why controlled update processes may include a dedicated transfer station, malware scanning, cryptographic validation and strict media handling.

An air gap changes the threat model.

It doesn't remove the need for one.

Air-gapped AI and accreditation for classified systems

For organizations handling classified information in Poland, there's another distinction worth making.

A specific teleinformation system gets accredited, not a software product in isolation.

According to Poland's Internal Security Agency (ABW), systems intended to process classified information marked zastrzeżone are accredited by the head of the organizational unit through approval of the system's security documentation. ABW or SKW can then issue recommendations relating to the system.

Systems processing poufne or higher classifications are accredited by ABW or SKW. The authority has six months from receiving complete security documentation to grant or refuse accreditation, with another six months possible in justified cases.

That distinction matters for vendors.

Saying that a product can operate in an isolated environment isn't the same as saying it is independently “certified for classified information.”

The configuration, infrastructure, procedures and organization all form part of the accredited system.

Questions to ask any air-gapped AI vendor

“On-prem”, “private” and “local AI” are useful starting points.

They aren't enough to verify an air-gapped deployment.

Ask:

• Can the system be installed with public DNS and internet connectivity completely unavailable?

• Can the license remain valid without contacting your infrastructure today and a year from now?

• What is the complete update procedure from release download to production deployment?

• Can telemetry be disabled completely?

• Are the model, tokenizer, embedding model and reranker included in the deployment package, or will anything try to download during startup?

• How can administrators verify the integrity and origin of every imported artifact?

• What is the rollback procedure if an offline update fails?

• What exactly stops working when external network connectivity disappears?

A vendor that can answer all eight questions precisely probably understands disconnected operations. One that keeps returning to “your data stays private in our cloud” is answering a different question.

Air-gapped code intelligence is an architecture, not a checkbox

Running an LLM locally is becoming easier.

Operating a useful AI system indefinitely inside a disconnected environment is harder.

Models need context. Software needs updates. Logs need somewhere to go. Licenses need to remain valid. Hardware needs enough capacity for actual workloads rather than just model weights.

And for software engineering teams, the AI needs accurate knowledge of the code it's being asked about.

That's the role of the code context layer.

Tentaro's on-prem AI code context platform combines multi-repository indexing, isolated repository storage, configurable models and MCP access to keep that context close to the software it describes.

For teams evaluating any system for a disconnected environment, though, the final test stays simple:

Disconnect the cable.

Then ask what still works.