{
 "slug": "github-copilot-pr-approval-soc2-supply-chain-risk",
 "topic_id": "TOPIC-035",
 "cluster": "CI/CD & Software Supply Chain",
 "tier": "Tier A",
 "title": "When an AI approves the pull request, what is left of change control?",
 "summary": "Branch protection counts approvals. It has never checked whether an approver read the diff. That worked while only humans could click the button.",
 "lede": "Two decades of software change control rest on a proxy: require one approval on a pull request and infer that a human looked at the code. The proxy held because clicking required a person. It no longer does.",
 "date": "2026-02-19",
 "category": "AEO",
 "author_id": "elias-vanterpool-osei",
 "tags": [
  "code review",
  "SOC 2",
  "branch protection",
  "change control",
  "AI code review",
  "supply chain"
 ],
 "image_title": "AI Approves The Pull Request",
 "schema": "FAQPage",
 "key_takeaways": [
  "Branch protection evaluates a count of approvals. It cannot distinguish a reviewer who read the diff from one who did not, or from one that is not a person.",
  "Audit frameworks generally require evidence of authorised change, not evidence of human review specifically — which is why the gap was never noticed.",
  "A signature over the commit SHA, produced by a named human, restores the property the approval count was standing in for."
 ],
 "body": [
  {
   "type": "h2",
   "text": "The proxy and why it held"
  },
  {
   "type": "diagram",
   "kind": "flow",
   "alt": "An agent writes the change, an agent approves it, branch protection passes, and the pipeline deploys with no human involved",
   "caption": "Each gate evaluates a boolean about repository state. None of them mentions a person.",
   "nodes": [
    {
     "label": "Agent writes the change",
     "note": "ordinary"
    },
    {
     "label": "Pull request opened",
     "note": "ordinary"
    },
    {
     "label": "Copilot submits an approving review",
     "note": "since 1 Sep 2026",
     "bad": true
    },
    {
     "label": "Branch protection: approvals ≥ 1",
     "note": "satisfied",
     "bad": true
    },
    {
     "label": "Merge and deploy",
     "note": "zero humans",
     "bad": true
    }
   ]
  },
  {
   "type": "p",
   "html": "A branch protection rule enforces something like <code>approvals >= 1 AND checks_passed</code>. Both are boolean conditions on repository state."
  },
  {
   "type": "p",
   "html": "Neither condition mentions human review, comprehension, or attention. The control worked because the only entity capable of producing an approval was a person with an account, and people generally glance at what they approve."
  },
  {
   "type": "p",
   "html": "Both halves of that were always weak. Rubber-stamp approvals are an old problem, and every engineering organisation has some. The difference now is that the mechanism can be satisfied at scale, continuously, by something that is not a person at all."
  },
  {
   "type": "h2",
   "text": "The pipeline that has no human in it"
  },
  {
   "type": "code",
   "text": "agent writes the change\n  → opens a pull request\n  → review agent approves it\n  → branch protection: approvals = 1        ✓\n  → checks pass                              ✓\n  → merge to main\n  → deploy to production\n\n# Total human involvement: zero.\n# Audit evidence produced: an approval record."
  },
  {
   "type": "p",
   "html": "There is a reasonable version of this. AI review genuinely catches defects, and for low-risk changes an automated pipeline is a legitimate engineering choice made deliberately."
  },
  {
   "type": "p",
   "html": "The problem is that it is not being chosen deliberately. It is arriving as a default, into a control framework that assumed it could not happen."
  },
  {
   "type": "h2",
   "text": "What the audit frameworks actually require"
  },
  {
   "type": "table",
   "head": [
    "Framework",
    "Typical requirement",
    "Does it say 'human'?"
   ],
   "rows": [
    [
     "SOC 2 change management criteria",
     "Changes are authorised, designed, tested and approved",
     "Generally not explicitly"
    ],
    [
     "ISO 27001 secure development controls",
     "Changes follow a controlled process with review",
     "Generally not explicitly"
    ],
    [
     "PCI DSS change control",
     "Changes are documented, approved by authorised parties",
     "'Authorised parties' — undefined as to species"
    ],
    [
     "Sector-specific model risk guidance",
     "Independent review before deployment",
     "Often implies human judgement"
    ]
   ]
  },
  {
   "type": "p",
   "html": "The honest reading: most frameworks predate the question and do not answer it. Auditors will form positions over the next cycles, and those positions will vary."
  },
  {
   "type": "p",
   "html": "An organisation that can demonstrate a named human approved production changes is in a good position under any of those positions. One that cannot is betting on the lenient reading."
  },
  {
   "type": "h2",
   "text": "The supply chain dimension"
  },
  {
   "type": "p",
   "html": "Beyond compliance, there is a straightforward security argument."
  },
  {
   "type": "p",
   "html": "If code generation and code approval are both automated, an attacker who influences the generation step — through a poisoned dependency, a manipulated issue description, injected content in a linked document — has a path to production with no independent check."
  },
  {
   "type": "p",
   "html": "The review agent is reading the same context that was manipulated. It is not independent in the sense the control requires."
  },
  {
   "type": "h2",
   "text": "What to bind"
  },
  {
   "type": "code",
   "text": "# The reviewer signs the state of the change, not the PR number\n{\n  \"repository\":  \"platform/payments\",\n  \"pull_request\": 4821,\n  \"head_sha\":    \"7f3a91c8e2b7d4056891fa2c73e1b9d40a2f8c31\",\n  \"base_sha\":    \"c19e4a77b3d2018845ff6e91c2a70b338d14e9aa\",\n  \"files\":       47,\n  \"additions\":   1203,\n  \"deletions\":   88,\n  \"reviewer\":    \"e.vanterpool@example.com\",\n  \"reviewed_at\": \"2026-08-23T09:14:22Z\"\n}\n\n# Signed with the reviewer's credential, user verification required.\n# Merge gate recomputes head_sha and refuses on mismatch."
  },
  {
   "type": "p",
   "html": "Binding <code>head_sha</code> closes the post-approval push — a commit added after review no longer merges under the old approval. That is a real defect in most current setups, independent of the AI question."
  },
  {
   "type": "h2",
   "text": "Tiering rather than blanket policy"
  },
  {
   "type": "p",
   "html": "Requiring a signature on every merge would be counterproductive: high-volume friction produces reflexive signing, which is the rubber stamp with cryptography attached."
  },
  {
   "type": "table",
   "head": [
    "Change class",
    "Gate"
   ],
   "rows": [
    [
     "Documentation, tests, internal tooling",
     "Automated review is sufficient"
    ],
    [
     "Ordinary application code",
     "Automated review plus human approval, unsigned"
    ],
    [
     "Authentication, authorisation, payment or cryptographic code",
     "Signed human approval bound to head SHA"
    ],
    [
     "Infrastructure, deployment configuration, secrets handling",
     "Signed human approval bound to head SHA"
    ],
    [
     "Dependency additions and version bumps in production paths",
     "Signed human approval bound to head SHA"
    ]
   ]
  },
  {
   "type": "p",
   "html": "In most repositories the bottom three rows are a minority of merges. Identifying them by path pattern takes an afternoon."
  },
  {
   "type": "h2",
   "text": "What to tell your auditor now"
  },
  {
   "type": "p",
   "html": "Do not wait to be asked. Three things are worth being able to state plainly: which repositories permit automated approval, which change classes require a named human, and how you evidence the second."
  },
  {
   "type": "p",
   "html": "An organisation with those answers is having a conversation. One without them is having a finding."
  },
  {
   "type": "h2",
   "text": "What changed on 1 September 2026"
  },
  {
   "type": "p",
   "html": "GitHub's changelog records that Copilot code review now includes an approval assessment in every review, and that administrators can authorise Copilot to submit an approving review which counts toward the repository's required-approvals rule. It is off by default and configurable at enterprise, organisation and repository level, and repository administrators can restrict which file paths Copilot may approve. If new commits land after Copilot approves, its approval is dismissed exactly as a human reviewer's would be."
  },
  {
   "type": "p",
   "html": "Those controls are well designed, and they are the reason this is a governance question rather than an incident. The default is safe. What matters is that the decision is now yours to make explicitly, for each repository, and that your audit evidence has to say which way you made it."
  },
  {
   "type": "table",
   "caption": "Where the approval decision now sits",
   "head": [
    "Level",
    "What it can set"
   ],
   "rows": [
    [
     "Enterprise",
     "Off for the whole enterprise, or delegate to organisations"
    ],
    [
     "Organisation",
     "On org-wide, delegate to repositories, enable for specific repositories, or off"
    ],
    [
     "Repository",
     "On or off, and which file paths Copilot may approve"
    ]
   ]
  },
  {
   "type": "h2",
   "text": "Objections and honest limits"
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“It is off by default, so there is nothing to do.”</strong> There is one thing: know, per repository, whether it is on, and be able to say so. An auditor asking how you evidence human review of production changes will not accept “we think it is off”."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">“AI review catches more than a tired human.”</strong> Often true, and not the point. The control is standing in for accountability, not for defect detection. Run both, and be clear which one the framework is relying on."
  },
  {
   "type": "p",
   "html": "<strong style=\"font-weight:600\">What a signed approval does not fix:</strong> a reviewer who signs without reading. Gating every merge guarantees that outcome, which is why the signed set has to be the minority of changes where review genuinely matters."
  }
 ],
 "faq": [
  {
   "q": "Do audit frameworks require a human reviewer?",
   "a": "Most predate the question and do not say explicitly. Auditors are forming positions, and being able to demonstrate named human approval for sensitive changes is defensible under any of them."
  },
  {
   "q": "Is AI code review a bad idea?",
   "a": "No. It catches real defects and is a reasonable part of a pipeline. The problem is it satisfying a control that was standing in for human accountability."
  },
  {
   "q": "Should every merge require a signature?",
   "a": "No. High-volume friction produces reflexive signing. Gate authentication, payment, cryptographic, infrastructure and dependency changes — usually a minority of merges."
  },
  {
   "q": "Why bind the head SHA?",
   "a": "Otherwise a commit pushed after approval merges under the old approval. That defect exists in most setups today, regardless of AI."
  },
  {
   "q": "Can Copilot's approval satisfy required reviews?",
   "a": "Yes, since 1 September 2026, if an administrator enables it. It is off by default and can be scoped at enterprise, organisation and repository level, including by file path."
  },
  {
   "q": "Does the approval survive new commits?",
   "a": "No. If commits are pushed after Copilot approves, the approval is dismissed exactly as a human reviewer's would be, and a fresh review can be requested."
  },
  {
   "q": "Do audit frameworks forbid this?",
   "a": "Most predate the question and do not say explicitly. Being able to demonstrate that a named human approved sensitive changes is defensible under any reading; being unable to is a bet on the lenient one."
  }
 ],
 "sources": [
  {
   "t": "AICPA Trust Services Criteria (SOC 2)",
   "u": "https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022"
  },
  {
   "t": "ISO/IEC 27001:2022 — Information security management",
   "u": "https://www.iso.org/standard/27001"
  },
  {
   "t": "PCI DSS v4.0 document library",
   "u": "https://www.pcisecuritystandards.org/document_library/"
  },
  {
   "t": "GitHub — About protected branches",
   "u": "https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches"
  },
  {
   "t": "GitHub Changelog — Copilot code review can now approve pull requests",
   "u": "https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests/"
  },
  {
   "t": "GitHub Docs — approving a pull request with required reviews",
   "u": "https://docs.github.com/en/pull-requests/how-tos/review-pull-requests/approving-a-pull-request-with-required-reviews"
  },
  {
   "t": "GitHub Docs — using Copilot code review",
   "u": "https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/copilot-code-review"
  }
 ],
 "related": [
  {
   "slug": "sigstore-vs-manav-signing-artifacts-prove-approved-deployment",
   "title": "Signing artifacts does not prove who approved the deployment",
   "category": "Comparison"
  },
  {
   "slug": "soc-2-common-criteria-6-8-replacing-slack",
   "title": "Replacing Slack screenshots with cryptographic proof",
   "category": "Developer"
  },
  {
   "slug": "servicenow-ticket-manipulation-preventing-unauthorized-admin-elevation",
   "title": "When the approval record is a database row",
   "category": "Developer"
  }
 ],
 "image": "https://cdn.twc.sh/images/igcache/AI%20Approves%20The%20Pull%20Request/1200_630/blog.jpg",
 "wordcount": 1196,
 "url": "/blog/github-copilot-pr-approval-soc2-supply-chain-risk.html",
 "reading_time": "5 min read",
 "seo_title": "When an AI approves the pull request",
 "hub": {
  "slug": "topics/software-supply-chain",
  "title": "Software supply chain authorization"
 },
 "answer": "Yes. Since 1 September 2026 administrators can authorise Copilot code review to submit an approving review that counts toward a repository's required-approvals rule. Branch protection counts approvals; it has never checked that a human read the diff. That proxy held only while clicking required a person.",
 "answer_q": "Can GitHub Copilot's approval satisfy branch protection, and what does that break?",
 "entities": [
  {
   "name": "GitHub Copilot",
   "type": "SoftwareApplication",
   "url": "https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/copilot-code-review",
   "primary": true
  },
  {
   "name": "GitHub",
   "type": "Organization",
   "url": "https://github.com/"
  }
 ],
 "glossary": [
  {
   "term": "Branch protection",
   "def": "Repository rules that must be satisfied before a merge, typically a required number of approving reviews and passing checks. Both are booleans about repository state."
  },
  {
   "term": "Required approvals",
   "def": "The count of approving reviews a pull request needs. It has never distinguished a reviewer who read the diff from one who did not."
  },
  {
   "term": "Head SHA binding",
   "def": "Tying an approval to the exact commit reviewed, so that pushing a new commit invalidates it rather than inheriting it."
  }
 ],
 "checklist": {
  "title": "Deciding this per repository",
  "id": "decide",
  "desc": "What to settle before an auditor or a customer asks.",
  "steps": [
   {
    "name": "Inventory where it is enabled.",
    "text": "Enterprise, organisation and repository settings, plus any path restrictions. Write the answer down."
   },
   {
    "name": "Classify your change types.",
    "text": "Documentation and tests, ordinary application code, and the sensitive set — authentication, payment, cryptography, infrastructure, dependencies."
   },
   {
    "name": "Require a named human on the sensitive set.",
    "text": "Identify it by path pattern; in most repositories it is a minority of merges."
   },
   {
    "name": "Bind the approval to the head SHA.",
    "text": "So a commit pushed after review cannot merge under the old approval — a defect that exists in most setups regardless of AI."
   },
   {
    "name": "Tell your auditor first.",
    "text": "Which repositories permit automated approval, which classes require a human, and how you evidence the second."
   }
  ]
 },
 "cta": {
  "title": "Where this fits in Manav",
  "html": "Manav binds the reviewer's signature to the head SHA and the diff statistics, so the approval covers the code that merges rather than the pull request number. Verification is a signature check an auditor can run against a published key, with no access to your systems.",
  "href": "../docs.html",
  "label": "See change-control receipts"
 }
}