Factory Private
Federal Deployment
IL4 and IL5 AI deployment: define the boundary
September 18, 2026 - 2 minute read
IL4 and IL5 AI deployment starts with the information the workload handles and the system authorized to handle it. An impact level, a private network, and an airgap describe different requirements. Keep them separate when evaluating a coding agent.
The review must cover source code, prompts, model endpoints, connected tools, and operational evidence. Hosting the working copy inside an approved environment leaves the rest of that path to be assessed.
IL4 and IL5 AI deployment depends on categorization
Microsoft's IL4 guidance explains the DoD Cloud Computing Security Requirements Guide and its treatment of controlled unclassified information.
Its IL5 guidance describes CUI requiring greater protection than IL4 and national security systems within the stated categorization. It assigns the categorization decision to the responsible authorizing official.
These references explain the cloud impact-level distinction. They do not establish that an arbitrary AI application, model endpoint, or deployment is approved for the workload.
Record the responsible authority's decision before selecting tools. Include the permitted data classes, system boundary, services, and operating responsibilities in the evaluation.
Review IL4 and IL5 AI deployment end to end
A development task may read an internal repository and send selected context to an inference endpoint. Review that endpoint's operator and location, including any service behind a gateway.
Factory's data-flow documentation distinguishes local file access, model traffic, and telemetry. Apply those distinctions to the intended environment rather than assuming that local execution makes every data path local.
Check identity, package sources, source control, and collectors too. Each integration must stay within the approved configuration. A permitted model service does not authorize an unrelated public build dependency.
Use synthetic data to exercise the complete workflow. Observe destinations, preserve validation evidence, and verify that an unapproved test connection is rejected.
Interpret private-deployment claims narrowly
Factory's sovereign software development whitepaper describes support for IL4/IL5 environments through private and airgapped deployment arrangements. Treat that as a deployment capability statement, then request the evidence and scope applicable to the intended system.
It should not be restated as a blanket authorization for every Factory service. Factory FedRAMP separately states that authorization is in progress as of September 18, 2026.
Factory Private places the control plane in customer infrastructure. That placement determines ownership, while the responsible reviewers still need to approve the workload, configuration, model service, and operating controls.
Ask for a responsibility matrix covering patching, access reviews, logging, incident escalation, and recovery. Shared ownership needs an explicit handoff.
Validate disconnected requirements separately
If runtime internet connectivity is prohibited, assess the airgap build. It uses customer-configured models and skips Factory-bound services. The customer network enforces isolation.
Cloud-dependent functions such as Slack integration, session sharing, and hosted analytics are unavailable. Provide internal task intake, model access, package sources, and collectors for the workflow that will actually run.
Rehearse a task, an unavailable dependency, and an approved update in the isolated environment. Record how operators detect failure and restore the previous configuration.
The acceptance record should identify the workload decision, exact service scope, active configuration, and verification results. A general product claim is a starting point for that review, not its conclusion.
