AI Code Review and SOC 2: Do You Need a Human on Every PR?

Your team now ships more code than it can read. Agents write a lot of it. Pull requests pile up, and the review step turns into a rubber stamp. Then someone asks the hard question: can we stop reviewing every PR and still get through SOC 2?

Our view, from the readiness side: SOC 2 asks for controlled, traceable change. It does not ask for a human to approve every pull request. If you can show who can change production, that every change was tested and approved by a rule you wrote down, and a clean record from ticket to deploy, you have something an auditor can test. Human review is one way to do that. It is not the only way, and for routine changes it may not be the strongest.

One caveat up front. Your auditor decides what meets the criteria. We help teams get ready. We are not the auditor, and nothing here is an audit opinion.

What SOC 2 actually asks for

SOC 2 is built on the AICPA Trust Services Criteria. The change management criterion, CC8.1, reads in full: "The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives."

Read it again. It names outcomes. Changes are authorized, tested, approved, and recorded. It does not name git, pull requests, or a second reviewer.

The AICPA's points of focus for CC8.1 add detail (reproduced here). They cover tracking changes, testing before production, approving before release, and emergency changes. Points of focus are guidance, not a checklist.

Amp skipped pull requests on purpose

Amp, the team behind the Amp coding agent, does not use pull requests. Engineers push to main. In "That's not SOC 2 compliant", Will Dollman explains what happened when they asked their auditors about it:

"SOC 2 doesn't require pull requests. It requires that you think about your risks."

Their auditors asked what the change process was, then worked with them on controls that fit it. Amp landed on four: restricted push access, signed commits, automated CI that blocks bad changes, and an audit trail that links each commit to the work that produced it. As Dollman puts it, "The criteria don't say a second human has to stare at a diff."

Two things to keep in mind. First, Amp sells a coding agent, so it has a reason to like this answer. Second, Amp says plainly that it is a small team where trust is high, and "we're not going to pretend a 2,000-person company should let everyone push to main." That is one team and one auditor. It shows the option exists. It does not show your auditor will agree.

Blanket review is weaker than it looks

Semgrep made the case well in "The End Is Nigh for Code Review". Semgrep sells security and code review tools, so discount the pitch. The strongest number in that post is not a vendor number, though. It comes from a study by researchers at Carnegie Mellon and Stanford.

They followed 802 developers and 196,212 pull requests at one company, from January 2024 to April 2026. Load per reviewer roughly doubled. Reviews with a written human comment fell from about 39% of pull requests to about 21%. The median reviewer's commented reviews stayed flat while their silent approvals roughly doubled.

That is one company, and the authors are careful about what it proves. But it matches what many teams feel. When volume rises, people approve more and say less. An approval click with no reading behind it is not much of a control, even if it looks fine in a sample.

The controls that replace blanket review

If a human will not read every change, something else has to carry the weight. These are the controls that do it.

1. Lock who can change main. For most small teams, that means no direct pushes to your production branch. If you do allow them, as Amp does, you need compensating controls: a short, named list of who can push, signed commits, required checks on main, and a trail from each commit to its deploy. Code owner review will not apply to those pushes, as covered below. Use GitHub protected branches or rulesets to restrict who can push, block force pushes, and keep the bypass list short. With classic branch protection, admins skip the rules unless you turn on "Do not allow bypassing the above settings." Rulesets work differently: only the people, teams, or apps on the ruleset's bypass list can skip it. Either way, turn bypass off or name each bypass on purpose. Repo admins can also change the rules themselves, so keep the ruleset history or audit log that shows the rules stayed on.

2. Require signed commits. With required signed commits, only signed and verified commits land on the branch. Each commit is then tied to a key registered to an account, not just a name typed into a config file. That shows who held the key, not which person wrote the code. Commits GitHub makes for you, such as web edits and squash merges, are signed by GitHub itself and show as Verified. Rebase and merge is the exception: GitHub does not sign those commits.

3. Make tests and security scans required checks. Unit and integration tests, static analysis (SAST), and dependency scanning should run on every change. Mark them as required status checks so a failure blocks the merge. GitHub also lets you require that a check comes from a specific app. Then only that app can report the check, so another user or app cannot post a passing result in its place. It does not stop an admin or anyone on the bypass list from overriding or changing the rule, which is why the bypass list in control 1 matters. For secrets, GitHub secret scanning works a little differently. Push protection blocks a push when it detects a supported secret, and secret scanning raises an alert for what it finds in the repo. Neither is usually a required status check. By default, anyone with write access can bypass a push protection block by giving a reason. GitHub logs the bypass and raises an alert, so review it with your other bypasses. If you want a secret to block the merge too, run a secret scanner in CI and make that a required check.

4. Use AI review as one input. An AI reviewer can read every change and flag what a tired human would skip. Treat it as a check that reports and escalates. Do not treat it as the approver of record for risky changes, and do not let it be the only control. Keep its findings as evidence, linked to the pull request or merge record, with what happened to each one: fixed, or dismissed with a reason. That supports the trail. It is not an approval on its own.

5. Keep a trail from ticket to deploy. For any change, you should be able to walk the chain: the ticket or request, the commits, the pull request or merge record, the check results, the deploy log, and who approved it. That approver can be a person or a written rule the change met. If the chain breaks anywhere, the control is hard to test.

Which changes still need a human

Use CODEOWNERS with "Require review from Code Owners" so changes to sensitive paths get a named human. Code owner review only applies to pull requests. If your team pushes straight to main, require pull requests on that branch with a ruleset or branch protection. Otherwise code owners do nothing. Put these on the list:

• Login, sessions, authorization, and access control.
• Encryption, key handling, and secrets config.
• Payment paths and code that touches customer data, personal data (PII), or data retention.
• Database migrations.
• Dependency and lockfile changes.
• Infrastructure as code and cloud permissions (IAM).
• Production config and feature flags that change security.
• CI/CD pipeline files (such as .github/workflows) and deploy scripts.
• Logging and audit trail changes.
• The CODEOWNERS file, branch protection or ruleset settings, and your change policy itself.
• Emergency changes. Ship the fix, then get a human review after the fact, within a time your policy sets, and log it.

GitHub's own docs say to give the CODEOWNERS file an owner too. Otherwise a change to that file could remove the very review it is meant to require.

Letting routine changes merge on passing checks is a choice based on risk, and it only holds up with guardrails. Write down what counts as routine. Send everything on the list above to a human every time. Keep bypass to a few named people, log every use, and review that log. Watch production after deploys and be ready to roll back. On a tiny team, have someone other than the author review a sample of merged changes after the fact, on a set schedule. Even then, your auditor decides whether it meets the criteria.

Illustrative example, not client data

Say a team merges 50 changes in a week. Five touch paths on the list above, so five get a code owner's review. The other 45 merge after tests, scans, and AI review all pass, with no human approval. One change is an urgent fix that ships at night. It goes in the emergency log, and a code owner reviews it the next morning.

That team reviews fewer changes by hand. But each human review is on a change that matters, and every change has a record. The numbers here are made up to show the shape. They are not a target.

What your auditor will want to see

Expect requests like these. Your auditor sets the final list.

• A written change policy that says what counts as routine, which changes need a human, which can merge on checks alone, and how emergencies work.
• Branch rules, as screenshots or exports from your repo settings, showing restricted pushes, required checks, signed commits, and the bypass list. Add the ruleset history or audit log that shows who changed the rules and that they stayed on.
• Sample changes. The auditor picks some from across the period. For each one, show the pull request or merge record, the check results, any AI review findings and how they were handled, and the deploy.
• Deploy logs that tie each release back to its commits.
• An exception, bypass, and emergency log with the after-the-fact review for each entry.
• Records of after-the-fact sample reviews, if routine changes merge without a human.
• An access list of who can merge, who can bypass, and why.
• A periodic review of that access list and of the rules themselves. Our post on access reviews that aren't theater covers how to make that review real.

A Type I report looks at whether the controls are designed well at one point in time. For Type II, the evidence has to show the controls worked the same way across the whole observation window, not just on the day you set them up. That means sample changes from across the period, history showing the protections stayed on, and a record of every exception and bypass. Our SOC 2 readiness in 90 days post walks through that timeline.

Small teams and separation of duties

Separation of duties is where tiny teams get stuck. If one engineer writes a change, checks pass, and that same engineer deploys it, one person controlled the whole path. Auditors commonly look hard at that.

Small teams can often handle this with compensating controls. Required checks that only the named app can report. A short bypass list, with every bypass logged and reviewed. Someone other than the author who reviews the emergency log and a sample of merged changes on a set schedule. Whether that is enough is your auditor's call, so ask early, before your observation window starts.

Talk to your auditor early

Write your change policy first. Then take it to your audit firm before you depend on it, the way Amp did. Ask what evidence they will want and how they will sample. Some firms will be at ease with checks as approvals for routine changes. Others will want more. If a buyer asks how you control change while you wait, our post on questionnaires before the audit can help.

If your team runs coding agents, the keys those agents hold are their own topic. We cover that in AI agent least privilege. This post is about the changes they produce.

If you want a second set of eyes on your change policy before you take it to your auditor, we're happy to talk it through.

Sources

• AICPA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• Openlane, CC8.1 criterion and points of focus
• Amp, Will Dollman, "That's not SOC 2 compliant", August 13, 2026
• Semgrep, Daghan Altas, "The End Is Nigh for Code Review", October 9, 2026
• He et al., "AI Writes Faster Than Humans Can Review", arXiv, July 2026
• GitHub Docs, About protected branches
• GitHub Docs, About rulesets
• GitHub Docs, About code owners
• GitHub Docs, Push protection
• GitHub Docs, About commit signature verification
• GitHub Docs, About merge methods on GitHub