The Auditor and the Agent — David J Crawford

A question I hear more and more, from engineering leaders and from customers alike: can we let AI write production code and still pass our SOC 2?

The short answer is yes. The more interesting answer is that if you do it properly, your audit can come out stronger than it was before the agents arrived.

1. The five criteria don’t move

SOC 2 evaluates a service organisation against five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Nothing in that list mentions who — or what — wrote the code, and that’s the point:

All code in production must uphold the same promises, no matter whose hands (or weights) produced it.

AI-assisted development doesn’t introduce new compliance principles. What it does is amplify existing risks under each criterion. Amplified risk is something the compliance world already knows how to handle: you extend your existing controls to cover it. No parallel “AI framework” required.

2. What actually changes

Four risks get louder, and one is cultural:

Plausible-but-insecure code. Studies have found that roughly 40–48% of AI-generated code snippets contain security vulnerabilities, ranging from inefficient logic to SQL injection and insecure functions. The code looks right, which is precisely the problem.
Hallucinated dependencies. Models suggest libraries that don’t exist, and attackers have noticed that publishing a malicious package under a commonly-hallucinated name is an easy supply-chain play.
Data leaking out through prompts. Samsung learned this publicly in 2023, when engineers pasted confidential source into ChatGPT and the company banned the practice after trade secrets left the building. Every prompt to an external service is a data flow your Confidentiality controls have to account for.
IP contamination. A model can regurgitate licensed code from its training data. SOC 2 doesn’t audit licensing, but an IP incident that forces you to rip out shipped code very much becomes a security and change-management problem.
Complacency. The cultural one. “The AI probably knows what it’s doing” is how review discipline quietly dies, and AI produces code faster than reviewers naturally scale.

3. The controls that answer

None of this requires invention. It requires extending controls you already have, deliberately:

Policy first. Write down which tools are approved, that no sensitive data ever goes into a prompt, and that AI output gets reviewed like any colleague’s work. Make it part of onboarding, and make people sign it; auditors check that policies are known, not just written.
Choose tools like vendors, because they are. An AI coding service is a third party handling your crown jewels. Vet it the way you’d vet any SaaS: ask for its SOC 2 report, prefer zero-data-retention modes, and where the stakes justify it, hybrid or self-hosted deployment so code never leaves your environment. By mid-2025 the better enterprise tools compete on exactly this.
Never let the agent commit to production. Every AI contribution flows through the same pipeline as human work (peer review, static analysis, security scanning, tests), arguably more rigorously, because the volume is higher and the failure modes are newer.
Log everything. Tag AI-assisted commits, keep prompt logs where you run your own models, and fold AI into your incident definitions: a vulnerability that an agent introduced and review missed is an incident, with a root-cause and a policy update, not a shrug.
Fold it into the risk register. “Data could leak via AI tool” and “AI could output vulnerable code” become named risks with named controls. Map each to the criteria it touches. When the auditor arrives, nothing about your AI use is a surprise; it’s a documented, managed part of the system.

4. What the auditor actually cares about

Here’s the reassuring part: the auditor is testing whether your controls operated, not who typed the diff. A sampled change should show the same evidence trail whether a person or an agent drafted it: review record, test results, approval, rollback path.

The deeper principle underneath: every line of code in production has a human owner. Attribution can’t get murky just because generation got cheap. Someone reviewed it, someone approved it, someone answers for it. That’s not bureaucracy; that’s the accountability that lets you use the acceleration.

And evidence beats assertion. Review records on AI-tagged commits. Training sign-offs. A screenshot of the tool’s admin console showing retention off. Even a near-miss handled well (a developer pasted a credential into a prompt; our logs caught it, we rotated the secret within the hour, retrained, and updated the policy) reads to an auditor as a control system working, not failing.

5. The horizon (as of mid-2025)

The wider governance world is converging on the same posture:

The AICPA hasn’t issued an AI-specific SOC 2 variant; the working consensus is that the existing criteria are flexible enough if you map AI risks onto them deliberately.
NIST’s AI Risk Management Framework (AI 100-1, 2023) and its Generative AI Profile (AI 600-1, 2024) give you the govern–map–measure–manage vocabulary, and your SOC 2 report becomes the external evidence you followed it.
ISO/IEC 42001, the AI-management sibling of ISO 27001, has been published and is where formal AI certification is heading.
The EU AI Act is now in force, with obligations phasing in through 2027. If your product’s AI features fall in scope, the record-keeping it demands dovetails neatly with the logging you should be doing anyway.

The pattern across all of it: map once, comply many. Controls you build for SOC 2 today are the same evidence tomorrow’s frameworks will ask for.

6. The silver lining

The quiet finding from teams who’ve done this properly: their overall software quality improved. Tightening review and testing to catch AI’s mistakes catches human mistakes too. The pipeline you harden for the agent hardens for everyone.

That’s the real story here, and it’s the same one I keep finding everywhere agents show up: acceleration and discipline are not opposites: the discipline is what makes the acceleration safe to use. An agentic SDLC with real controls isn’t a compliance headache; it’s a more auditable process than the one it replaced, because you were forced to make the implicit explicit, and evidence of that is exactly what an auditor wants to see.

Trust remains the foundation. Weave it into the tools and the process, and you get the speed without spending the thing that actually keeps customers with you.

Originally researched and written in June 2025, with research assistance from Microsoft Researcher and NotebookLM; lightly revised for this site.