Segregation of Duties: The Property an Auditor Can Verify in the Log
Intercom took its automated PR-approval pipeline to its auditors, Schellman, and confirmed it meets SOC 2, HIPAA, ISO 27001, ISO 42001, and AIUC-1 (Intercom). It auto-approves 19% of pull requests with no human in the loop. That is the segregation-of-duties property doing its job: the fifth of the seven properties an auditable agent system has to satisfy, and the one where the change-management control SOC 2 has demanded for decades meets agent volume. It assumes you already enforce the rule and asks what an auditor accepts as proof you did.
The enforcement itself is a decision-gate question and lives in author never approver under Manage the Work, alongside the gates that produce the evidence: review as a gate, AI reviewing AI, and auto-approval by risk. The entity that authored a change cannot approve it, and a platform built correctly enforces that as a permission that does not exist, not a sentence in a handbook.
The auditor accepts it because the control is provable, not because a human clicked approve
The argument Intercom's auditors signed off on is that the evidence shape does not change when the approver does. Every AI-approved PR is "labelled, logged, and queryable," with review comments, approval decision, test results, and merge event all recorded. In Intercom's words: "The 'who' may change, but the 'what' doesn't." The SOC 2 change-management objective was never "a human clicked approve." It was "a qualified, independent check happened before the change shipped, and you can prove it." Proving it is the work of the audit-trail property.
What it has to show is three distinct actors. The agent that authored the change is one, the human who initiated the task is a second, and the approver must be a third entity, human or automated, distinct from both. That is why segregation of duties pairs with attribution: if the record cannot tell the author from the approver, there is no control to evidence. GitHub's Copilot cloud agent is the cleanest published example of the capability boundary that makes the distinction real: the agent "cannot mark its pull requests as 'Ready for review' and cannot approve or merge a pull request," and the person who asked Copilot to create the pull request is blocked from approving it too, preserving the "Required approvals" rule (GitHub Docs). The agent never holds the approval capability, so the log can never record the author approving its own work.
The capability boundary assumes the approver is human. An AI reviewing step must hold the approval capability, so stripping it from the agent stops being an option. Distinctness has to come from identity instead: a persistent identity per role, so the implementing function and the reviewing function are never the same principal. Otherwise a single AI identity scoped to the initiating human can perform both steps of one task, and authored-by and approved-by resolve to the same actor.
Volume is the threat to the control, and Intercom is the published proof it scales
The threat AI volume poses to segregation of duties is not that agents will self-approve. It's that humans will. Intercom names the failure mode plainly: when agents produce working implementations in minutes and human review takes hours or days, "either the queue backs up and velocity drops, or, more dangerously, humans start rubber-stamping." A rubber-stamped approval satisfies the control on paper and nobody else. Their framing: "Speed is not the enemy of safety. It's a prerequisite for it."
Their answer was to make the approving gate as scalable as the authoring agent. Review is decomposed into independent sub-agents (problem-description quality, code-intent alignment, safety, logical correctness, best practices), and the reviewer traces execution paths through the codebase, "something humans rarely had time to do." The gate is also strict in a way tired humans aren't: the agent won't approve large PRs, flagging them for breakdown instead, which turns scope discipline into an enforced control rather than a style preference.
The numbers Schellman saw alongside the controls: a 6–16x improvement in time-to-approval at the 75th percentile, 497 fully autonomous PRs in the first four weeks of broader rollout, and AI-authored code reverting at a fraction of human rates (backend 0.53% vs 5.39%, frontend 0.22% vs 2.00%). And the line that reframes the whole debate: the product changes that caused past outages "were all reviewed and approved by humans."
Two boundaries the auditor will probe
Opt-out and ownership. A scaled automated gate does not remove the human from the loop, and an auditor will want to see that. At Intercom, "any engineer can request a human review on any change, at any time," and the engineer who ships a change watches it go live and owns the rollback. Automated approval replaces the review bottleneck, not the accountable human.
Same-model independence. The corpus is silent on reviewer independence at the model layer. If the authoring agent and the reviewing agent run on the same underlying model, is that one actor or two for the purposes of the control? Intercom's sub-agent decomposition and Schellman's sign-off are the strongest published evidence that decomposed AI review satisfies auditors, but no source in this handbook's research addresses same-model independence head-on. Treat it as an open question to put to your own auditor.
What the auditor wants to see, row by row
| Rule | The evidence behind it |
|---|---|
| Agent cannot approve or merge its own work | Capability absent from the agent's credentials, not just denied by policy |
| Task initiator cannot approve the agent's PR | Required-approvals rule treats initiator as author |
| Automation-created PRs attribute to the automation's creator | Creator is then barred from approving |
| Large changes are refused, not waved through | Reviewer flags and requires breakdown |
| Human review available on demand | Opt-out on any change, at any time, recorded |
If your platform can't show each row as an enforced behavior with a log entry behind it, the author-approver split is a promise rather than a property, and an auditor sampling your change-management evidence will find the gap.