A manager says code review is dead. His team disagrees. Someone replies with the question that actually decides it: if you are under SOC 2, how do you merge without a human approving the change? A compliance practitioner answers, correctly, that the framework does not care how the approval happens, only that your documented process is followed. That answer is right, and it is where the interesting part starts, because the process a team would have to write down is narrower and stranger than either side of the argument assumes.
The tools in the room for this are real and shipping today: Greptile, GitHub Copilot code review, Claude Code, each reading pull requests right now. So the useful question is not whether an AI is allowed to approve a change. It is what SOC 2 actually asks of that approval, and what a code-review signal is built to tell you, versus what a compliance approval still has to establish on its own.
What CC8.1 actually asks
SOC 2 change management lives in one criterion, CC8.1. In plain terms it asks that a change is authorized, built, configured, documented, tested, approved, and implemented through a defined process, so that changes reach production deliberately rather than by accident. It names the steps a change should pass through and expects your changes to actually pass through them.
The word carrying the whole argument is 'approved'. The criterion names the step. It does not name who, or what, performs it. SOC 2's criteria are written to be principle-based and technology-neutral: you define the control that meets the criterion, and the auditor tests the control you defined, as written, over the period. Nothing in CC8.1 says the approver has to be a person. A policy that authorizes automated approval for a defined class of change can meet it, if the control is scoped, evidenced, and operates the way you wrote it down, and your auditor accepts it as the control.
This is not hypothetical. Teams are already rewriting change-management policy so that low-risk changes can be approved by automated means, with human approval reserved for changes above a risk line they define. That is a defensible CC8.1 posture when you can evidence it. It is a policy, applied and tested, not the absence of one.
The three things 'the AI approved it' walks past
First, separation of duties. An approval is only worth something if the approver is independent of the author. That is the oldest expectation in change management: the person who wrote the change is not the only one who signs it off, so that no single actor can push whatever they like to production. 'The AI approved it' runs straight into this. If the same agent authors the diff and clears it, or two automations do with no independent check between them, you have collapsed author and approver. That is the part an auditor pushes on, not the word 'AI'.
Second, the policy has to actually say this. An auditor does not test your intentions, they test your documented process against what happened. 'The reviewer bot was happy' is not a control unless your change-management policy defines that reviewer: what it is, which changes it may approve, what it checks, and when a human is still required. Without that, an automated approval is not a control operating as designed. It is a merge with a robot's comment attached.
Third, the evidence trail is the same either way. What an auditor samples does not change because a bot approved: they want to see that the change was authorized, that it was tested, who or what approved it, and that all of it is tied to the change and logged. Automated approval passes CC8.1 when it produces that trail on every change it touches. If it does not leave the record, it has not replaced the control, it has skipped it.
A mechanical detail the thread skips: comment is not approve
Underneath the philosophy there is a wiring detail that decides more than the philosophy does. In GitHub's own model, an AI reviewer leaving feedback and an AI reviewer casting the approving action are two different things, and the tools people name do not all do the second.
GitHub Copilot code review, generally available since 2025, posts its feedback as a Comment review by design. By GitHub's own description it does not count toward required approvals and does not block or clear a merge. So 'let Copilot approve' is not, mechanically, a thing Copilot does: a required human, or an automerge rule you configured, still casts the approving action. Claude Code's pull-request action reads changes and, depending on how you wire it, posts its feedback as comments or as a formal review event, so what it submits, and whether that can satisfy a branch-protection rule, is something you configure and verify. Greptile reads each pull request for bugs and quality with context from the whole codebase and flags issues on the change.
So 'the AI can approve' is a configuration decision as much as a policy one. Which tool casts which signal, what that signal is permitted to gate, and where the record of it lands are things you set on purpose, in repository rules and branch protection, not things that follow from a tweet. Set them deliberately, because that configuration is the control your auditor will actually test.
A green review is not a compliance review
Even once the mechanics are right, the thread quietly assumes away a harder question. Every one of those tools is built to answer the questions code review has always asked: is this correct, and is it safe. Those are the right questions to ask of a diff, and good ones to automate. Whether the change still meets the frameworks you are audited on is a different question.
That second question depends on which controls you wrote down and what your last audit relied on, and it is not a property of the code that a bug reviewer reads off the diff. A change can be correct, safe, pass every automated check, and still move a control you will be sampled on. Here is the shape of it.
export const auditLog = {- retentionDays: 365,+ retentionDays: 30, // trim storage cost}Clean, correct, and cheaper: nothing here is a bug or a vulnerability. SOC 2 sets no retention number, but your own logging and monitoring control does, and it depends on these logs existing for as long as you committed to keep them. If your control or audit evidence assumes a longer window, events older than the new one can no longer be reviewed, and an audit that samples the period finds the logs no longer reach it. Set retention from what your control and evidence need, not only from the storage bill.
Where heygrc fits
That retention change is clean and correct on its own terms, which is exactly why a compliance question can stay open after every code-review signal on it is green. So when a policy says a change was 'approved by automated means', the honest follow-up is: approved as correct, or approved as compliant? Those are two different approvals, and in that thread only one of them was on the table.
heygrc is built for the second one. It reads each pull request against the frameworks you have to meet and names the exact control a change touches, at the diff, whether a person or an agent wrote it. It does not try to be a bug checker: keep Greptile, Copilot, or Claude Code for correctness and safety, the roles they are built for, and use heygrc for the separate compliance read, reported the only way a compliance finding is worth anything, by citing the clause.
If you are going to let automated approval merge low-risk changes under CC8.1, that is a reasonable direction. An automated compliance read is the missing check that helps you decide which changes are actually low-risk in the first place. The examples here are illustrative, the kind of change that raises the question rather than telemetry we are claiming. But the point holds on its own: SOC 2 never required a human to approve your pull requests. It required that someone, or something, approved them on the record, independently, against a process you wrote down. A code reviewer being happy is not the same as that process having run.