September 2026 Summaries

On-premises AI development for private repositories requires evaluating every dependency in the workflow, including the execution environment, control plane, model endpoint, package sources, operational-data collection, and permitted network routes. Factory describes cloud-managed, hybrid, and fully air-gapped deployment patterns, with Factory Private offering a customer-controlled control plane in a VPC or on-premises environment while still requiring approved inference services, tools, and connectivity. Teams are advised to first make repository builds reproducible using internally approved artifacts, avoid unreviewed public downloads, and verify where file content travels when used for model inference. Initial agent access should be narrowly scoped through disposable workspaces, limited permissions, command and network restrictions, sandboxing, and continued source-control review, with tests confirming that prohibited actions fail. Successful operation also depends on clear ownership of releases, model availability, certificates, recovery procedures, and measurable results from bounded maintenance tasks, with artifact versions, endpoint settings, policy tests, and reviewed changes recorded before expanding use to additional repositories.

Factory’s guidance on AI agent telemetry emphasizes collecting only the operational evidence needed, distinguishing lower-sensitivity activity metrics from potentially sensitive raw content and approval records. Metrics-only customer exports are enabled by default, while optional content spans may include prompts, files, commands, and tool outputs without automatic redaction, requiring approved collectors and centralized policies. Organizations are advised to secure collector credentials, verify configurations on actual execution accounts, test export failures, and review downstream storage, access, and retention practices. The guidance also recommends deliberately selecting identity granularity, validating exported schemas with non-sensitive samples, and accounting for air-gapped environments where no hosted fallback exists. To assess outcomes rather than mere activity, telemetry should be combined with CI results, source-control history, and reviewer approvals, while cost data should come from appropriate inference or infrastructure sources. Pilot programs should use stable definitions for measures such as accepted changes, validation failures, corrections, and operator intervention to avoid mistaking measurement changes for productivity gains.

Self-hosted AI models can help keep confidential source code within approved environments, but organizations must verify the complete inference route, including gateways, downstream services, credentials, logs, retention policies, and fallback behavior. Factory recommends documenting model identifiers, endpoints, providers, operators, and data-handling policies, while using enterprise controls to limit developers to approved model destinations rather than relying only on default selections. Credentials should be managed through secure, organization-controlled mechanisms such as keyless endpoints or runtime helpers, with testing for expiration, revocation, identity failures, and log exposure. Teams should validate models using realistic development workflows involving file access, tool calls, edits, tests, and error correction rather than simple chat responses, and should maintain repeatable evaluations when changing models or gateways. In air-gapped environments, customer-configured internal models are required, while outages should halt work or move it to another approved internal route.

SOC 2 evaluation for AI coding tools should focus on whether a report’s defined system scope actually covers the selected control plane, model services, integrations, and workflow rather than treating a security badge as proof of compliance. Reviews should examine report periods, exceptions, customer responsibilities, and the distinction between an auditor’s attestation and real-world configuration choices such as model routing, regional deployment, repository permissions, execution identities, and network controls. Organizations should map end-to-end data flows, including local file access, prompts, model context, telemetry, session records, diagnostics, and error paths, while separately assessing vendor-operated and customer-operated components. Useful evidence includes current model policies, retention settings, sandboxing and approval controls, and bounded tests conducted in disposable environments, with sensitive session content collected only when necessary. The resulting acceptance record should identify the reviewed service, configuration, unresolved risks, responsible owners, and reevaluation triggers, since changes in model routes, integrations, or deployment ownership can alter the compliance posture.

FedRAMP AI deployment should be evaluated based on the exact named service, its current authorization status, and the full architecture of the proposed workflow rather than assumptions based on product families, GovCloud hosting, or vendor claims. As of September 18, 2026, Factory describes its FedRAMP control-plane and analytics hosting in GovCloud as authorization in progress, so organizations should obtain current, dated evidence and involve responsible agency reviewers before committing to deployment. Reviews should cover dependencies such as repositories, model services, identity systems, telemetry, scanners, and ticketing integrations, while assigning owners to unresolved questions and distinguishing commercial, private, federal, connected-cloud, and air-gapped configurations. Air-gapped deployments require customer-managed internal services and lack certain cloud-dependent capabilities, creating additional responsibilities for releases, certificates, model availability, incident response, and recovery. Organizations should validate a bounded, approved workflow with permitted data, document permissions, destinations, tests, audit evidence, and review gates, test both successful and failure scenarios, and preserve the authority’s decision for the precise production configuration rather than a broader product category.

Factory’s air-gapped deployment guidance argues that offline AI development must be validated as a complete workflow, since tools such as test runners, dependency resolvers, model gateways, and plugins may otherwise attempt external connections. Its enterprise airgap build of Droid disables Factory services including sign-in, updates, telemetry, synchronization, hosted models, and routing, requiring organizations to configure and test approved internal model endpoints using representative repositories and realistic development tasks. Network and infrastructure controls should independently restrict all destinations and local access, while approved internal artifact processes must supply source code, runtimes, packages, tools, fixtures, policies, and credentials. Organizations are advised to test model failures and credential expiry, account for unavailable cloud-based collaboration and analytics features, preserve evidence through internal source control and validation records, and rehearse updates and rollbacks. A successful pilot should demonstrate that teams can consistently build, secure, review, and recover within the offline environment rather than merely complete a one-time isolated test.

Private AI security remediation should focus on reducing verified risks through narrowly scoped, reviewable changes rather than generating large volumes of unvalidated findings or patches. Effective workflows begin by confirming reachability, exploitability, existing controls, and false positives, while using synthetic data and disposable environments instead of live systems or real credentials. Organizations should limit repository access, keep production credentials out of task environments, apply sandboxing and secret-scanning controls, and avoid granting deployment authority solely because an AI agent can prepare a patch. Each remediation should include evidence, focused code changes, regression testing for the unsafe behavior, confirmation that legitimate behavior still works, and transparent reporting of any tests that could not run. Reviewers should independently inspect changed data paths and possible bypasses, since passing tests may not cover every entry point. Success should be measured through validated findings, accepted fixes, false positives, and review burden, with records documenting why a finding was real, how the patch addressed it, which checks were performed, and who approved the result.

AI code data residency depends on the full path of source files, prompts, model inference, session records, telemetry, integrations, logs, and diagnostic outputs rather than solely on where a Git repository is hosted. Factory states that Droid works on files locally and routes inference context through the configured model path, while its cloud-managed, hybrid, and airgapped options differ in their data boundaries; organizations must also verify whether gateways, proxies, or fallback routes send data to external providers. Model hosting and control-plane placement are separate considerations, requiring review of session handling, administrative records, support diagnostics, retention, and deletion procedures. Telemetry, MCP services, hooks, and test tools can create additional data destinations, particularly during failures, and Factory notes that content logging is disabled by default but sends unredacted raw content to a customer-configured collector when enabled. The recommended approach is to use representative synthetic tasks to observe and document every data destination, operator, purpose, retention policy, and enforcement point, repeating the assessment whenever models, collectors, integrations, or execution environments change.

Deploying AI coding agents in IL4 and IL5 environments requires an end-to-end assessment based on the data classification, authorized system boundary, and responsible authorizing official’s decision, rather than relying on labels such as private network or airgapped deployment. Evaluations should account for source code, prompts, model endpoints, connected tools, telemetry, identity systems, package sources, source control, and operational controls, with each integration remaining within the approved configuration. Factory describes support for private, sovereign, and airgapped arrangements, but these statements represent deployment capabilities rather than blanket authorization for specific workloads or services; as of September 18, 2026, its FedRAMP authorization was still in progress. Private deployments place the control plane in customer infrastructure, while airgapped deployments use customer-configured models and exclude Factory-bound and cloud-dependent functions such as Slack integration, session sharing, and hosted analytics. Organizations should validate complete workflows using synthetic data, document data flows and responsibilities, test rejected connections and failure recovery, and maintain acceptance records identifying the workload decision, service scope, active configuration, and verification evidence.

Self-hosted AI agents require enterprises to evaluate not only model placement but also ownership of orchestration, session handling, inference, analytics, connected tools, maintenance, and support access. Factory presents Managed as a hosted control-plane option and Private as a customer-hosted alternative, with deployment choices determined by specific requirements for data boundaries, access controls, and operational responsibility rather than by labels alone. Organizations considering private deployments should map data flows, gateways, retries, diagnostics, and dependencies; establish processes for releases, recovery, certificate management, model validation, and incident response; and test complete workflows rather than isolated model responses. Airgapped deployments impose additional restrictions by eliminating runtime connectivity and disabling cloud-dependent features, while GovCloud hosting and customer-operated infrastructure do not by themselves demonstrate completed authorization, particularly as Factory’s FedRAMP status was described as in progress. The recommended approach is to compare options through bounded tasks, approved permissions, known test suites, output quality, review effort, and the organization’s ability to operate and validate the chosen system.