Are AI Coding Assistants SOC 2 Compliant? What Auditors Ask

Yes — you can use Cursor, GitHub Copilot, and Claude Code and still pass a SOC 2 audit. The question auditors ask is not “is the tool compliant?” but “do you govern it like any other subprocessor that touches your source code?” That means a vendor review with the right contractual terms, an approved-tool policy your team actually follows, technical controls that keep secrets out of prompts, and evidence you can hand over during fieldwork. Teams that stumble in this section stumble on shadow usage — engineers on personal AI accounts nobody reviewed — not on the tools themselves.

Do SOC 2 auditors actually ask about AI coding tools?

Increasingly, yes — under vendor management, not under some new AI section. SOC 2 is built on the AICPA’s Trust Services Criteria, which have no AI-specific control; auditors map AI assistants onto the criteria that already exist: vendor and business partner management, logical access, change management, and confidentiality. An AI coding tool is a vendor that receives your proprietary source code, so it lands in the same review queue as your cloud provider and your error-tracking SaaS.

In practice, expect three questions during fieldwork:

• Which AI tools are approved, and how do you know those are the only ones in use?
• What did your vendor review of each tool cover — training on your data, retention, subprocessors?
• How does AI-generated code reach production — does it pass the same review and CI gates as human code?

That third one is the sleeper. If your change-management narrative says all code is peer-reviewed and tested before merge, AI-generated code must follow the same path — “Copilot wrote it” is not an exemption from branch protection.

What vendor commitments should you get in writing?

Before approving a tool, collect its SOC 2 report and pin down two things in the contract or plan tier: your code is not used to train models, and retention is limited or zero. The business tiers of the major tools can meet this; free and personal tiers often cannot, which is exactly why personal accounts are the risk.

What the vendors publish, per their own security and legal pages:

Tool	Attestations (per vendor)	Data commitment to look for
Cursor	SOC 2 Type II, ISO 27001:2022, ISO 42001:2023	Privacy Mode — “we will not train on your data,” plus contractual controls with model providers
GitHub Copilot	Covered under GitHub/Microsoft trust documentation	Org-level policy controls for privacy, model access, and MCP servers on Business/Enterprise plans
Claude Code (Anthropic)	Reports via Anthropic’s trust center	Commercial terms: “Anthropic may not train models on Customer Content from Services”

Zero-data-retention (ZDR) agreements are the strongest version. Anthropic, for example, offers qualifying commercial customers ZDR arrangements under which inputs and outputs are not stored except where required by law or to combat misuse — safety classifier results are still retained, per their privacy docs. Not every startup needs ZDR, but if you handle regulated data or your enterprise customers grill you on subprocessors, ask each AI vendor whether a ZDR tier exists — and get the answer into the order form, not a sales email. Either way, write the decision into your vendor risk assessment so the auditor sees a choice, not an accident.

What does an approved-tool policy look like?

One page, four sections — auditors want to see that it exists, that it predates your audit window, and that you enforce it. A shape that holds up in fieldwork:

• Approved list: named tools at named plan tiers (“Copilot Business,” not “Copilot”), accessed only through company SSO — no personal accounts on company code.
• Prohibited by default: anything not on the list, including browser chatbots for pasting proprietary code.
• Required settings: privacy/no-training mode on, org-managed seats so offboarding revokes access, admin policies locked rather than left to individual choice.
• Data rules: no credentials, customer data, or PHI in prompts, ever.

Codify the machine-readable half in your repos too — AGENTS.md and CLAUDE.md files are where per-repo AI rules live, and a versioned policy file in Git is stronger evidence than a PDF nobody opens.

How do you keep secrets out of the prompt window?

Policy alone doesn’t stop an assistant from reading .env into context. You need technical controls: secrets in a manager (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault) instead of in files the tool can index, ignore rules that exclude sensitive paths from AI context, and pre-commit plus CI secret scanning as the backstop. A secret leaked into an AI prompt is a confidentiality incident under your own SOC 2 narrative, so this is the control auditors probe hardest. The full setup is in how to keep secrets out of AI coding tools.

What evidence should you have ready for the auditor?

Six artifacts cover nearly every AI-tooling request. For a Type II report, they must exist throughout the observation window, not just at fieldwork:

• The approved-tool policy, with version history and employee acknowledgment
• Vendor review records: each tool’s SOC 2 report, DPA, and training/retention terms
• Seat inventory from each tool’s admin console, reconciled in quarterly access reviews
• Screenshots or exports of enforced org settings (privacy mode, SSO, policy toggles)
• Branch-protection and CI evidence showing AI-generated code passes the same gates
• Offboarding tickets showing AI-tool seats revoked alongside everything else

Compliance platforms collect some of this automatically — see automating SOC 2 evidence with Vanta and Drata — but AI-tool vendor reviews and the policy itself are still human work.

The bottom line

AI coding assistants are a vendor-management problem with a thin technical layer on top, and both halves are solvable in a couple of weeks. Governed well, they’re one of the easiest sections of your audit; ungoverned, they’re the finding your auditor remembers. If SOC 2 is on your roadmap, ByteDel’s SOC 2-Ready Infrastructure package builds tool governance alongside the AWS, GCP, or Azure hardening auditors actually test — see pricing for how the audit-prep engagement is scoped.

This is engineering guidance based on public vendor documentation and the SOC 2 Trust Services Criteria, not legal advice — confirm contractual specifics with your auditor and counsel.