# Air-gapped AI development: run coding agents offline > Air-gapped AI development needs an internal model, offline artifacts, and enforced network isolation. See what the Factory airgap build skips and how to test it. URL: https://factory.com/articles/air-gapped-ai-development Published: 2026-09-18 Updated: 2026-10-23 Air-gapped AI development means running coding agents, their models, and their supporting tools on a network with no runtime connection to outside services. It fails when an apparently local workflow reaches for an unavailable service. A test runner may download a browser. A dependency resolver may query a public registry. A model gateway may forward requests outside the network. The acceptance test must cover a complete development task, including its supporting tools. Starting the agent offline is only the beginning. ## Air-gapped AI development needs an internal model Factory provides a dedicated enterprise airgap build of Droid. Its [deployment contract](https://docs.factory.com/enterprise/airgapped-deployment) states that it skips sign-in, update checks, session synchronization, crash reporting, and Factory telemetry. The build uses customer-configured models only. Factory-managed models and Factory Router are unavailable, and Droid refuses to start a turn without a custom model. Configure the approved internal endpoint and test it from the actual workstation or runner. Use a representative repository with known tests. A successful chat response does not prove that the model endpoint handles tool calls, longer context, or repeated interactions correctly. ## Enforce air-gapped AI development outside the model Airgap Mode provides offline behavior. The network supplies the isolation boundary. Factory's published enforcement table makes that division explicit. ![Factory airgap documentation comparing customer network isolation, sandbox network policy, and cooperative Airgap Mode.](https://factory.com/articles/private-enterprise/airgap-enforcement.png) Screenshot of the linked airgap documentation, captured September 18, 2026. Review every configured destination, including model endpoints, Git remotes, MCP servers, collectors, and plugin sources. Commands can create connections too. Use infrastructure and sandbox rules to constrain them independently of the model's instructions. Test a harmless request to an unapproved destination and record the rejection. Also restrict local access. An isolated network may still contain credentials and sensitive files unrelated to the assigned task. ## Import a usable development environment Prepare the source, runtime, packages, build tools, and test fixtures through the approved artifact process. First reproduce the task without the agent. That separates environment problems from problems in a proposed patch. Factory's [BYOK reference](https://docs.factory.com/model-independence/byok) describes custom-model configuration. Use the compatible provider interface and approved credential path. Include model-service failure and credential expiry in the acceptance test. Distribute policy through system-managed settings or an approved internal endpoint. Check that the actual execution account receives it. A configuration file on an administrator's machine is insufficient evidence for a fleet. Keep internal documentation and dependencies current together. Instructions that name unavailable package versions can make a disconnected workflow impossible even when the network configuration is correct. ## Plan collaboration, evidence, and updates The offline feature set changes the workflow. Slack integration, cloud session sharing, built-in web lookup, and Factory-hosted analytics are unavailable. Local capabilities such as Missions, hooks, installed skills, and configured MCP servers remain usable when their dependencies are available internally. Factory's [telemetry documentation](https://docs.factory.com/enterprise/telemetry) specifies customer-only export in an airgap. Without a usable customer collector, the pipeline does not run. Use internal source-control and validation records to preserve the reviewed change. Rehearse an update and rollback in a disposable environment. Record the approved artifacts, active policy, model configuration, and validation result. Then restore the previous setup and confirm that operators can repeat the task. A useful pilot proves the offline lifecycle, not only an isolated demonstration. Expand after the team can reproduce the build, enforce the boundary, review the output, and recover from a failed dependency. ## Frequently asked questions ### What is air-gapped AI development? It means running coding agents, their models, and their supporting tools on a network with no runtime connection to outside services. Inference, packages, and artifacts all have to be available internally. ### What does the Factory airgap build skip? Its deployment contract states that it skips sign-in, update checks, session synchronization, crash reporting, and Factory telemetry. It uses customer-configured models only. ### Does Airgap Mode isolate the network? No. Airgap Mode provides offline behavior, and the network supplies the isolation boundary. Use infrastructure and sandbox rules to constrain connections independently of the model. ### Which Factory features are unavailable offline? Slack integration, cloud session sharing, built-in web lookup, and Factory-hosted analytics are unavailable. Missions, hooks, installed skills, and configured MCP servers remain usable when their dependencies are available internally. ### How do you validate an air-gapped setup? Run a complete development task with its supporting tools, including package installs and tests, against the internal model endpoint. Also test a harmless request to an unapproved destination and record the rejection. ## Further reading - [On-prem AI development](https://factory.com/articles/on-prem-ai-development) - [Airgapped deployment requirements](https://docs.factory.com/enterprise/airgapped-deployment) - [Enterprise Controls](https://docs.factory.com/enterprise/hierarchical-settings-and-org-control)