Air-Gapped AI Agent Platform
An AI agent platform is the layer above LLMs where organizations build, govern, and operate AI agents — specialized assistants with tools, knowledge, permissions, and audit trails — and compose them into multi-agent workflows, operating on a network with no connection to the public internet — models, updates, and telemetry all move by controlled offline transfer, so the system functions fully inside a classified or isolated enclave.
Agent platforms are the hardest AI workload to air-gap: agents want tools, tools want networks. A genuinely air-gapped agent platform scopes agents to in-enclave systems — document stores, databases, internal APIs — and proves that no execution path can reach for an external endpoint, because in an accredited environment "mostly offline" is a failing grade.
Agents are the air-gapped workload where the interesting constraint is not the model — it is the tools. An agent platform earns its keep by calling systems: ticketing, document stores, databases, build servers. Inside an enclave those systems exist, but the connectors were written for their cloud versions, and the gap between "supports Jira" and "supports your enclave's Jira Data Center behind an internal CA" is where most of the integration work actually lands.
That makes the tool registry the centre of the deployment rather than an afterthought. Every tool an agent can call has to be explicitly registered, network-reachable from inside the gap, and covered by the same accreditation as the agent itself. An agent that can reach an unregistered endpoint is a finding, not a feature — which is why free-roaming autonomy sells poorly in classified environments and scoped, approval-gated workflows sell well.
The third factor is that audit is not optional here, and it cannot be exported casually. Every agent decision and tool call must be logged inside the enclave, retained under your classification rules, and reviewable by cleared staff. Platforms that treat the audit trail as a cloud service with an in-region option are structurally unsuitable; the log store has to be a first-class in-enclave component.
Why teams run their AI agent platform air-gapped
Built for defense, intelligence, critical-infrastructure and classified-environment teams.
Zero external connectivity, by design
An air-gapped AI agent platform makes no outbound calls — no license pings, no telemetry, no model API fallbacks. If a component phones home, it fails certification; the architecture must assume the internet does not exist.
Built for classified and SCIF environments
Defense, intelligence, and critical-infrastructure operators need AI capability where cloud AI is categorically prohibited. The AI agent platform runs entirely on enclave hardware and clears accreditation reviews because there is nothing external to assess.
Controlled update path
Models, embeddings, and software updates arrive as signed offline bundles through your cross-domain transfer process — the same discipline you already apply to any software entering the enclave.
Core capabilities of an enterprise AI agent platform
Governed agent workspaces
Create agents with scoped tools, knowledge bases, and role-based access — not free-roaming chatbots but permissioned digital workers.
Multi-agent orchestration
Compose agents into networks with routing, approval gates, and eight-phase execution so complex workflows stay observable and controllable.
Tool and MCP integration
Agents call enterprise systems — Jira, GitHub, Slack, databases, internal APIs — through a registered, auditable tool layer.
Full audit trail
Every agent decision, tool call, and model response is logged immutably — the evidence layer governance teams and regulators ask for.
What an air-gapped deployment changes
Everything ships as a self-contained bundle: container images, model weights, embedding models, and documentation must install from local media with no registry or CDN access.
Local models only: the AI agent platform serves open-weight models on enclave GPUs; there is no cloud fallback tier, so model selection and routing happen entirely inside the gap.
Audit evidence must be exportable on your terms — logs stay in the enclave and leave only through your controlled review process.
The air-gapped AI agent platform stack
Air-gapped AI agent platform, layer by layer — with the reason each choice holds up under this deployment mode.
| Layer | Typical choice | Why, here |
|---|---|---|
| Agent runtime | Containerized platform on the enclave Kubernetes or Compose estate | It has to install from local images and run under the enclave's existing patching and backup runbooks, not a vendor-managed control plane. |
| Tool registry | Explicit allowlist of in-enclave endpoints, per-agent scoping | This is the security boundary for agents. An enclave deployment needs deny-by-default: an agent reaches only what it is registered for. |
| Model backend | Locally served open-weight models via vLLM | Agents make many more model calls than a chat user per unit of work, so the enclave model tier is sized by agent step volume rather than headcount. |
| Approval gates | Human-in-the-loop checkpoints on any state-changing action | In classified environments the approval record is often as important as the action. Gates should be configurable per tool, not per agent. |
| Audit store | Append-only log store inside the enclave with controlled export | Logs stay in the gap and leave only through your review process — so retention, indexing, and search all have to work locally. |
| Identity | Enclave AD FS or Keycloak, agents bound to service identities | An agent acting "as itself" breaks accountability. Bind each agent run to a human owner and a service principal your IAM already knows. |
Sizing an air-gapped AI agent platform
| Profile | Scale | Hardware | What actually binds |
|---|---|---|---|
| Single-workflow pilot | 1–3 agents, tens of runs per day | One GPU for the model tier; the platform itself is CPU-bound | Agent latency here is dominated by tool round-trips to enclave systems, not by inference. |
| Department rollout | 10–30 agents, thousands of steps per day | 2–3 GPUs with a small model resident for routine steps | Step volume, not user count, sets model capacity. One multi-step agent run can equal fifty chat messages. |
| Cross-program | Multiple teams, shared registry, separate data domains | Dedicated model nodes plus isolated audit storage per domain | Domain separation in the audit store is usually the binding requirement, ahead of compute. |
Regulations that point to air-gapped
Classified handling
The AI agent platform operates inside SCIF and enclave boundaries; there is nothing to accredit outside them.
ITAR / export control
Technical data entering the AI agent platform never transits foreign-controlled infrastructure.
NIS2 / NERC CIP
Critical-infrastructure isolation is met structurally by the AI agent platform, not contractually.
Zero-trust postures
No third-party endpoints to allow-list — the AI agent platform’s attack surface is your own network.
When air-gapped is the right call — and when it isn’t
Choose air-gapped when
- The network the AI agent platform must serve is already isolated — classified programs, OT networks, offline research enclaves.
- Policy prohibits any external AI API, including via proxy or private link.
- You need AI capability in disconnected field or vessel environments with intermittent or no connectivity.
Consider another mode when
- You can tolerate controlled outbound connectivity → an on-premises AI agent platform is simpler to operate and update.
- Your requirement is legal jurisdiction rather than physical isolation → the sovereign variant fits; air-gapping an AI agent platform is stricter than most regulators ask.
Same capability, different deployment mode:
AI Agent Platform: Air-Gapped vs the alternatives
| Deployment mode | Typical owner | What you gain — and give up |
|---|---|---|
| Air-Gapped (this page) | CISO / Classified Program Lead | Structural security no contract can match — in exchange for moving every model, index, and software update through an offline bundle process. |
| Self-Hosted | Platform Engineering Lead | Complete stack and model freedom with no usage meter — in exchange for your team owning operations, CVE response, and the upgrade cadence. |
| Sovereign | CIO / Chief Data Officer (public sector & regulated EU) | Legal control that survives foreign disclosure orders and sanctions — in exchange for in-country hosting constraints and heavier procurement diligence. |
| Private | CISO / Data Protection Officer | The fastest route to confidential AI — in exchange for a boundary defined by tenancy and contract rather than by a building you own. |
How to deploy an air-gapped AI agent platform
- 01
Inventory the tools that exist inside the gap
List the enclave systems agents will need to call and confirm each has a reachable API, an internal certificate path, and a service account model. This inventory, not the agent design, determines what is buildable in the first phase.
- 02
Register tools deny-by-default
Configure the tool registry so agents can reach nothing until explicitly granted, and scope each grant to a single agent and purpose. Accreditation reviewers will ask exactly this question, and a permissive default is very hard to defend afterwards.
- 03
Deploy the platform and model tier from one bundle
Ship the runtime images, model weights, and registry configuration together so the enclave deployment is reproducible. Verify no component attempts outbound calls for licensing, updates, or telemetry.
- 04
Pilot one workflow with approval gates on every write
Start with a workflow that reads widely but writes narrowly, with human approval on each state change. This builds the audit evidence base and gives reviewers something concrete to assess before autonomy widens.
- 05
Agree log retention and export review
Define how long agent logs are retained inside the enclave, who can search them, and what the review process is for exporting evidence. Doing this after the first incident is considerably more painful.
Where air-gapped AI agent platform projects fail
Connectors written for the cloud edition
The enclave runs the self-managed version of the same tool, with different auth, different endpoints, and an internal CA. Integration effort gets underestimated because "it supports Jira" was taken at face value.
Under-sized model tier for agent step volume
Teams size GPUs for the number of users and then discover a single agent run consumes dozens of model calls. Throughput collapses at exactly the moment the pilot starts being useful.
Audit logs that cannot be searched in place
If reviewing agent behaviour means exporting logs through cross-domain transfer, review will not happen at a useful cadence. Search and retention have to work inside the gap.
How to evaluate an air-gapped AI agent platform
Can agents be created and modified by business teams without code, under IT-defined guardrails?
Does orchestration support human approval gates and rollback, not just chained prompts?
Is every model call routable — small local models for routine steps, larger models where needed?
Are audit logs immutable, exportable, and mapped to your compliance frameworks?
Can the platform run your required models where your data lives?
Air-gapped deployments trade update convenience for structural security; budget for the offline bundle process, but the AI agent platform itself prices like any fixed in-enclave infrastructure — no meters, no per-token exposure.
An air-gapped AI agent platform, on the VDF AI platform
VDF AI is built as exactly this: governed agent workspaces (VDF AI Agents) plus visual multi-agent orchestration (VDF AI Networks), deployable wherever your data must stay.
Air-Gapped AI Agent Platform questions, answered
What is an air-gapped AI agent platform?
An AI agent platform is the layer above LLMs where organizations build, govern, and operate AI agents — specialized assistants with tools, knowledge, permissions, and audit trails — and compose them into multi-agent workflows, operating on a network with no connection to the public internet — models, updates, and telemetry all move by controlled offline transfer, so the system functions fully inside a classified or isolated enclave.
Why do enterprises choose an air-gapped AI agent platform over a cloud service?
An air-gapped AI agent platform makes no outbound calls — no license pings, no telemetry, no model API fallbacks. If a component phones home, it fails certification; the architecture must assume the internet does not exist. Air-gapped deployments trade update convenience for structural security; budget for the offline bundle process, but the AI agent platform itself prices like any fixed in-enclave infrastructure — no meters, no per-token exposure.
Which regulations drive air-gapped AI agent platform adoption?
The most common drivers are Classified handling, ITAR / export control, NIS2 / NERC CIP, Zero-trust postures. Classified handling: The AI agent platform operates inside SCIF and enclave boundaries; there is nothing to accredit outside them.
Can VDF AI run as an air-gapped AI agent platform?
Yes. VDF AI is built as exactly this: governed agent workspaces (VDF AI Agents) plus visual multi-agent orchestration (VDF AI Networks), deployable wherever your data must stay. VDF AI Agents and VDF AI Networks install from a signed offline bundle with the tool registry set to deny-by-default, and write every decision and tool call to an append-only store that stays inside the enclave and is searchable there.
Can AI agents run in an air-gapped network?
Yes, provided the tools they call also live inside the network. The agent runtime, model serving, and audit store all install from local images and need no external service. What does not transfer is any tool that is fundamentally a cloud API — those either have a self-managed equivalent inside the enclave or the workflow has to be redesigned without them.
How do you control what an agent can do in a classified environment?
Through a deny-by-default tool registry plus approval gates. Each agent is granted access to named tools for a named purpose, every state-changing call is gated on human approval, and every decision and call is written to an append-only log. Accountability comes from binding each run to both a service identity and a human owner.
How many GPUs does an air-gapped agent platform need?
Size it by agent steps per day, not by user count — a single multi-step run can generate dozens of model calls. A pilot with a few agents runs comfortably on one GPU, while a department-wide rollout typically wants a small model permanently resident for routine steps plus larger-model capacity for the reasoning-heavy ones.
Related guides and resources
See enterprise AI agents in production
Watch how VDF AI runs governed, multi-agent workflows on your own infrastructure — then compare it against the platforms you are evaluating.