# On-prem AI development inside your security boundary

> On-prem AI development needs more than a local agent. Place the control plane, model endpoint, build tools, and telemetry inside the approved boundary.

URL: https://factory.com/articles/on-prem-ai-development
Published: 2026-09-18
Updated: 2026-09-18

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](https://docs.factory.com/enterprise/network-and-deployment) 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](https://factory.com/deployment/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](https://docs.factory.com/enterprise/privacy-and-data-flows) 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](https://docs.factory.com/enterprise/llm-safety-and-agent-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.

## Frequently asked questions

### Is a local agent enough for on-prem AI development?

No. A local agent can still depend on a hosted control plane, external inference, or a public package registry. Each of those dependencies needs separate approval.

### What does Factory Private place on premises?

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

### What does an airgapped workflow require?

It must run without public-internet or Factory connectivity at runtime, including during installation and failure recovery. Approved artifacts and internal model endpoints have to be in place first.

### How do you prove access limits work?

Test a harmless denied operation alongside a successful task, such as a write outside the workspace or a connection to an unapproved destination, and record the enforcement point.

## Further reading

- [Self-hosted AI agents and control-plane ownership](https://factory.com/articles/self-hosted-ai-agents)
- [Air-gapped AI development](https://factory.com/articles/air-gapped-ai-development)
- [Factory Private launch](https://factory.com/news/factory-private)