When AI can approve a pull request

An approval is not just a comment on a pull request. In many repositories, it is a control-flow decision: the change has satisfied enough conditions to move closer to production.

That is why AI approving a pull request is not merely an automation feature. It is a governance decision.

GitHub’s September 1, 2026 changelog introduced an opt-in capability that lets Copilot code review submit an approval that counts toward a repository’s required-approval rule. The capability is off by default, can be configured at the enterprise, organization, and repository levels, and can be limited by file path. GitHub also describes a separate approval assessment that appears in every Copilot review, but that assessment does not count toward merge requirements until an administrator enables approvals. GitHub’s announcement is precise about that distinction.

The interesting question is not whether a model can write the word “approved.” It is whether a team can explain why that approval was allowed to influence delivery.

This changes the design problem. We need to define the scope an AI reviewer may see, the changes it may approve, the evidence it must produce, the people who own the policy, and the conditions that force a human decision. Fast feedback is valuable only when the system can preserve the reasoning behind a release decision.

An approval is a stronger statement than a review

The words review, assessment, and approval are often used as if they describe the same event. They do not.

Signal	What it tells the team	Should it affect merge policy?
Review comments	The tool found observations, questions, or suggestions	Not by itself
Approval assessment	The tool judges the pull request ready to approve	Not by itself
Approval	The configured reviewer is willing to satisfy an approval condition	Only when policy explicitly allows it
Required checks	Automated evidence met a defined technical condition	Yes, within the limits of the check

A review comment can be useful without being authoritative. A test can pass without proving that the right behavior was tested. An approval, however, is interpreted by branch protection as a reason the change may proceed.

That makes an approval closer to a delegated authorization than to a text-generation result. The organization is saying that a particular actor, under particular conditions, is allowed to participate in the decision to ship.

This distinction also explains why the feature being opt-in matters. Enabling it is not the same as installing a code-review bot. It changes the set of actors that can satisfy a repository control. The administrator is making a statement about acceptable risk, not just reducing a queue.

GitHub’s behavior after a new commit reinforces the point: when new commits are pushed after Copilot approves, the approval is dismissed just as a human reviewer’s approval would be. A fresh review is required. That is a useful invariant because an approval should describe a specific revision, not a pull request’s general intention.

The first boundary is consequence, not file extension

The most tempting way to configure AI approval is to create a list of paths:

• documentation can be approved;
• tests can be approved;
• application code needs a person;
• infrastructure is excluded.

Path-based rules are a practical control, and GitHub’s repository-level setting can limit which file paths Copilot is allowed to approve. But a path is only a proxy for consequence. A small change in a “safe” directory can still change a public contract, bypass authorization, or alter the meaning of a test.

The better question is: What can this change affect if the reviewer is wrong?

I would start with three risk classes.

Low-consequence changes

These changes have a narrow blast radius, are easy to inspect, and have a reliable validation path. Examples might include a documentation correction, a deterministic formatting change, or a test update that does not alter production behavior.

Even here, “low consequence” should not mean “unimportant.” A documentation change can affect an operational procedure. A test-only change can remove the only assertion protecting a critical path. The classification should describe the expected blast radius, not the file suffix.

Conditional changes

These changes may be eligible for AI approval when additional evidence is present. Examples include a small bug fix in a well-tested module, a localized UI change, or a dependency update with a locked and reviewed diff.

The conditions might include:

• the change stays within an owned module;
• the relevant contract tests pass;
• no public API, database schema, or permission boundary changes;
• the diff does not modify deployment or runtime configuration;
• the reviewer can inspect all relevant context;
• and a human owner remains responsible for the area.

Conditional approval is useful because it reflects how engineering teams actually work. Risk is not binary. It is a combination of the change, the evidence, the context, and the ability to recover.

Human-required changes

Some changes should not rely on an AI approval as the only approval. I would put these in the human-required class:

• authentication, authorization, tenant isolation, or data access rules;
• billing, payments, quotas, or customer-visible entitlements;
• database migrations, retention policies, and irreversible backfills;
• production infrastructure, secrets, network policy, or deployment workflows;
• public API and event contracts;
• security controls and privacy-sensitive processing;
• changes to code ownership or branch protection itself;
• and novel architecture where the main risk is a trade-off rather than a syntax error.

These areas need contextual judgment and accountable ownership. An AI tool can still review them, summarize the diff, identify missing tests, and point to evidence. The boundary is that its output should inform the human decision rather than silently replace it.

Context is a security boundary

An AI reviewer cannot evaluate what it cannot see. That sounds obvious, but it is easy to confuse a successful response with a complete review.

The model may receive the pull-request diff and miss the configuration that changes its behavior. It may see a service method and miss the middleware that establishes tenant scope. It may read a test fixture without seeing the production schema. It may have access to a generated file that looks authoritative even though the next build will replace it.

Context selection is therefore part of the approval policy.

GitHub’s September 2, 2026 changelog says that the Copilot app and Copilot CLI now respect content exclusion policies configured by enterprise, organization, and repository administrators. Excluded files are not used as context across those agentic workflows. The content-exclusions announcement is a meaningful privacy and governance improvement.

It is also a reminder that exclusion is not the same as comprehension. If a critical file is excluded, the system has to represent that blind spot. The reviewer should not receive an approval that sounds complete when the model was deliberately prevented from seeing a dependency that could change the conclusion.

At minimum, an approval workflow should make these facts visible:

• which revision was reviewed;
• which files and symbols were included;
• which files were excluded by policy;
• whether generated output was treated as evidence or ignored;
• which tests and configuration sources were inspected;
• and whether the model reported an unresolved dependency.

An exclusion policy protects sensitive content. It does not grant permission to approve changes whose correctness depends on that content.

This is the same principle I use for AI-assisted code analysis: the tool should show the scope before asking the developer to trust the result. AI-assisted code analysis with evidence is useful here because it treats scope, evidence, confidence, and uncertainty as separate parts of the artifact.

Approval needs an owner and an exception path

Governance fails when a policy exists but nobody owns its meaning.

GitHub’s configuration hierarchy creates useful control points: enterprise administrators can keep approvals off or delegate the decision to organizations; organization administrators can set an organization-wide policy or leave the choice to repositories; repository administrators can enable or disable the feature and constrain approval paths.

Those controls answer where a policy can be set. They do not answer who is responsible for reviewing whether the policy still makes sense.

For each repository, I would want a named owner or owning team for:

1. the list of AI-eligible change classes;
2. the paths and repositories covered by the policy;
3. the required checks that make an approval meaningful;
4. the process for handling exceptions;
5. and the evidence used during periodic review.

The exception path matters because real pull requests do not stay inside neat categories. A documentation-only diff may update an incident runbook. A dependency bump may include a transitive change to a parser. A test refactor may weaken coverage while leaving the test count unchanged.

When the system detects an exception, the safe result is not a more confident sentence. It is a transition to human review.

An illustrative policy might look like this:

# Illustrative policy, not a drop-in GitHub configuration file.
aiApproval:
  default: human-required
  eligible:
    - class: documentation
      paths: ["docs/**"]
      requires: ["docs-build", "link-check"]
    - class: localized-change
      paths: ["src/components/**"]
      requires: ["unit-tests", "visual-regression"]
  alwaysHuman:
    - "src/auth/**"
    - "src/billing/**"
    - "db/migrations/**"
    - ".github/workflows/**"
  onUncertainty: human-required
  onMissingContext: human-required

The important lines are not the path names. They are the defaults and the transitions. Uncertainty and missing context do not become approval merely because the rest of the diff looks harmless.

Evidence should travel with the approval

An approval without evidence is difficult to audit and difficult to improve. It leaves the team with a status rather than a decision record.

The evidence does not need to be a long essay. It needs to be specific enough for another person to understand what the tool checked and what it could not establish.

For a code change, I would expect an AI approval to summarize at least:

• the behavior that changed;
• the contracts or interfaces affected;
• the test commands that ran and their outcomes;
• the authorization, tenant, or data boundaries touched;
• the failure paths considered;
• the files intentionally excluded from context;
• the assumptions made by the review;
• and the conditions that would invalidate the approval.

A structured result is easier to inspect than a paragraph that combines all of these claims:

{
  "decision": "approve",
  "revision": "abc1234",
  "scope": {
    "included": ["src/reports/**", "tests/reports/**"],
    "excluded": ["infra/production/**"]
  },
  "evidence": [
    {
      "claim": "The report query preserves tenant scope.",
      "source": "src/reports/buildReportQuery.ts:42",
      "validation": "report-scope-tests"
    }
  ],
  "uncertainties": [],
  "humanRequired": false
}

This is an example of an evidence shape, not a claim about GitHub’s internal output format. The design principle is that the approval should be decomposable. A reviewer should be able to challenge one claim without having to reject an opaque blob of generated prose.

The distinction between observation and interpretation is important here.

Observation: the service calls a query builder with tenantId and sourceId.

Interpretation: the report is protected against cross-tenant and cross-source access.

The second statement may be correct, but it requires tracing the complete path. Does the query builder preserve both values? Does another endpoint bypass the service? Are the identifiers authorized before the query runs? Does the test cover a mismatched source? AI review is valuable when it accelerates those questions. It becomes dangerous when it turns a partial observation into a full approval.

Tests are evidence, not a substitute for judgment

Required checks make approval policies operational, but green checks do not prove that a change deserves to ship.

The obvious failure mode is a test suite that does not cover the changed behavior. A second failure mode is more subtle: the tests cover the implementation but not the contract. A query may return the expected rows for a happy path while leaking data when a source belongs to another tenant. A migration may succeed on a fresh database while failing during a rolling deployment. A feature flag may leave the new code unreachable in the environment that matters.

An AI approval policy should therefore ask not only “Did tests pass?” but also:

• Did the relevant tests change with the behavior?
• Is the test population representative of the real boundary?
• Are negative and failure cases covered?
• Do list, count, export, and summary paths use the same scope?
• Is the test running against the same configuration shape used in delivery?
• Is there a rollback or recovery path if the assumption is wrong?

This is where testing backend systems as a boundary problem connects to AI approval. The goal is not to produce more green marks. It is to make the important system boundary observable and testable.

The approval should be blocked when the evidence is missing, not when the model fails to write a persuasive explanation of why missing evidence does not matter.

Common failure modes

Allowing AI approval introduces recognizable ways for a delivery system to become weaker while appearing faster.

A safe path with an unsafe dependency

A path rule permits changes under src/components/**, but a component imports a shared authorization helper or controls a customer-visible entitlement. The diff is local; the consequence is not.

Mitigation: classify imports, ownership, public contracts, and runtime configuration as part of the review scope. Path rules should be a first filter, not the complete risk model.

A green suite with the wrong assertion

The relevant test command passes, but the changed behavior is not asserted. An AI reviewer can report the check accurately while still missing the product-level defect.

Mitigation: require behavior-specific checks and review test diffs as carefully as production diffs. Measure escaped defects and reviewer corrections, not only check completion.

Approval after the context changed

A new commit changes the behavior after an approval. GitHub dismisses Copilot’s approval in this case, which preserves an important revision-specific rule. The remaining risk is workflow confusion: a developer may assume the old approval still represents the current state or may request a review before the full change is ready.

Mitigation: show the reviewed revision prominently and make stale approvals impossible to interpret as current evidence.

Excluded context creates a false sense of coverage

A file is excluded for privacy or policy reasons, but the changed code depends on it. The model cannot inspect the dependency and still returns a confident summary.

Mitigation: represent excluded or unavailable context as a hard condition. If the missing file could affect correctness, require a human who is authorized to inspect it.

Review comments become approval theatre

The team starts treating an AI-generated overview as proof that a human no longer needs to think. The approval becomes a ritual attached to a dashboard rather than a decision supported by evidence.

Mitigation: keep the reviewer accountable for the change class, not for the existence of a generated comment. Require meaningful evidence and allow the reviewer to reject the AI decision without friction.

The policy quietly expands over time

A low-risk path accumulates more responsibilities. A shared utility becomes a security boundary. A documentation generator begins writing configuration. A repository’s recovery process changes, but its AI approval policy does not.

Mitigation: review eligible paths and outcomes on a regular schedule. Governance is a maintained artifact, not a one-time settings change.

Measure safety and decision quality

The easiest metric to celebrate is time to merge. It is also the least sufficient.

If AI approvals are working, a team may see faster feedback and less routine reviewer effort. Those benefits matter. They have to be measured beside the cost of incorrect approvals and the quality of the evidence.

I would establish a baseline before enabling approvals and then compare AI-eligible changes with similar human-only changes. Useful signals include:

• time from pull request open to first useful review;
• time from ready-for-review to merge;
• human override, rejection, and escalation rates;
• reviewer correction time for AI findings;
• percentage of approvals with complete evidence;
• escaped defects and rollbacks by change class;
• incidents involving authorization, data scope, or production configuration;
• frequency of stale approvals after new commits;
• and the number of policy exceptions that needed human judgment.

These signals should be interpreted together. A low escalation rate can mean the tool is effective. It can also mean that people have stopped challenging it. A shorter merge time can mean less waiting. It can also mean that the organization has weakened a control without noticing the downstream cost.

The most useful question is not “How many pull requests did AI approve?” It is “Did the team make equally good or better decisions with less time spent searching for evidence?”

That question keeps the system focused on engineering outcomes rather than automation volume.

A safer rollout is deliberately boring

I would not enable AI approval across every repository on the first day. A staged rollout gives the organization a chance to learn which assumptions were wrong.

1. Inventory the existing control

Document current branch protection, required approvals, code ownership, required checks, deployment gates, and exception paths. Identify where an approval is a compliance requirement, where it is a team convention, and where it is simply a signal.

2. Classify changes by consequence

Use real pull requests from the repository. Mark which changes were routine, which required domain expertise, and which would have been expensive or dangerous to reverse. Do not design the policy from file names alone.

3. Run in assessment or shadow mode

Start by collecting AI review assessments without letting them satisfy merge requirements. Compare the findings with human reviews. Look for systematic omissions: configuration, ownership, negative cases, data boundaries, and operational behavior.

4. Enable one narrow eligibility class

Choose a repository or path where the consequence is low, the owner is clear, and the validation is strong. Keep the default human-required. Treat uncertainty, missing context, and policy exceptions as escalation conditions.

5. Audit outcomes before expanding

Review not only successful merges but also rejected approvals, post-merge fixes, and cases where humans corrected or overruled the tool. If the evidence is not useful, improve the workflow before widening the permission.

6. Preserve a rollback switch

The organization should be able to turn off AI approvals without changing the codebase or waiting for a model update. A governance control is incomplete if it cannot be withdrawn quickly when the risk changes.

Where I would draw the boundary

I would allow AI approval to satisfy a required-approval condition only for changes with a narrow, reversible blast radius and a testable evidence path. I would begin with a small set of repositories and paths, keep the default human-required, and review the policy as the codebase evolves.

I would not let an AI be the sole approver for authentication, authorization, tenant or source boundaries, billing, migrations, infrastructure, public contracts, security controls, or changes whose main risk is an architectural trade-off. In those cases, AI can make the human review faster and more precise, but accountability should remain with a person or an explicitly responsible team.

The boundary is not “AI versus humans.” It is delegated judgment versus accountable judgment.

GitHub’s new capability makes that delegation configurable. The engineering work is deciding whether the delegation is justified for a particular change, and keeping enough evidence to explain the decision later.

Conclusion

AI pull request approval can be useful, but only when approval remains a meaningful statement. That requires more than enabling a setting.

The system needs explicit change classes, narrow permissions, visible context boundaries, revision-specific evidence, accountable ownership, strong tests, measurable outcomes, and a reliable path back to human review. Content exclusions help protect sensitive code, but unavailable context must also reduce confidence. File paths help constrain risk, but they cannot replace consequence-based classification. Green checks help validate behavior, but they cannot decide whether the right behavior was tested.

The real shift is not fewer reviews. It is making context, permissions, ownership, and testable evidence first-class parts of delivery.

Where would you draw the boundary for an AI approval in your codebase?

Sources

• GitHub: Copilot code review can now approve pull requests
• GitHub: Content exclusions generally available in Copilot app and CLI