Factory Private
Model Governance
Self-hosted models for confidential source code
September 18, 2026 - 2 minute read
Self-hosted models can keep inference within an approved environment, but only if the configured path actually ends there. A gateway with a private hostname may still forward requests to an external service.
Review the model route, credentials, logs, and fallback behavior together. Then test the complete development task before introducing confidential source code.
Self-hosted models need an explicit route
Factory's custom-model documentation describes connecting the Droid CLI and desktop app to customer-selected endpoints. These configurations are read from local settings and do not appear in the hosted web or mobile platforms.
Record the model identifier, base URL, compatible provider interface, and downstream service. Include the operator and retention policy. Review any fallback that can change where a request is processed.
Factory's data-flow documentation assigns the privacy guarantees of custom endpoints to those systems and the customer's agreements. Selecting a model does not add a retention guarantee to the gateway.
Keep the approved route with the model catalog. Repointing an endpoint can change the data boundary even when developers see the same display name.
Govern self-hosted models through policy
A default model is a starting preference. The organization also needs a policy defining which destinations are allowed for the workload.
Factory's Enterprise Controls separates hard model policy from session defaults. Use that distinction to keep developer choices within the approved catalog.
Test an unapproved endpoint as well as an approved one. Check the effective policy on workstations and automation runners, including any differences in proxy or certificate configuration.
Record who may approve an exception and when it expires. Temporary model experiments should not quietly become permanent routes for sensitive code.
Use a manageable credential path
Factory supports local environment-variable references for custom-model keys. Organization-managed models can use keyless endpoints or apiKeyHelper to obtain credentials at request time. New organization-distributed models cannot use static apiKey values.
The credential command runs only from trusted organization-managed settings. Treat it and its dependencies as managed code, with a clear owner and approved access scope.
Test expiry, revocation, and identity-service failure. Confirm that the execution account can obtain the intended credential and that failures do not expose credential material in logs.
Avoid placing shared keys in repositories or broadly readable configuration. Distribute secrets through the existing managed-environment or secret-delivery process.
Validate more than a chat response
Use a disposable repository with deterministic tests. Exercise file reads, tool calls, edits, validation, and correction of a failed check. A short response confirms connectivity but says little about a full development workflow.
Record the model version and gateway configuration. Keep those conditions stable when comparing endpoints so the result is interpretable.
For disconnected operation, Factory's airgap build requires a customer-configured model. Factory Router and managed models are unavailable. An outage must pause work or use another approved internal route.
Track accepted changes and reviewer corrections alongside runtime behavior. Maintain a small evaluation set and rerun it before promoting a model or gateway change.
The useful result is a model service that fits the approved boundary and reliably supports the team's task, with an operating owner who can diagnose and recover failures.
