Air-Gapped Automation: What Actually Has to Run Locally?

Air-gapped automation means the control plane, execution runtime and every service needed by a workflow are available inside a disconnected environment. Installation inside the enclave is not enough. A representative workflow must be able to start, authenticate, retrieve secrets, run integrations and code, call any required model, complete approval, write its result and retain evidence without relying on an outbound route.

That is the direct architectural test: disable outbound connectivity and complete a real workflow from trigger to recorded outcome. If execution stops because a licence must be checked, an external control plane must issue instructions, a model API must answer, telemetry must be delivered or a package must be fetched, the installation is local but the operating dependency is not.

This distinction is not an argument against cloud services. Connected environments can be appropriate for many workloads, and a private or sovereign cloud can sit inside the organisation's controlled estate. Air-gapped environments have a narrower condition: runtime operation must not assume connectivity that the enclave does not provide. The air-gapped deployment model describes how Nexus applies that condition in practice.

Hidden dependencies often appear outside the central architecture diagram. A user signs in through a remote identity service. A connector image pulls a supporting package on first use. A model endpoint sits behind a public API. A dashboard sends operational telemetry to a vendor service. Each may be acceptable in a connected deployment. Each becomes a point of failure when the same design is placed behind a closed boundary.

The boundary needs more than a workflow engine. It needs the complete operating chain required to turn an event into a governed result. Reviewing these dependencies as six local capabilities makes omissions easier to find before deployment.

Control plane and execution runtime

Workflow definitions, scheduling, orchestration and execution must remain available inside the enclave. A local worker attached to a vendor-operated control plane is not sufficient, because the run can still depend on instructions or state held outside. Nexus places the platform and its execution plane in the customer environment, as described in deployment options.

Identity, authentication and role control

Authentication, role resolution and approval attribution need a directory or identity path the enclave can reach. If sign-in or group membership must be resolved through an external vendor service, operators may lose access when disconnected. The local design should cover people, service identities and the roles allowed to edit, run or approve work.

Secrets and credentials

Connectors and code steps need credentials for the systems they call. Those credentials should be resolved from vault-backed storage inside the boundary rather than embedded in workflow definitions or retrieved from an internet service. Rotation, recovery and access policy then remain under the enclave operator's control.

Model endpoints

Any workflow that uses AI needs a locally reachable inference endpoint and the model artefacts required to operate it. A model step cannot be considered disconnected if its prompts still cross the boundary to an external API. Model registration and version selection also need to work locally so the execution record can identify what produced an output.

Connectors, libraries and code runtimes

Connector packages, protocol support, code runtimes and required libraries must be present at execution time. A step that downloads a package on demand introduces a hidden outbound dependency. The design should inventory what each workflow calls and ensure approved versions are already available through internal repositories or the imported artefact set.

Evidence, history and approvals

The workflow is incomplete if its outcome cannot be recorded. Execution history, approval decisions, workflow versions and relevant inputs and outputs need local storage governed by the organisation's access and retention policy. This keeps the operating record available even when no external observability or reporting service can be reached.

Air-gapped AI inference requires a model endpoint inside the controlled estate. Nexus workflows can call self-hosted endpoints, allowing prompts, retrieved context and outputs to remain inside the environment. Core inference therefore does not require an external model API. The organisation chooses and operates the endpoint that fits its boundary and workload.

The model itself should be treated as a governed artefact. Its identity and version need to be known, its import needs to follow change control, and its use should be attributable to a particular workflow run. A new model version is not merely a file replacement when it may change how a workflow interprets content or recommends an action.

Self-hosted AI is not mandatory for every enterprise workload. Connected workloads may intentionally use an external service under an approved architecture. The narrower point is that an air-gapped workflow cannot depend on that service. Sovereign AI explains how local inference operates as one governed step among deterministic rules, code and human review.

Removing runtime dependence on an external vendor also moves operational authority into the enclave. That is the purpose of the design, but it requires named ownership. Platform, connector and model artefacts need a defined offline update path, from preparation and transfer through verification, testing and promotion.

Capacity planning also becomes local. Workflow concurrency, storage growth and any inference demand have to fit the infrastructure available inside the boundary. Endpoint availability, backup and recovery, and the health of internal registries or repositories belong to the operating model selected by the customer.

Imported artefacts should pass through change control because import is a governed event. Teams need to know which version entered the enclave, who approved it, how integrity was checked and when it became active. The exact transfer mechanism follows the organisation's established process. Nexus does not require one prescribed method or claim a universal update cadence.

Start with event sources already available inside the boundary. Local schedules, database events and monitored file locations can initiate work without an internet path. File-based handoffs can also be appropriate at a controlled boundary when the operating process already governs how files enter and leave.

Exception paths deserve the same dependency review as the happy path. An error branch that sends only an external email or posts to an internet service may disappear when it is needed most. Use an internal work queue, local notification route or review interface that remains available inside the enclave. Human approval can occur there with the relevant context attached, then resume the same workflow run.

Outbound integration is not forbidden as a matter of principle. Some architectures include an approved cross-boundary path, gateway or transfer process for selected exchanges. When that exists, describe it explicitly as part of customer configuration. Do not confuse an intentionally configured business path with a vendor connection required for the platform itself to function.

Many organisations do not have one uniform boundary. They operate a combination of on-premises systems, private cloud, sovereign cloud and one or more disconnected enclaves. Different workloads may therefore need different execution locations even when they follow the same governance model.

The useful design unit is the workflow and its dependencies. Place execution where the required systems, identity, secrets and evidence can remain under the intended control. Then identify any exchange that crosses a boundary and apply the organisation's approved mechanism to that exchange. Physical location alone does not determine sovereignty, and cloud is not inherently outside a sovereign operating model.

This is why the six control surfaces of sovereignty remain useful across every topology. Execution, data, models, identity, secrets and evidence can be tested for ownership and dependency whether the workload runs in a data centre, a controlled cloud estate or a disconnected network.

A disconnected environment still needs a defensible account of what happened. The execution record can connect the initiating event, actor, workflow version, relevant inputs, approval decision and final outcome. When AI is used, the model version and its step output can be retained with the same run, subject to local access and retention policy.

That record helps teams evidence their controls during internal review, procurement assurance or an accreditation process. It does not make the deployment accredited, certified or approved for a classification. Those conclusions belong to the responsible authority and depend on the complete environment, operating procedures and intended use, not the automation platform alone.

Local evidence is also operationally useful. It lets an operator trace an exception without assembling records from an unavailable external service. Governance and audit describes how history, versions and attributed approvals stay connected to the execution they affected.

Use these questions with architecture, security, operations and procurement teams. Ask for a demonstrated workflow where possible, because an installation diagram does not expose every runtime dependency.

1. 01

   Can a representative workflow complete with all outbound routes blocked?

   Test the complete run, including identity, secrets, model inference, connector execution, approval and evidence capture.

2. 02

   Where do the control plane and execution runtime run?

   Confirm that definitions, scheduling and execution remain available inside the enclave rather than depending on a remote service.

3. 03

   Does any licence validation occur at runtime?

   A periodic call to an external licensing service can stop operation even when every business system is local.

4. 04

   Can authentication and authorisation work without vendor connectivity?

   Users, service identities, roles and approval attribution need a locally reachable identity path.

5. 05

   Can AI inference run locally?

   If the workflow uses AI, confirm that its model endpoint and required model artefacts are available inside the boundary.

6. 06

   Are required libraries, connectors and code runtimes already present?

   Execution should not pause to fetch a package, image or dependency from the public internet.

7. 07

   Where are secrets stored and resolved?

   Credentials must remain available through vault-backed storage inside the enclave, with local access and rotation controls.

8. 08

   Where is the execution evidence retained?

   Confirm that history, approvals, versions, inputs and outcomes are written to storage governed inside the environment.

9. 09

   How are approved updates imported offline?

   Document who prepares, transfers, verifies and promotes platform, connector and model artefacts.

10. 10

    What happens to exceptions if external alerting is unavailable?

    Define an internal queue, local notification path or review process that does not assume internet access.