Factory

Factory Private

Compliance

SOC 2 for AI coding tools: evidence to request

September 18, 2026 - 2 minute read

SOC 2 is an assessment of controls at a service organization. For an AI coding tool, the report concerns the described service and its controls. A vendor's badge does not automatically cover a customer-managed runner, an internal model gateway, or every integration used by the engineering team.

Security and procurement reviewers need to connect the actual deployment to the report's scope, examination period, findings, and customer responsibilities. That comparison determines which evidence the vendor supplies and which controls the customer must demonstrate separately.

SOC 2 for AI coding tools is a scope review

The AICPA's SOC suite of services establishes the framework for these reports. A Type II report addresses control design and operating effectiveness over an examination period. That period matters because a report about an earlier system cannot settle every question about a newly introduced service or deployment.

Start with the system description and confirm that it covers the offering being purchased. Then examine the auditor's opinion and test results. Exceptions can identify controls that did not operate as described, so the reviewer needs to understand their effect on the proposed workload rather than treating the report as a binary badge.

Customer responsibilities identify controls the service expects the customer to perform. For a coding workflow, those may intersect with account administration, access review, and protection of the execution environment. Map the report's actual requirements to the customer's procedures instead of assuming that purchasing the service completes them.

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.

Assemble evidence for the deployment being approved

Alongside the report, collect the applicable service terms, model-provider arrangements, data-flow diagram, and retention configuration. Identify which party operates each service and how the customer's control obligations are met. The review should make a customer gateway visible rather than silently treating it as part of the vendor's assessed system.

Resolve questions about exclusions, report currency, and exceptions with the security reviewer and vendor. Record any approval conditions and the evidence needed to close them. A working demonstration of the coding tool cannot substitute for those answers.

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.

Security approval should identify the covered service, relevant report findings, customer controls, and unresolved conditions. Procurement also needs the corresponding contractual commitments. Both teams should be able to explain why those materials cover the proposed deployment before the tool receives sensitive repository access.

Further reading

Talk with Factory

Discuss your team’s software development, privacy, or deployment requirements.

Contact us

Ready to build the software of the future?

Start building

Arrow Right Icon