Running agents in air-gapped environments

Most agentic AI assumes an open door to the internet: a hosted model here, a third-party tool there, a stream of outbound calls no one thinks about until they stop. In defense and national-security work, that door is closed on purpose. The environment is air-gapped, the data is classified, and nothing leaves. Running governed agents there is not a matter of tightening a cloud deployment. It changes what the agents can reach and how they have to be built. Trunnion is designed to run in exactly that setting, on the same control plane it uses everywhere else.

What air-gapped means for agents

An air-gapped environment has no path to the public internet. For an agent, that rules out anything that depends on an outside service: hosted model APIs, external tool calls, remote logging, license servers that phone home, and cloud-hosted anything. If a workflow was built assuming those are always available, it simply will not run once the connection is gone, and it will fail in ways that are hard to diagnose because the missing piece is something the developer never had to think about.

That constraint touches every layer, from where the model runs to where the audit trail is stored. The models have to be local. The tools have to be internal. The record has to stay inside the boundary. The design has to assume disconnection from the start, not bolt it on later, because a system built for connectivity does not degrade gracefully when the network disappears; it stops.

The same control plane, disconnected

The value of one control plane is that it does not change shape when the network does. Trunnion runs the same governed platform in cloud, on-premise, and fully air-gapped environments. The model router points at models running on local hardware instead of hosted endpoints. The tool and integration layer connects to internal systems rather than external APIs. The governance and audit behave identically. A workflow proven in a connected pilot can move to a disconnected environment without being rebuilt, which matters because rebuilding for the target environment is exactly where secure AI projects tend to stall.

This is a deliberate contrast with the common pattern of a cloud product plus a separate, stripped-down on-premise edition that lags behind and behaves differently. When the disconnected deployment is the same platform rather than a lesser cousin, the controls you validated in the pilot are the controls that run in production, not an approximation of them.

Everything the agent touches has to be inside

In a connected setting, an agent’s reach extends quietly through every API it can call. Air-gapped, that reach is bounded by what lives inside the enclave, and that is a feature, not a limitation to work around. The model is one you host, so prompts and completions never traverse an outside network. The tools are the internal systems the mission actually uses, wired in through the same authorization layer rather than through public connectors. Retrieval runs against data already inside the boundary, under access control, so the agent’s context is drawn only from what it is cleared to see.

The result is that the agent is powerful within a fence you control completely. Nothing it does reaches for the open internet, because there is nothing out there to reach.

Identity and classification

In a classified setting, who is acting matters as much as what they are doing. Trunnion carries CAC/PIV identity traceability through a run, so every action ties back to a real, credentialed person rather than an anonymous service account. Data and actions carry their classification, and attribute-based access control decides what each agent may see and do at each level. Workflows run up to TS/SCI, with policy enforced per tenant, role, and classification rather than trusting the environment to keep things separate. The enclave provides one layer of separation; the platform provides another, so a misstep inside the boundary still meets a policy check rather than open access.

This is where a human-in-the-loop gate earns its place. Consequential actions pause for a named operator to approve, edit, or reject, so autonomy never quietly crosses a line that a person should have to sign for. In an environment where the cost of a wrong action is measured in more than dollars, having a credentialed human on the decisive moves is not overhead; it is the point.

Audit without the internet

Audit is often the quiet blocker for AI in secure environments, because the usual answer is a cloud logging service that an air-gapped network cannot reach. If the only way to record what an agent did is to ship the log off-site, then in an enclave you have no record at all, and no record means no approval to operate.

Trunnion keeps the audit inside the boundary. Every step is written to a SHA-512 hash-chained, tamper-evident record that lives where the workflow runs, with full reasoning traces and execution replay. Because each entry is linked to the one before it, altering a past entry breaks the chain and shows, so the trail holds up as evidence rather than serving as a log someone could quietly edit. A reviewer inside the enclave can reconstruct exactly what an agent did and why, and replay the sequence to watch the decision unfold, without anything ever leaving the network.

The operational realities

Disconnection changes how the system is maintained, and it is better to plan for that than to be surprised by it. Updates arrive through a controlled process rather than an automatic pull from the internet, so platform and model refreshes are deliberate, reviewed events. Model choice is bounded by what can be hosted on the available hardware, which is one more reason an LLM-agnostic router matters: as approved local models improve, the workflow can adopt them through configuration rather than a rebuild. The audit and governance keep working the entire time, because they never depended on an outside service to begin with. None of this is friction for its own sake; it is the shape of running serious AI where the network is closed on purpose.

From cloud pilot to disconnected deployment

A practical path is to prove the mission where iteration is easy, then move it to where it has to live. Scope the workflow, the data, the policy, and the deployment target. Compose the agents with ABAC and approval gates wired in from the start. Prove the run and validate the audit trail with a human in command. Then deploy into the on-premise or air-gapped environment on the same control plane. Because governance, identity, and audit are part of the platform rather than the network, the controls that held in the pilot still hold once the door is closed.

The reassurance in that sequence is that the disconnected deployment holds no surprises. You are not discovering in the enclave that a dependency phones home or that the audit needs a service you cannot reach. You proved the mission with the same controls it will run under, and closing the network changes where the models and tools live, not whether the governance works. That is what it takes to put autonomous agents to work in the places where the stakes, and the secrecy, are highest.