Separation of duties with AI code review

Separation of duties means no one person can both make a change and put it into production without a second, independent person approving it. AI code review does not break that principle; it breaks the record of it. When an agent writes the code, an AI reviewer comments on it, and the same engineer merges it, the approval record looks full and the second person is missing.

Why frameworks care

Every major framework states the principle in its own words. ISO/IEC 27001:2022 A.5.3 asks that conflicting duties be segregated. SOC 2 CC6.1 and CC6.3 restrict and segregate the ability to change production. NIST SP 800-53 AC-5 and SP 800-171 3.1.4 require separation of duties. SOX program-change controls say developers cannot approve or promote their own changes. The reason is the same everywhere: one person acting alone can make a mistake or a bad decision and nobody will see it until it is live.

What AI changes, and what it does not

Coding agents multiply the number of changes. AI reviewers read every one of them and post findings. Both are good. Neither adds a person. The reviewer is a tool run by the same team, often configured by the same engineer who wrote the change, and it cannot be the independent party that separation of duties needs.

Three patterns teams try, and where each lands:

• AI approves, engineer merges. One human touched the change, and it was the author. Fails the test.
• Risk-tiered policy. AI approves low-risk paths, a human approves high-risk paths, a weekly retroactive human review covers the rest. This can work; Mirage Engineering negotiated it with their auditors. It costs a classifier, a staffed weekly review, and a fresh negotiation with each new auditor.
• An independent approver on every change. The design auditors already know how to test. The cost is the approver's time, which is why it has to be fast and priced per change.

How PSCO keeps the duties separate

• The developer and the approver are different people in different organizations. The Officer is contracted by you, not employed by you, and never writes code in your repositories.
• Branch protection enforces it: one required approval from the @psco-officers team through CODEOWNERS and the required psco/approved check. Authors cannot self-approve.
• PSCO never merges or deploys. The approval is a decision that the change meets your model; promotion stays with your release owner, which keeps a third duty separate as well.
• Every decision is recorded on the PR and in an attestation record: who, when, which commit, which model version, which tier.

The control statement

"All changes to production code require approval from a qualified reviewer who is not the author. Reviewers are PSCO Officers, background-checked US-based engineers contracted by the company, who review each change against the company's Security & Compliance Model before approval."

Add one sentence for the merge: "Release to production is performed by the change owner or by automation keyed to the required psco/approved check after approval." Now the author, the approver and the promoter are separate, and the record shows it.