Most agent frameworks assume an internet connection. They phone a hosted model API, pull packages at runtime, fetch tools from a registry, and report telemetry to a SaaS dashboard. Put that same stack inside a classified or disconnected enclave and it does not degrade gracefully — it fails closed, or worse, it tries to reach out and trips a sensor. Here is the pattern we use to run real agents where the network ends.
The constraint, stated plainly
An air-gapped enclave has no route to the public internet, by design and often by physical separation. Nothing the system runs may make an external call. There is no package install at runtime, no model API, no remote logging, no license check that needs to reach a server. Everything the system needs must be inside the boundary before the boundary closes. If a dependency assumes connectivity anywhere in its call path, it is disqualified.
This sounds obvious and is routinely violated. The violation is almost never the obvious model API call — teams catch that. It is the transitive dependency that fetches a tokenizer file on first use, the telemetry library that buffers and retries, the framework that resolves a tool definition from a remote registry. The whole architecture has to be designed around the assumption that any external call is a defect.
The pattern
1. Vendor the harness
Do not depend on a framework you pull from a package index. Vendor the agent harness — the loop that plans, calls tools, and handles results — into your own repository as source you control. This is more work up front and it pays for itself the first time you need to certify exactly what the code does, patch it without a network, or prove to an accreditor that nothing in the loop reaches out. A vendored harness is a few thousand lines you can read, not a dependency tree you have to trust.
The same rule applies to every dependency: the entire artifact set — harness, libraries, model weights, tokenizer files, tool code — is assembled, pinned, and hashed on the connected side, then carried across as one reviewed bundle. Nothing resolves anything at runtime.
2. Redact PII locally, before anything else
In sensitive enclaves the inputs frequently contain names, identifiers, and other PII that should not flow into a model context unredacted, even a local one. The answer is a local named-entity-recognition model that runs as the first stage of the pipeline. It tags entities, replaces them with stable placeholders, and keeps the mapping in a controlled store so outputs can be rehydrated if and only if the consumer is authorized.
The point of doing this with a local NER model rather than a hosted service is that the redaction itself never leaves the boundary — the thing protecting the data does not become the thing leaking it. Small NER models are accurate enough for this and fast enough to run inline, which means redaction is not an optional step a user can skip; it is wired into the pipeline ahead of the model call.
3. Self-host the inference
Run the model inside the enclave. For lighter workloads and single-box deployments, Ollama is a clean way to serve a quantized open-weight model with a local API. For throughput — concurrent agents, batched requests, real duty cycles — vLLM gives you the serving performance to make the system usable rather than a curiosity. Either way the weights are part of the bundle carried in, the serving endpoint is on localhost, and there is no API key pointing at someone else's data center.
The model selection conversation changes here. You are not picking the absolute frontier model; you are picking the best open-weight model that fits the hardware in the rack and the accuracy bar of the task, validated on your eval suite. For a surprising number of federal tasks — extraction, classification, summarization, structured routing — a well-chosen mid-size open model clears the bar.
4. Package as a run-and-dump container
The deployment unit is a Docker image with everything baked in: harness, libraries, weights, NER model, tool code. It is built and scanned on the connected side, exported as a file, transferred across the boundary by whatever approved path the enclave uses, and loaded. At runtime it takes its inputs, does its work, and writes its outputs and its full trace to a mounted volume — then exits. Run and dump. No daemon reaching out, no background sync, no surprise.
This run-and-dump shape has a second benefit beyond network isolation: it is trivially auditable and reproducible. The same image, the same inputs, the same outputs, every time. That property is gold during accreditation.
Zero external calls, and how you prove it
Claiming zero external calls is not the same as having them. Prove it. The container runs with no network, or with egress denied at the host so any attempted call fails loudly and shows up in a log. Build a test that runs the full pipeline under a deny-all network policy and asserts the run completes — if anything in the stack secretly needed the network, this test fails on the connected side where you can still fix it, instead of in the enclave where you cannot.
We treat the no-egress test as a release gate, the same way we treat the eval suite. A green eval and a green isolation test together are the minimum to carry a new bundle across.
What you give up, and what you do not
You give up the frontier-model API and the convenience of pulling things at runtime. That is real, and for some tasks the accuracy gap matters — measure it on your evals rather than assuming. What you do not give up is capability. Agentic workflows, tool use, retrieval, structured output, and human-in-the-loop checkpoints all work the same inside the boundary as outside it. The harness does not care that the model is on localhost.
We have stood this pattern up for environments where the network genuinely ends — the same architecture the team is built around, with audit, redaction, and access control present from day one rather than bolted on. The disconnected enclave is not a special exception to good engineering. It is good engineering with the escape hatches removed.
If you have a classified or disconnected program that needs agents running with zero external calls, we have built this. Start a conversation, or have us train your team to own the pattern.