Running AI Agents in an Air-Gapped Environment

Some of the most valuable places to run AI agents are also the hardest to reach: hospitals, government departments, financial back offices and plants with strict network rules. In these environments the network boundary is a compliance requirement, and it often means there is no route to the public internet at all. This article covers what changes when an agent platform has to run fully air-gapped, and the mistakes teams commonly make.

What "air-gapped" really means

An air-gapped environment has no connection to the public internet. Some are fully isolated. Others allow a tightly controlled transfer path, such as a one-way gateway or a reviewed media transfer. Before designing anything, find out which one you have, because it decides how you deliver updates, models and licences.

Everything an agent depends on has to live inside the boundary: the orchestration layer, the models, the tools it calls, the data it reads and the logs it writes. Any dependency that quietly calls out to a cloud API will fail the first time it runs.

Model serving

Hosted model APIs are off the table, so models are served locally on your own hardware. Decide early:

• Which models you will run, and whether they meet the quality bar for your tasks. Smaller open-weight models are often enough for classification, extraction and routing, while larger ones can be reserved for hard reasoning steps.
• What GPU or CPU capacity you have, and how you will handle peak load.
• How new model versions get in. Treat a model file like any other release artefact: checksum it, scan it, test it and record who approved it.

Dependencies and updates

Nothing can be pulled from a public registry at install time. Plan for:

• Internal mirrors for container images, language packages and operating system updates.
• Signed release bundles that carry everything needed for an upgrade, with versions pinned.
• A tested rollback path, because you cannot fetch a fix in a hurry.
• Time, DNS and certificates that work internally: an internal time source, internal DNS and a private certificate authority.

Tools and integrations

An agent is only useful if it can act. Inside the boundary that means connecting it to internal systems through APIs, databases, file stores and internal MCP servers, using service accounts with the narrowest permissions that work. Do not let an agent reach anything you would not let a new employee reach on their first day.

Logging, audit and observability

You cannot send traces to a hosted monitoring service, so run your own logging and metrics stack inside the boundary. Record every trigger, every model call, every tool call with its inputs and outputs, and every approval. In regulated settings these records are often the first thing auditors ask for.

Common mistakes

• Testing in a connected environment and discovering hidden internet dependencies on deployment day.
• Forgetting telemetry, analytics and licence checks that phone home.
• Treating model and package updates as an afterthought, so the system ages in place.
• Giving agents broad credentials because it is quicker during a pilot.
• Having no plan for support. Engineers may not be able to log in remotely, so runbooks and diagnostics matter.

A practical starting checklist

• List every external network call the system can make, and remove or replace each one.
• Build and test the full installation from a bundle in an isolated staging network.
• Define the update, rollback and model-approval process before go-live.
• Turn on complete audit logging from the first day.
• Write the runbook for the person who will operate it without you.

NARIRO Platform supports fully self-hosted and air-gapped deployment, and our services team helps design, harden and operate these environments. If you are planning one, get in touch through the Contact page.