An AI agent that drafts and auto-merges its own change fails segregation of duties under SOX and PCI-DSS, even if a second AI reviewed it first.
A coding agent that drafts a financially material change and then merges its own output under the same account, with no accountable human in between, does not satisfy segregation of duties under SOX or PCI-DSS. That holds even if a second model reviewed the diff first, because both frameworks are built around the same assumption about a human workforce: the party who writes a change and the party who approves it must be different, accountable people, and that assumption does not relax because the author is a model instead of an engineer.
This is not a hypothetical edge case. Spec-driven and agentic coding tools now draft, test, and open pull requests inside production codebases at banks, payment processors, and fintechs, frequently under a service identity that has merge rights of its own. The question an auditor asks during a SOX walkthrough or a PCI-DSS assessment is never whether the code works. It's who is accountable for saying yes, and whether that person could have said no.
A disclosure before the specifics: we build TLM Forge, a spec-audit, independent-review, and adversarial-gate process for AI-written code, which is the category this post examines. Treat the standards descriptions below as the claims to check against the primary text yourself; the product section near the end is flagged clearly as a vendor claim, not a compliance certification.
What PCI-DSS actually requires of a code change
PCI-DSS v4.0.1's Requirement 6.2 governs bespoke and custom software, meaning code an entity writes for itself rather than buys off the shelf. Requirement 6.2.1 expects that software to come out of a documented, security-aware development process, not an ad hoc one. Requirement 6.2.3 requires that code changes be reviewed before release into production to catch coding vulnerabilities, and the reviewer has to be someone other than the code's original author, or an automated tool such as a static-analysis scanner. Where the review is manual, 6.2.3.1 tightens that further: the reviewer must be a different individual with code-review and secure-coding knowledge, and the review results must be reviewed and approved by management before release.
Sources: PCI Security Standards Council, Document Library (PCI DSS v4.0.1), PCI DSS v4.0.1 Requirement 6.2.3.1 mapping (Cloudaware)
Note what 6.2.3 does not say: it does not require a human reviewer in every case. An automated scanner satisfies the base requirement. The independence rule, a different person than the author, only binds tightly once the review is manual, under 6.2.3.1. That gap matters for AI-written code, because a vulnerability scanner passing a diff is a different thing than a person with authority having looked at it.
PCI SSC's own AI guidance goes further, and it isn't binding
Separate from the mandatory standard, the PCI Security Standards Council has published its own non-binding AI guidance, and it speaks to this exact question more directly than Requirement 6 does. A September 2025 Council blog post on AI principles states plainly that AI systems "are not human individuals, and they cannot accept or take on responsibility," and that "operations and roles which require the formal acceptance of responsibility are not suitable for AI systems," naming key custodian as an example. It adds that "the entirety of the creation and deployment pipeline should not be fully automated," and that there should always be a human responsible for oversight of an end-to-end process.
Sources: PCI SSC: AI Principles: Securing the Use of AI in Payment Environments
A follow-on information supplement, Security Considerations for AI Systems, reportedly extends the same logic: for AI agents with access to cleartext cardholder data, it recommends explicit human approval for any action touching that data, and for lower-risk actions it allows a "monitored autonomy" model instead, provided the organization has defined permitted actions, shutdown triggers, and reversal procedures. Either way, a suitable human is expected to formally accept responsibility for what the AI produced. The Council describes this supplement as advisory: where it conflicts with the formal PCI DSS requirements, the requirements take precedence, and how much weight assessors give it is not yet settled.
Sources: PCI SSC calls for human approval of AI agent actions involving cardholder data (Help Net Security)
What SOX actually requires, and what's built around it
SOX itself is narrower than most engineering teams assume. Section 404 requires management to assess and report on the effectiveness of internal control over financial reporting; it does not name a checklist of IT controls, let alone a code-review rule. Segregation of duties, in the form most engineering teams recognize, is something organizations build on top of that requirement, typically using the COSO Internal Control framework and ISACA's COBIT to define and test the IT general controls that support a SOX assessment. The control auditors actually test is a simple one: no single identity should be able to initiate, approve, and deploy a change to a financially material system on its own.
Sources: SOX ITGCs: How to Choose IT General Controls for SOX Requirements (Secureframe)
Treat "segregation of duties" as shorthand for an IT-general-control an auditor tests under SOX, not as a phrase printed in the statute. That distinction matters when a vendor or an internal team claims a tool is "SOX-compliant": SOX doesn't certify tools, auditors test whether a specific control operated as designed.
Where AI agents break the assumption behind the control
Segregation of duties was designed around a workforce of distinct, accountable people. A coding agent breaks that quietly rather than loudly: the pull request still opens, the diff still passes CI, and nothing in the pipeline complains, because nothing in the pipeline is checking whether the author and the approver are the same accountable party. One vendor working this problem from the runtime-execution side frames the test precisely: "no single identity, human or non-human, can both create a change and deploy it without independent verification." Another, writing specifically about finance workflows, calls an AI agent that both builds and runs a production process a "control disaster" even when no individual human role has changed on paper, and asks the question an auditor will actually ask: "who approved this workflow, and is the approver separated from the executor?"
Sources: AI coding agents and segregation of duties: what to know (hoop.dev), AI Agents Are the New Privileged User (Savant Labs)
The failure mode that matters most is the one that looks like a control from a distance: an agent drafts the change, a second agent (or the same model, re-run) reviews it, and the merge goes through with no human in the loop. Two computational passes happened. Segregation of duties, as SOX and PCI-DSS auditors test it, did not. The control was never about a second pass; it was about a second accountable party who could have said no, whose "no" would have actually stopped the change, and whose identity is on record.
| Review pattern | Who authored it | Who reviewed it | Satisfies the SoD intent? |
|---|---|---|---|
| Human writes, human approves | Developer | A different engineer with merge authority | Yes, the standard case the control was written for |
| Agent writes, same agent/account auto-merges | Coding agent under a service account | None, the same account merges its own output | No, author and approver are the same accountable identity |
| Agent writes, a different agent model reviews | Coding agent A | Coding agent B, a different model or prompt | Probably not, no accountable human signed off and the review carries no authority to be enforced |
| Agent writes, independent human reviews and holds merge authority | Coding agent proposes the diff | A named human reviewer who can reject it | Yes, if the review is logged and cannot be bypassed under load or by override |
What an auditor actually wants to see
None of this requires predicting how a specific QSA or external auditor will rule on a specific pipeline. It does mean knowing what evidence they will ask for when they sample a financially material change that an AI agent touched.
- Who or what proposed the change: the agent identity, the model and version, and the spec or ticket it worked from, not just a commit message.
- Who or what independently reviewed it, and what authority that reviewer actually held, meaning could the change have been rejected and did that rejection stick, or was the review advisory.
- Whether the review could be bypassed: an admin override, a merge queue that proceeds on timeout, a flag that skips the gate under deploy pressure.
- A named, accountable human tied to the approval record, not a system account or a shared service identity standing in for a person.
- A timestamped record linking the request, the review, and the approval that survives independently of the git history, so it can be produced on sample without reconstruction.
The reason "an AI wrote it, a different AI reviewed it" probably does not satisfy that question is that neither SOX nor PCI-DSS auditors are grading computational redundancy. They are grading accountability. The PCI Council's own framing is blunt about this: AI systems "cannot accept or take on responsibility," so "ultimate responsibility must come down to a single individual." A second model can catch bugs a first model missed, and that is worth having. It cannot be the party that is accountable when the change turns out to be wrong, because a model is not a party at all in the sense the control was written to protect against.
Sources: PCI SSC: AI Principles: Securing the Use of AI in Payment Environments
What TLM Forge's process gives you, and what it doesn't
TLM Forge runs a spec audit before code generation, an independent diff review distinct from the agent that wrote the change, an adversarial red-team pass, and a convergence gate that blocks a merge until outstanding issues hit zero. How it works covers the mechanics. That process produces artifacts an auditor would plausibly want: a record of what was proposed, what an independently-scoped review flagged, what changed in response, and whether the gate actually blocked the merge until resolution, not just whether it ran.
What it does not do is certify SOX or PCI-DSS compliance, and it should not be described that way. The independent review in TLM Forge's pipeline is still, by default, a different computational pass rather than a different accountable human. If the merge authority on top of it is a service account with no named individual tied to the approval, the evidence trail is better than nothing but still falls short of what a SOX or PCI-DSS assessor is actually testing for. Closing that gap means putting a named, accountable human with real reject authority at the point where the gate opens, and using the tool's output as the evidence that supports their decision, not as a replacement for it.
For the broader shape of this problem across SOC 2, HIPAA, and GDPR environments, where provenance and audit-trail capture are the central issue rather than segregation of duties specifically, see Shipping AI Code in a Regulated Codebase. That piece covers the general case; this one narrows to the specific SOX and PCI-DSS question of who is allowed to be the approver when the author is a model.
Frequently asked questions
01Can a different AI model reviewing the code satisfy segregation of duties?
Probably not by itself. PCI-DSS's manual-review rule and SOX-style segregation of duties are built around an accountable human sign-off, not a second computational pass. Auditors look for a named person who could have rejected the change and whose approval is logged.
02Does PCI-DSS require a human to review every code change?
No. Requirement 6.2.3 allows automated tools such as SAST scanners as an alternative to a second reviewer. The independence rule requiring a different human reviewer, 6.2.3.1, applies specifically when the review method chosen is manual, not in every case.
03Does SOX itself mention AI agents or code review?
No. Section 404 requires management to assess internal control over financial reporting; it names no specific IT controls. Segregation of duties is a control organizations build, usually via the COSO or COBIT frameworks, to satisfy that assessment, and auditors test it as a general control.
04Is it a problem if the same account both writes and merges a change?
PCI SSC's own AI guidance says a fully automated creation-and-deployment pipeline with no human oversight is not advisable, and that AI systems cannot formally accept responsibility. One account authoring and merging its own change leaves no independent party to hold accountable.
05Does using TLM Forge make a codebase SOX or PCI-DSS compliant?
No. It produces evidence, such as who proposed a change, what independent review flagged, and whether a convergence gate actually blocked the merge, that supports an audit. It does not certify compliance or replace the accountable human sign-off those controls assume.