Air-gapped AI agents: what zero egress actually takes

Every serious deployment conversation with a security-conscious institution reaches the same checkpoint, and it is run by the network team, not the data team: "What does it need to reach?" Most enterprise AI products answer with a list — a model API, a license server, a telemetry endpoint, an update channel — and then negotiate about which items are really necessary. DataQube is built so the negotiation isn't needed: the platform itself reaches nothing, and the one dependency that genuinely needs a model — the model — runs where you decide.

Two honest clarifications before the engineering. First, full air-gap is a supported way to run DataQube, not the only way: most clients choose commercial frontier models running in their existing cloud footprint — their own tenancy, under zero-data-retention terms, inside agreements their security team has already reviewed. Second, the air-gapped ceiling is still what shapes the product. Designing for the hardest case is why the easier cases are clean: a platform with no telemetry, no license callbacks, and no update channel behaves identically whether the model endpoint is across the cluster or across their cloud. This article is about that ceiling — what it actually takes.

Where the model runs is your dial, not ours

The model endpoint is configuration, and the configuration spans a spectrum. At one end: an OpenAI-compatible endpoint in your own cloud tenancy — the frontier models your teams already know, with zero data retention in force, meaning prompts and outputs are not stored and not used for training, and traffic never leaves the agreements you already govern. This is where most clients land, because it buys frontier-model quality without creating a single new data relationship.

At the other end: a fully air-gapped deployment, with an in-cluster inference service on your own GPUs serving open-weight models you have chosen and validated. No route out at all — the configuration for closed networks, and the mode the rest of this article stress-tests.

What both ends share is the property that matters to an auditor: model choice is under your change control. A model upgrade is a change ticket — tested, approved, reversible — not a vendor silently swapping weights under an API. When someone asks "which model produced last quarter's numbers, and who approved it," the answer is in your change history either way.

Delivery: one approved path for everything

Getting software into a network with no internet is a solved logistics problem — every air-gapped institution already operates an approved-artifact path with a registry mirror behind it. The design obligation on the vendor is to need only that path, for every artifact, with no exceptions that arrive later as surprises:

A release is container images, deployment charts, model weights where we supply any — and the license, which is deliberately boring: a signed file validated locally against our public key, no license server, no activation call, renewals as a file swap through the same path. Nothing in the set expects to fetch anything else: zero egress means the entire dependency closure — down to awkward artifacts like browser engines — surfaces at build time and ships pinned, rather than arriving through a download nobody reviewed. Digest pinning is what makes the whole path trustworthy: what your team reviewed at the boundary is byte-for-byte what runs inside, and the digests in the deployment record answer "what exactly is running" for any audit, forever. Reproducible builds close the loop — a running digest ties back to a source release without taking our word for it.

Support without a tunnel

The question that follows delivery: "When something breaks, how do you help us if you can't connect?" It deserves a concrete answer, because "we'll figure it out" is how remote-access exceptions get born.

Our answer has three parts. First, the audit and diagnostic logs are structured and exportable by design — the same records that serve compliance serve support, and they never contain data, credentials, or personal information, so exporting them through a review process is tractable. Second, reproducible builds mean a reported issue against a digest is a reproducible issue in our lab: we run the same bytes, not a guess at them. Third, fixes travel the artifact path like any release — on your change calendar, not ours.

That last clause is a real cost, so it belongs in the open. Zero egress made us give up things vendors like: silent auto-updates (customers upgrade deliberately, on their schedule), usage analytics (we learn from design partners and drills, not telemetry), and remote debugging (the logs must be good enough, which forces them to be). We consider each trade a feature wearing a cost's clothing — every one removes a channel your security review would otherwise have to model.

The checklist for any vendor claiming air-gap support

"Air-gap capable" spans everything from "genuinely designed for it" to "worked once in a demo with the Wi-Fi off." Five questions separate the ends of that range. Where can the model run — and is fully inside a supported answer, not a roadmap item? Does licensing ever call out, even once? Can every artifact in a release be mirrored and verified by digest — including the awkward ones like browser engines and model weights? What exactly does support receive when something breaks, and does any answer involve a tunnel? And the summary question the network team will ask anyway: what does the platform itself need to reach?

Our answers are on the security page, and the deployment spectrum — cloud tenancy with zero data retention through fully air-gapped — is what the Sovereign tier on our pricing page exists for. A demo runs fine with the internet unplugged, which is rather the point.