Factory Private
Compliance
SOC 2 for AI coding tools: evidence to request
September 18, 2026 - 2 minute read
SOC 2 for AI coding tools starts with the system described in the report. A security badge does not tell an evaluator whether the proposed control plane, model service, and connected tools fall within that scope.
A coding workflow also creates customer-side responsibilities. Repository permissions, execution environments, and the information included in model context must be reviewed alongside the vendor's evidence.
SOC 2 for AI coding tools is a scope review
SOC 2 reports examine controls at a service organization. Microsoft's SOC 2 Type 2 overview, grounded in AICPA standards, describes the auditor's assessment of the system description, control design, and operating effectiveness over a specified period.
Ask for the report covering the service you intend to use. Check the period, scope, exceptions, and applicable customer responsibilities. Have the appropriate reviewer interpret how those findings affect the proposed workflow.
Distinguish attestation from product behavior. A report does not establish that a particular model endpoint uses the required region or that a customer's runner has appropriate permissions. Those are configuration and deployment questions.
Review SOC 2 for AI coding tools alongside data flows
Trace the task through local file access, inference, session handling, and telemetry. Identify the operator of each service and the data it receives.
Factory's compliance documentation lists SOC 2 Type II within its security program and directs reviewers to its Trust Center for current materials. Use those materials to confirm the scope relevant to the selected offering.
Its data-flow documentation separately explains that Droid reads and edits local files while model context travels to configured endpoints. An assessment of Factory's service should not be extended automatically to a customer-operated gateway or another provider.
Record where prompts, test output, session records, and support diagnostics persist. Apply the same review to error paths, which may contain more detail than a successful run.
Ask for operational evidence
Require evidence that the customer environment applies its approved controls. A useful review can include the active model policy, execution identity, repository permissions, network restrictions, and retention configuration.
Factory's Agent Safety & Controls documents command blocklists, approval-based denylists, hooks, and sandboxing. Test the settings relevant to the workload instead of assuming that their availability means they are enabled.
Run a bounded task in a disposable environment. Preserve the resulting diff, test output, and reviewer approval. Add harmless negative tests for prohibited file access or network destinations.
Keep the evidence collection proportionate. Full session content may contain sensitive code or credentials, so do not enable it merely to make the audit package larger.
Keep the acceptance record current
Record the reviewed service, report period, deployment configuration, and unresolved conditions. Assign owners for follow-up items and define when the evaluation must be repeated.
A changed model route, new integration, or move from a managed service to customer infrastructure can alter the reviewed system. Revisit the relevant controls when those changes occur.
Treat private deployment as an ownership decision rather than an automatic compliance result. Customer-controlled infrastructure brings its own configuration, monitoring, and recovery obligations.
The useful outcome is a decision supported by current evidence. Reviewers should be able to connect the report's scope to the actual workflow and explain which controls remain the customer's responsibility.
