Coding agents now open pull requests, write database migrations and edit infrastructure templates. Many teams are asking whether their auditors expect something new. They don't, at least not on paper. Neither the AICPA's Trust Services Criteria nor ISO/IEC 27001:2022 has a change-management requirement written for AI. Auditors therefore apply the controls they already have to commits no person typed. The real question is whether your change process still produces the evidence those controls take for granted.
What the Frameworks Actually Require
For SOC 2, the relevant criterion is CC8.1. In the AICPA's 2017 Trust Services Criteria, it says the organization authorizes, designs and develops, configures, documents, tests, approves and implements changes to its infrastructure, data, software and procedures. The points of focus, revised in 2022 without changing the criteria, break this into separate steps. A change should be authorized before it's designed, built or acquired, tested before it reaches production and approved before implementation, with a defined path for emergency changes. The 2022 points of focus also build segregation into deployment: one user shouldn't be able to develop or test a change and also push it to production. CC5.1 carries the broader principle of separating incompatible duties, or designing alternative controls where separation isn't practical. The AICPA is explicit that not every point of focus has to be addressed, but in practice auditors design their test steps around them.
For ISO 27001, the anchor is Annex A 8.32, Change management, which requires changes to information processing facilities and systems to go through change management procedures. It doesn't operate alone, and like every Annex A control it applies through your risk treatment and Statement of Applicability rather than automatically. Annex A 8.25 (secure development life cycle), 8.28 (secure coding), 8.29 (security testing in development and acceptance), 8.31 (separation of development, test and production environments), 8.4 (access to source code) and 5.3 (segregation of duties) all apply to the same pipeline.
None of these controls says anything about who, or what, writes the change. The profession's recent AI guidance hasn't changed that. In September the AICPA published technical Q&A on how a service organization's use of AI affects SOC 1 and SOC 2 examinations. On October 13 it followed with a practice aid for financial statement auditors, which, as the Journal of Accountancy reports, keeps responsibility for the opinion with the auditor. Both work within the existing standards rather than adding new criteria.
Where AI-Written Code Strains the Control
The criteria hold up. What breaks are the assumptions underneath them, usually in four places.
- Authorship: in most Git workflows, a commit carries the identity of whoever ran the agent. If the agent works under a developer's own credentials, the logs can't tell human work from machine work. Give agents their own service identities so the change record shows what actually happened.
- Segregation of duties: the classic rule is that whoever develops a change doesn't approve it. If an agent writes the code and the developer who prompted it approves the pull request, the independent reviewer is effectively the author. Treat the person who directed the agent as the author, and require a second approver. Check too whether the agent's identity can merge or deploy on its own. If it can, development and implementation have collapsed into one, which is exactly the unilateral path the CC8.1 deployment point of focus is meant to close. Under ISO, it's also a question of how write access to source code is managed under Annex A 8.4.
- Review quality: an approval click looks the same whether the reviewer read twenty lines or two thousand. Agents raise both the volume and the size of changes, so approval evidence alone says less than it used to.
- Test independence: the 2022 points of focus count automated testing as testing, so machine-written tests aren't the problem. But when the same agent writes the code and the tests that pass it, the testing step is technically satisfied and proves little. Testing under CC8.1 and Annex A 8.29 should include checks the author didn't design.
How to Test It
For SOX ITGC change management over in-scope financial applications, the attributes don't change: authorization, testing, approval, segregation and restricted migration to production. What changes is where to look.
- Inventory agent access first: which in-scope repositories and pipelines can an agent commit to, merge into or deploy from? You can't scope a control you haven't mapped.
- Inspect the enforcement settings: confirm branch protection requires an approver other than the author, and that agent or service accounts can't bypass it.
- Prove completeness: reconcile what was deployed back to the change population, including agent-originated pull requests, before sampling from it.
- Sample for substance: in the sample, compare diff size against time-to-approval and look for review comments. A pattern of large changes approved in seconds is a finding, whoever wrote the code.
One scoping point is often missed. Your AI coding vendor's SOC 2 report covers the vendor's own system. It doesn't cover your change process. Agent-written code that enters your repository is your change, under your controls.
Seeing AI show up in your audit and risk scope? If you hold a CISM or CISSP, AAISM™ is the next step. The AI Security Management Prep App covers it across 307 practice questions, fully offline — free to download on Google Play.
Explore the AppRelated Reading
For the full exam breakdown, see the AAISM™ Certification Study Guide. On how AI changes an existing control framework, see IT Governance vs. AI Governance: What's Actually Different. On assurance over AI systems, see Third-Party AI Audits Are Becoming Law. On AI tools adopted outside formal controls, see Shadow AI Governance Gap.
Sources
AICPA & CIMA — 2017 Trust Services Criteria (with revised points of focus, 2022)
ISO — ISO/IEC 27001:2022 Information security management systems
AICPA & CIMA — TQA 9561: Effect of the service organization's use of AI on SOC 1 and SOC 2 examinations
AICPA & CIMA — AICPA releases guidance on AI in financial reporting and auditing
Journal of Accountancy — AI and the audit: AICPA publishes practice aid