Using AI-Approved Pull Requests Safely with GitHub Copilot

GitHub Copilot can now do more than review a pull request and leave comments.

When Copilot approvals are enabled, it can submit an approving review, and that approval can count toward a repository's required approval rules. The feature is currently in public preview and is disabled by default.

That changes an important part of the pull request workflow.

Previously, teams could use Copilot to find possible bugs, security problems, and maintainability issues while keeping the actual approval decision with human reviewers.

Now an organization can configure Copilot to provide an approval that participates in the merge process.

That can be useful, but it also means repository administrators need to think carefully about where AI approvals should be allowed.

The safest approach is not to ask whether Copilot approvals are "good" or "bad."

Instead, ask a more practical question:

Where does an AI approval fit safely into our existing review and deployment process?

What Copilot Approval Actually Does

By default, Copilot code review leaves a Comment review.

That means its review does not satisfy a repository's required approval count.

When approvals are enabled, Copilot can instead submit an Approve review. GitHub can then treat that approval as satisfying the repository's required-approval rule, depending on the repository configuration.

The basic workflow becomes:

Pull Request
     |
     v
Copilot Code Review
     |
     v
Approval Assessment
     |
     v
Copilot Approval Enabled?
     |
     +---- No ----> Comment Review
     |
     +---- Yes
             |
             v
       Approving Review
             |
             v
       Repository Rules

The approval assessment and the actual approval are separate.

Every Copilot review includes an approval assessment, but that assessment alone does not count toward merge requirements.

Why the Distinction Matters

Suppose Copilot reviews a pull request and reports:

Approval assessment:
Ready to approve

That does not automatically mean the pull request has received an approval.

If Copilot approvals are disabled, it remains a review assessment.

If approvals are enabled, Copilot can submit the actual approving review.

So there are effectively two steps:

Assessment
    |
    v
"Ready to approve"
    |
    v
Approval configuration
    |
    v
Actual approval

This distinction is important when designing branch protection and merge rules.

Why Teams Should Not Enable It Everywhere Immediately

A repository is not just a collection of source files.

It can contain:

• Application code

• Infrastructure code

• Database migrations

• Deployment scripts

• Security configuration

• GitHub Actions workflows

• Production configuration

A small change in one of these areas can have a very different impact from a change to a README file.

For example:

README.md

and:

.github/workflows/deploy-production.yml

may both be valid pull request changes, but they do not carry the same operational risk.

GitHub allows repository administrators to restrict which file paths are eligible for Copilot approvals to count toward merge requirements.

This provides a useful control for organizations that want to introduce AI approvals gradually.

Start With Repository Classification

Before enabling Copilot approvals, classify your repositories.

A simple model could be:

The exact classification should come from your organization's risk model.

The purpose is to avoid applying one review policy to every repository.

Use Custom Properties to Target Repositories

If your organization already uses GitHub repository custom properties, they can help identify groups of repositories.

For example:

criticality = high
environment = production

You can use repository metadata as part of broader governance and ruleset management. GitHub documents custom properties as a way to organize repositories and target them with rulesets.

A conceptual model could be:

Repository
    |
    v
Custom Properties
    |
    +-- criticality = high
    +-- environment = production
    +-- application-type = API
    |
    v
Repository Rules
    |
    v
Review Requirements

This is easier to maintain than manually managing hundreds of repository names.

Keep Human Approval for High-Risk Changes

One practical approach is to allow Copilot to review all pull requests but keep human approval requirements for sensitive repositories.

For example:

All Pull Requests
       |
       v
Copilot Review
       |
       +----------------+
       |                |
       v                v
Low Risk            High Risk
       |                |
       v                v
Copilot + Tests     Human Approval

This lets teams benefit from automated review without treating AI approval as the only gate for high-impact changes.

GitHub itself recommends maintaining human review and states that Copilot is not guaranteed to find every issue.

Require Automated Tests

An approval should not be the only signal that a pull request is ready.

A practical pipeline might look like:

Pull Request
     |
     v
Build
     |
     v
Unit Tests
     |
     v
Integration Tests
     |
     v
Security Checks
     |
     v
Copilot Review
     |
     v
Human Review
     |
     v
Merge

For low-risk repositories, some of these gates may be lighter.

For production systems, the checks should normally be stronger.

The important point is that code review and automated validation solve different problems.

Use Copilot Review Before Human Review

One useful workflow is to have Copilot review the pull request before a developer spends time on the detailed review.

For example:

Developer
   |
   v
Open PR
   |
   v
Copilot Review
   |
   v
Fix obvious issues
   |
   v
Human Review
   |
   v
Merge

GitHub recommends using Copilot as part of the pull request lifecycle while keeping human review.

This can make human review more focused.

Instead of spending the first few minutes finding obvious issues, the reviewer can concentrate on architecture, business logic, and design decisions.

Configure the Review Effort

GitHub currently provides different review effort levels.

The documented options include:

• Lite

• Balanced

Lite provides more targeted feedback.

Balanced performs deeper analysis of complex logic, security-sensitive code, and cross-service changes, and can use more AI credits.

For example:

Simple repository
      |
      v
Lite Review


Complex production service
      |
      v
Balanced Review

The review effort should match the repository and workload.

Do not assume that choosing the deepest review automatically makes the approval safe.

Review depth is only one part of the process.

Use Repository Instructions

Copilot code review can use repository custom instructions.

For example:

.github/copilot-instructions.md

You could define review expectations such as:

# Code Review Guidelines

- Check all database changes for backward compatibility.
- Flag authentication and authorization changes.
- Check for missing cancellation tokens in long-running async operations.
- Review public API changes carefully.
- Do not recommend suppressing compiler warnings without justification.

GitHub documents repository custom instructions as a way to customize Copilot's review behavior.

This is useful because generic code review rules do not always match the requirements of a specific application.

Security Rules Can Be Included

Security-sensitive repositories can provide additional review guidance.

For example:

# Security Review

When reviewing authentication code:
- Check authorization boundaries.
- Check token validation.
- Check privilege escalation risks.

When reviewing database access:
- Check parameterization.
- Check sensitive data handling.
- Check logging of confidential information.

Copilot can use repository instructions and, where configured and relevant, agent skills and MCP context during code review.

This does not guarantee that every security issue will be found.

It simply gives the review more project-specific context.

Be Careful With MCP and External Context

Copilot code review can use configured MCP servers and agent skills when they are relevant to the review.

That can provide additional context from systems outside the immediate source files.

For example, a pull request description might reference an incident or issue that is available through a configured MCP integration.

This can make reviews more context-aware, but it also means administrators should understand what external context is available to the reviewer.

GitHub provides repository-level controls for whether Copilot code review can use MCP tools.

Before enabling external context broadly, understand:

• What data the tool exposes

• Who can access it

• What information can appear in review output

• Whether the data contains confidential information

• Which repositories are allowed to use it

Limit Which Files Can Count Toward Approval

This is one of the most practical controls.

GitHub allows repository administrators to specify file path patterns for Copilot approvals.

For example, an organization could decide that Copilot approvals can count only when every changed file matches approved patterns.

Conceptually:

Copilot Approval
       |
       v
Check Changed Files
       |
       +---- Allowed
       |       |
       |       v
       |    Can count
       |
       +---- Not allowed
               |
               v
          Human review

GitHub currently supports up to 15 file globs for this configuration.

This can provide a useful middle ground between:

Copilot can never approve

and:

Copilot can approve everything

Protect Sensitive Paths

Consider a repository containing:

src/
tests/
docs/
.github/workflows/
infrastructure/
security/

You might decide that Copilot approval should not count when changes involve:

.github/workflows/
infrastructure/
security/

The exact patterns should match your repository structure.

The principle is simple:

Use stricter review requirements for files that can have a larger operational or security impact.

Re-Review After New Commits

One of the important safeguards is what happens after approval.

Suppose Copilot reviews:

Commit A
Commit B

and approves the pull request.

Then the developer pushes:

Commit C

The pull request has changed.

GitHub dismisses the Copilot approval when new commits are pushed after the approval, and a new review can be requested.

The workflow becomes:

Review
  |
  v
Approval
  |
  v
New Commit
  |
  v
Approval Dismissed
  |
  v
Re-review

This prevents an old approval from silently applying to new code.

Enable Review on New Pushes

For teams that want continuous review, GitHub supports automatic Copilot reviews on new pushes.

This can be configured as part of automatic code review.

A workflow can therefore look like:

Push
 |
 v
Copilot Review
 |
 v
Fix
 |
 v
Push
 |
 v
Copilot Re-review

This is useful for pull requests that change significantly during development.

Treat Copilot-Generated Code Differently

There is another important scenario: a pull request created by Copilot itself.

Copilot cloud agent can create and modify pull requests, but GitHub's current documentation requires human review before those pull requests are merged. The cloud agent cannot approve or merge its own pull request.

This gives a useful separation:

Copilot Agent
     |
     v
Writes Code
     |
     v
Pull Request
     |
     v
Review
     |
     v
Human Decision
     |
     v
Merge

Do not assume that enabling Copilot approvals means an AI-generated pull request can automatically approve itself.

The permissions and capabilities are separate.

Protect GitHub Actions Workflows

GitHub Actions workflows deserve special attention.

A pull request changing:

.github/workflows/build.yml

can change what code runs in your CI environment.

It may affect:

• Secrets

• Permissions

• Deployment

• Build commands

• Third-party actions

• Release processes

For this reason, many teams should require human review for workflow changes.

A useful rule might be:

Application source changes
        |
        v
Copilot + Tests


Workflow changes
        |
        v
Copilot + Tests + Human Approval

The exact policy should depend on your security model.

Protect Infrastructure Code

Infrastructure changes deserve similar treatment.

Examples include:

Terraform
Kubernetes manifests
Cloud infrastructure
Deployment scripts
Network configuration
IAM policies

A change that compiles successfully can still cause a production outage.

Automated code review can identify suspicious patterns, but infrastructure changes should be evaluated against the intended deployment architecture.

Do Not Ignore Business Logic

AI review tools are strongest when they can inspect code and available context.

But business requirements can exist outside the repository.

Consider:

Requirement:
Customers cannot cancel an order
after shipment begins.

The implementation might compile correctly and pass tests while still violating that rule.

A human reviewer who understands the product requirement may catch the problem.

This is one reason GitHub recommends supplementing Copilot feedback with human review.

Use Security Scanning Alongside Copilot

Copilot code review is not a replacement for dedicated security tooling.

A production repository may use:

Copilot Review
      +
CodeQL
      +
Dependency Scanning
      +
Secret Scanning
      +
Tests

Each tool looks at a different aspect of the codebase.

For example, GitHub Code Quality can combine rules-based CodeQL analysis, test coverage information, and optional merge gating.

The right combination depends on the repository and organization.

Measure the Results

If your organization enables Copilot approvals, do not stop at configuration.

Measure what happens.

Useful metrics include:

Review duration
Review comments
False-positive rate
Re-review frequency
Build failures
Escaped defects
Security findings
Human review time

You can compare the process before and after introducing Copilot review.

The goal is not simply to maximize the number of AI-approved pull requests.

The goal is to build a review process that catches problems without creating unnecessary friction.

Watch for False Confidence

One of the biggest risks with automated approval is psychological rather than technical.

A developer may see:

Approved

and assume:

The code must be correct.

That assumption is unsafe.

An approval means that Copilot's review reached an approval result under the configured review process.

It does not prove that:

• The business requirement is correct

• Production behavior is correct

• Every security issue was detected

• Performance is acceptable

• The architecture is appropriate

• External dependencies behave correctly

GitHub explicitly notes that Copilot can make mistakes and that its feedback should be validated carefully.

A Safer Adoption Model

A gradual rollout can reduce surprises.

Stage 1: Review Only

Start with:

Copilot Review
+
Human Approval

Measure the quality of the review.

Stage 2: Automatic Review

Enable automatic reviews for suitable repositories.

PR
 |
 v
Automatic Copilot Review
 |
 v
Human Approval

Stage 3: Limited AI Approval

Enable Copilot approvals for selected low-risk repositories or paths.

Selected Repository
 |
 v
Copilot Approval
 |
 v
Required Checks
 |
 v
Merge

Stage 4: Expand Carefully

Only expand after reviewing the results and adjusting repository rules.

This is easier to manage than enabling approvals across an entire enterprise on day one.

A Practical Policy Example

An organization could define something like:

Documentation
    |
    +-- Copilot review
    +-- Automated checks

Internal applications
    |
    +-- Copilot review
    +-- Tests
    +-- Copilot approval allowed

Production applications
    |
    +-- Copilot review
    +-- Tests
    +-- Security checks
    +-- Human approval

Infrastructure and security
    |
    +-- Copilot review
    +-- Automated checks
    +-- Human approval

This is not a universal policy.

It is an example of how an organization can separate review requirements according to risk.

Practical Checklist

Before enabling Copilot approvals, check:

This checklist gives teams a starting point for evaluating the workflow before changing merge policies.

Common Mistakes

Enabling Approval for Every Repository

Different repositories have different risks.

Removing Human Review

Copilot should not become the only reviewer for important code.

Ignoring Workflow Files

CI/CD configuration can be security-sensitive.

Treating Approval as Proof of Correctness

An approval is not a guarantee.

Forgetting New Commits

A new commit can invalidate the previous review.

Skipping Tests

Code review and automated testing serve different purposes.

Giving Copilot Too Much External Context

Review MCP and agent integrations carefully before enabling them across sensitive repositories.

Summary

GitHub Copilot can now submit approving pull request reviews when administrators enable the feature. Those approvals can also count toward repository merge requirements when that option is enabled. The capability is currently in public preview.

The safest way to use it is to treat AI approval as one part of a broader engineering process.

A practical workflow looks like:

Pull Request
     |
     v
Automated Tests
     |
     v
Copilot Review
     |
     v
Security Checks
     |
     v
Approval Rules
     |
     +---- Low Risk ----> Copilot Approval
     |
     +---- High Risk ---> Human Approval
     |
     v
Merge

Use repository-specific instructions, automated testing, security scanning, path restrictions, and appropriate human review to provide additional controls.

Also remember that Copilot-generated pull requests remain subject to human review and merge controls.

The useful way to introduce AI approvals is gradually: start with code review, measure its results, enable approvals for appropriate repositories or paths, and keep stronger human controls around production, infrastructure, security, and other sensitive changes.