Factory Private architecture inside your boundary

Factory Private puts the control plane, the service that coordinates development sessions, in customer infrastructure. The remaining architecture decisions concern where model requests go, what the execution identity can do, and what telemetry retains.

For example, a model gateway can have a private address while forwarding code context to an external provider. Customer hosting of the control plane leaves that downstream route unchanged. Following one request through a small dependency update makes the separate boundaries visible.

Factory Private architecture separates ownership decisions

Suppose Droid is asked to replace a deprecated library in an internal service. The working copy and build run on a customer-managed machine. The control plane coordinates the session, the model endpoint processes selected context, and a collector receives the telemetry the organization enables.

Factory's deployment patterns documentation distinguishes cloud-managed, hybrid, and fully airgapped operation. Droid can run on developer machines, CI runners, VMs, or containers. The pattern determines which services remain reachable and where model and telemetry traffic terminates.

The task also needs the old and replacement library versions from an approved package source. Map that connection alongside the model route. A public download during installation crosses the boundary even if every source file stays on the internal machine. Review configuration changes that introduce a new route as changes to the architecture.

Model placement determines where context travels

Local file access and local inference are separate properties. Factory's data-flow documentation explains that Droid reads and edits files on the machine where it runs. File contents used as model context travel through the configured inference path.

When Droid reads the deprecated API's call sites, the relevant code may become model context. Follow the request beyond the gateway to the actual model service and its region. The gateway's logs and the provider's retention settings both affect where that context persists.

Factory supports custom model endpoints through BYOK. That lets an organization choose a permitted inference destination, but the endpoint's privacy guarantees still come from its configuration and the relevant provider agreement. Customer ownership of the control plane does not automatically establish the model provider's retention policy.

Run the example first with non-sensitive code. Observe destination hosts and gateway records during normal inference, retries, and failures. If a failed request triggers another provider, that fallback needs the same approval as the primary destination.

If the deployment requires entirely internal inference, verify that every permitted model resolves to an in-network service. Document what happens when that service is unavailable. An operational fallback must stay within the same approved boundary.

Factory Private architecture needs independent controls

The dependency update needs permission to edit the working copy and run its tests. It does not need authority to deploy the service or change a shared production database. Keep those credentials outside the execution environment.

Factory's Agent Safety & Controls describes command permission rules, hooks, sandboxing, and Droid Shield. Current rules distinguish allow, ask, and block. Legacy command denylists ask for confirmation, while blocklists prohibit execution without an approval path. The legacy lists remain supported but are deprecated in favor of permission rules.

A rule allowing the test command is still separate from a sandbox restriction on reachable files and hosts. Use least-privilege infrastructure credentials as well as agent controls. Let existing source-control protections govern whether the resulting patch reaches a protected branch.

Network controls deserve the same specificity. Permit the model endpoint, internal Git service, required package sources, and approved collectors. A general route to the corporate network may expose systems unrelated to the task. Restricting internet access alone leaves that internal exposure intact.

Test policy with harmless negative cases. Attempt a write outside the permitted workspace and a connection to an unapproved test destination. Record whether the operating system, sandbox, or application policy blocked the attempt. A reviewer should be able to identify the enforcement point without relying on the model's explanation of its own behavior.

Treat observability as part of the data boundary

If the replacement library fails its tests, tool duration and CI output may be enough to diagnose the problem. Retaining the entire conversation introduces a different data category, potentially including source fragments and command arguments.

Factory's telemetry documentation describes customer-owned OpenTelemetry export. Metrics are the default customer export. Message content can be exported separately as trace spans to a customer-configured collector. The collector is therefore a deployment component with its own access controls, storage policy, and operational owner.

The customer metric catalog does not include token and cost data. Use the relevant hosted analytics, provider, gateway, or infrastructure records for those measurements. CI establishes which compatibility tests ran, and source control identifies the approved revision. Activity counts alone establish neither.

Where content export is justified, approve the collector and its downstream destinations for those data classes. Raw message content has no automatic redaction. A customer-operated collector can still forward it externally, just as the model gateway can.

Also test the absence of data. A healthy dashboard can conceal a runner that never received the collector configuration. Confirm coverage for each execution environment and establish who investigates gaps.

Reproduce the request after an update

Factory Private leaves upgrade timing under customer control. Keep the dependency-update task and its known starting revision as a regression check for changes to the control plane, model route, or execution image. Re-run the same compatibility tests after an update and compare the observed destinations and policy decisions.

The recovery procedure should restore the approved artifacts and configuration in a disposable environment. Confirm that the package mirror, model service, and collector reconnect without a temporary public-network exception. This checks the architecture the team intends to operate, rather than just whether a service starts.

Finish the example with a reviewed patch, compatibility-test output, and a record of the actual inference and telemetry paths. If support needs additional diagnostics, approve their release separately. The boundary holds only when normal work, failures, and recovery follow the same data-handling decisions.

Further reading

• Factory Managed vs Private deployment choices
• Preparing air-gapped AI development
• Custom model configuration