On-prem AI development inside your security boundary

On-prem AI development becomes difficult when the source repository is private but the tools around it expect cloud access. A local agent can still depend on a hosted control plane, external inference, or a public package registry. Those dependencies need separate approval.

Consider a dependency update in an internal service. The current version builds from an approved mirror, but the replacement version has not reached that mirror. Validation then tries a public registry and fails. The team needs to supply the approved dependency before Droid can establish whether its patch works.

On-prem AI development has several data paths

The execution machine is where code is read, changed, and tested. The control plane coordinates work. The model endpoint processes context, while the collector stores approved operational evidence. Putting one component on-premises leaves the placement of the others undecided.

Factory's deployment patterns distinguish cloud-managed, hybrid, and fully airgapped operation. A connected on-premises environment can permit selected external services. An airgapped workflow must run without public-internet or Factory connectivity at runtime, including during installation and failure recovery.

Factory Private places a customer-owned control plane in a VPC or on-premises environment. That arrangement supports customer control over infrastructure and updates. The deployment still needs approved inference, tools, and network routes.

Make on-prem AI development reproducible

Before adding an agent, build and test the repository in the intended environment. For the dependency update, verify that both library versions and their build tools are available from approved sources. Run the same test command against the original revision so a broken environment cannot be mistaken for a regression in the patch.

Use the existing artifact process to distribute approved versions. If an update introduces a public download during validation, either supply an internal source or explicitly review that connection. Avoid temporary network exceptions that quietly become production dependencies.

Factory's data-flow documentation explains that file reads and writes remain local, while file content used for inference follows the configured model path. Inspect the service behind any gateway rather than relying on its private hostname.

Bound access before increasing autonomy

Give the initial workflow a disposable working copy and the permissions needed to validate a change. Keep standing production credentials and unrelated repositories outside its reach.

Factory's Agent Safety & Controls includes command restrictions, hooks, and filesystem and network sandboxing. Use those controls with existing infrastructure policy. Keep source-control review requirements in place for the resulting patch.

Test a harmless denied operation alongside a successful task. Confirm that a write outside the workspace or a connection to an unapproved test destination fails. Record the enforcement point, not just the model's explanation.

Assign the operating work

Customer-controlled deployment needs owners for releases, model availability, certificates, and recovery. Record who promotes an update and how the previous configuration is restored. Test recovery in a disposable environment before depending on it during an incident.

The dependency update is ready for review when another engineer can rebuild it using the recorded artifact versions and permitted endpoints. Keep the denied-operation results with the test output. A passing patch that depended on an undocumented network exception has not validated the intended on-premises workflow.

White Paper

Read the Sovereign Software Development White Paper

A deployment and governance framework for the world's most important systems, from managed to air-gapped.

Read the white paper

Further reading

• Self-hosted AI agents and control-plane ownership
• Air-gapped AI development
• Factory Private launch