Five questions for merging an AI PR
A pull request written by an AI coding agent should neither receive easier merging nor be rejected simply because AI wrote it.
Baseline merge conditions should apply regardless of author. Protect important branches, pass required checks against the current revision, and obtain accountable approval from someone who understands the impact. AI involvement adds evidence about agent permissions, provenance, and reviewability.
A useful merge decision asks five questions.
- Did the change follow the protected branch’s normal PR path?
- Were all required checks executed against the revision being merged?
- Did the appropriate people approve the latest diff for this change type?
- Can the team trace who produced the change and under what conditions?
- Are exceptions accompanied by reasons, accountable owners, and post-review schedules?
NIST SSDF recommends defining security-check criteria, recording approvals, rejections, and exceptions, and retaining code-review, analysis, and executable-code test results in the development process. SLSA Source Track also treats protected branches, technical controls, source provenance, and understandable change displays as assurance elements. Whether the author is human or an agent is one input to this structure, not a replacement for merge policy.[6]
Protected branches come before AI-specific rules
Teams may start managing AI PRs by adding labels and checklists. Those checklists offer little protection if direct pushes to the default branch remain possible, failed checks are only warnings, or administrators can bypass rules without records.
GitHub, GitLab, Bitbucket, and Azure Repos differ in terminology and implementation, but provide protected branches, PR or MR paths, required checks, approvals, and direct-push restrictions. The common baseline is enforcing these controls as actual merge conditions.[7]
Shared default and release branches should apply at least these principles.
· Block direct pushes and force pushes by default.
· Require changes to arrive through PRs.
· Prevent merging when required checks fail or have not run.
· Reconfirm approval of the latest changes after new commits.
· Limit bypass rights to a small set of designated roles.
The important fact is not a green UI indicator, but which system produced the result for which revision. GitHub rulesets recognize that people or integrations with write access can set statuses and allow a specific GitHub App to be designated as an expected issuer. Apply the same principle to internal checks. Without linked check names, execution identities, target commits, and result artifacts, a green indicator is insufficient evidence.[7]
Evidence connected from requirement to approval — Link requirements, tests, defect actions and approval records so teams judge quality consistently.
Required Checks mean required evidence, not merely that a check existed
Applying identical checks to every PR is easy to administer but may not match risk. The same checks for a documentation typo and an IAM policy change can be excessive for the former and insufficient for the latter.
This article divides checks into four layers.
Baseline integrity checks use builds, static analysis, and required team tests to establish that a change preserves repository quality conditions.
Security checks find secrets, vulnerable code patterns, and security-policy violations.
Dependency checks examine direct and transitive changes in manifests and lockfiles, vulnerabilities, licenses, and supply sources.
Change-specific checks provide evidence such as IaC plans, permission diffs, workflow permissions, and reproducibility of generated output.
The exact test selection depends on change impact and regression risk, a separate regression-scoping problem. This article requires the selected checks to run before merging and ties their results to the current head revision.
Do not treat missing or unevaluable security results as success. GitLab security approval policies support fail-closed behavior requiring additional approval when scanner results are missing or policy evaluation is impossible. SLSA also requires evidence that claimed technical controls were continuously applied. In particular, distinguish no results from no problems in PRs changing permissions, secrets, or deployment paths.[8]
AI review supplements evidence; it does not automatically transfer human responsibility
AI code review can quickly identify repeated patterns, possible omissions, and code explanations. Its output alone does not establish that human approval requirements have been met.
GitHub Copilot code review currently leaves comments rather than Approve or Request changes decisions. It does not count toward required approvals or block merging by itself. Atlassian Rovo Dev documentation also says it may leave no review comments on large PRs and automatically skips some files, including dependency lockfiles and binaries.[9]
These examples do not impose identical limitations on every AI review product. They do establish a clear principle.
Using AI review requires visibility into what it inspected and what it did not.
AI review output can support required checks and human review. Do not label a PR simply AI reviewed when review did not run or excluded some files.
Changes that require human approval
Shared default branches generally need approval from someone other than the change author. When an agent produces a change, separate the person directing and submitting its work from the person independently approving the actual diff.
In the current GitHub Copilot agent flow, approval by the person who assigned the task may not count as a required approval, so a separate reviewer is needed. GitHub and Azure Repos also provide controls requiring approval from someone other than the latest pusher.[10]
At minimum, make human approval by the responsible domain owner a merge condition for the following changes.
Secrets and credentials
Do not put actual API keys, tokens, passwords, or private keys in source code or PR descriptions. A credential found by a secret scanner should first block merging and be removed, not merely become a review item. If it was pushed remotely, also confirm revocation or replacement.[11]
Passing a secret scan does not prove that secrets are absent. GitLab Secret Push Protection uses high-confidence patterns to reduce latency and false positives and may miss tokens with custom prefixes. Platform or security owners must therefore review changes to secret-reference paths, environment variables, vault connections, token scopes, and signing-key use.[12]
Permissions, IAM, authentication, and authorization
Changes to roles, policies, service accounts, OAuth scopes, repository-app permissions, and authentication or authorization logic can have large effects despite small diffs.
Approvers must compare who can access which resources before and after the change. Broadening privileges through wildcard permissions, administrator roles, or tenant-boundary changes requires a reason and an affected-identity list. NIST SSDF and SP 800-204D recommend least-privilege protection of source code and configuration-as-code and granular permissions for commits, builds, and artifact work.[6]
Dependencies and lockfiles
Dependency changes include transitive changes through lockfiles as well as directly added packages. GitHub Dependency Review compares direct and transitive manifest and lockfile changes and known vulnerabilities per PR, and its check can be required.[13]
A person must inspect supply sources and execution permissions when changes introduce a package registry or Git source, upgrade a major version, or add build plugins or post-install scripts. NIST SSDF also calls for lifecycle verification of third-party components, including commercial and open-source software.[6]
This does not mean every automatic patch update from a predefined source and scope always needs several human approvals. Organizations can define limited exceptions combining narrowly scoped trusted automation, vulnerability, license and build checks, and explicit auto-merge policy. Exceptions require fixed bot identity and change scope, plus auditable policy application. SLSA Source Track likewise permits explicitly defined trusted-robot exceptions at high assurance levels.[14]
CI workflows, builds, and merge rules
CI workflows and build scripts define the checks themselves. A PR that can remove its own required checks, arbitrarily report success, or gain broader secret and repository access needs stronger review than ordinary application code.
GitHub’s baseline agent controls require human inspection before running changed workflows and warn separately that workflows can access sensitive secrets. NIST also calls for protecting clients and execution environments against malicious code stealing CI/CD signing keys, cloud credentials, and environment secrets.[10]
Assign platform or repository administrators or security owners as automatic reviewers for these files.
· CI/CD workflows and shared pipeline templates
· Branch rulesets and merge policies
· CODEOWNERS or required-reviewer settings
· Build, packaging, and signing scripts
· Repository-app and action permissions
· Workflow definitions using secrets
Infrastructure and deployment configuration
IaC, Kubernetes manifests, deployment workflows, and runtime configuration may look like source code but change networks, compute, identities, data stores, and deployment permissions in actual environments.
Before merging, require plans or diffs closer to execution outcomes than syntax success alone. Identify target environments, resource creation or deletion, and changes to public exposure, IAM, and state. Azure Repos security guidance likewise lists deployment and infrastructure code and shared pipeline templates as sensitive paths needing designated reviewers.[15]
Change Type × Merge Requirement Matrix
The matrix is a recommended team operating model reconstructed from official documentation and standards, not a feature list for a particular source-control product. Adapt checks and approval counts to repository risk, regulations, and team size.
Human approval is not strengthened indiscriminately because AI wrote code. Human-written IAM changes also need strong approval, while an AI-corrected typo can follow a narrow policy. Judge change impact and the consequences of control failure, rather than author type.
Change Type | Required Checks | Human Approval | Additional pre-merge evidence |
|---|---|---|---|
| Documentation, comments, non-executable metadata | Documentation build, link and format checks, basic secret scan | Usually one independent reviewer; narrowly scoped trusted automation may use a pre-approved exception policy | Confirmation that executable code, configuration, and permissions are unaffected |
| General application code | Team baseline build, static analysis, selected tests, and security checks, all against the current head revision | A reviewer other than the person who made the change | Purpose, affected components, and links to check results |
| Test-only changes | Changed test suites and baseline checks; verify diffs for bulk snapshot updates | Domain owner required for removed or weakened assertions, reduced coverage, or bulk snapshot changes | Explain whether product behavior or only test expectations changed |
| Dependencies, manifests, lockfiles | Direct and transitive dependency diff, vulnerabilities, licenses, build | Human approval required for new sources, major versions, build plugins, and post-install scripts | Package source, manifest/lockfile relationship, and new execution privileges |
| Secret and credential references | Push protection, secret scan, configuration validation | Security or platform owner required | No actual secret values, revocation and replacement records after exposure, before/after scope comparison |
| Permissions, IAM, authentication, authorization | Policy checks, permission diff, relevant security checks | Domain owner and independent approver required | Before/after role, principal, resource, and tenant boundaries |
| CI/CD, build, signing workflows | Workflow validation, permission and secret-access diff, expected check issuer | Platform or repository administrator required; author-only approval prohibited | Tokens, secrets, and environments used; removed or weakened checks |
| Rulesets, branch policies, CODEOWNERS | Policy-as-code checks or configuration diff, administrator audit | Repository administrator and independent security or platform owner | Bypass subjects and before/after required checks and approvals |
| IaC, deployment, runtime configuration | Validate, plan, policy checks, environment-specific security checks | Platform owner or relevant service owner required | Target environment and resource, network, IAM, and state changes |
| Generated code and artifacts | Build and regeneration checks, hashes and provenance, original source and generator validation | Domain reviewer able to explain functional impact | Generator, version, input source, base/head revisions, generation path |
| Large refactors and unreviewable changes | Run relevant checks, but passing alone does not justify merging | Owners for each affected area; second independent reviewer where needed | PR split plan, review map, separation of generated files and manual changes |
| Emergency hotfix | Run checks possible in the available time and identify omitted checks | Pre-designated override authority and risk owner | Incident ID, bypass reason and controls, expiry, post-review deadline |
What should generated-code provenance retain?
Recording agent-generated code provenance does not require copying entire prompts or internal model reasoning into the repository. Prompts can contain credentials, customer information, and internal architecture, while natural-language explanations do not prove correctness.
Instead, retain observable records that can support policy decisions.
SLSA Source v1.2 defines source provenance as information about the processes and contributors that produced a revision and its parent revisions. It also requires understandable plain-text diffs and links between technical controls, actor identities, and revisions.[14]
Some implementations, such as GitHub’s current agent flow, connect commits to agent-session logs. Even without a vendor-specific session feature, linking tasks, agent identities, base/head revisions, checks, and human approvers establishes a basic audit structure.[16]
Provenance does not mean the code is correct. It shows how the code was produced and which controls it passed. Separate reviews and checks assess correctness and safety.
Field | Value to record |
|---|---|
| agent_identity | "" |
| agent_provider_or_service | "" |
| human_requester | "" |
| task_or_issue | "" |
| repository | "" |
| target_branch | "" |
| base_revision | "" |
| head_revision | "" |
| generated_or_modified_paths | [] |
| generator_or_tool_versions | [] |
| external_tools_or_context_used | [] |
| required_checks | |
| required_checks[].name | "" |
| required_checks[].issuer | "" |
| required_checks[].revision | "" |
| required_checks[].result | "" |
| required_checks[].evidence | "" |
| human_approver | "" |
| merge_actor | "" |
| merged_at | "" |
A PR can be too large to merge even when checks pass
A change that reviewers cannot understand has not been fully reviewed.
Agents can quickly modify many files, mixing new functionality, refactoring, dependency updates, generated files, and formatting in one PR. Even when every check passes, unseparated intent and impact make defects harder to find and causes harder to trace later.
AI review tools have coverage limits too. Rovo Dev, for example, may leave no comments on PRs exceeding 10,000 lines and automatically excludes some lockfiles, binaries, and snapshots. This is not a universal team merge limit, but it is evidence against assuming that a large PR was fully reviewed simply because AI reviewed it.[17]
Consider these signals together instead of relying on one fixed line limit.
· Are changes with different purposes mixed in one PR?
· Can reviewers explain the diff?
· Are generated files distinguished from manually modified source?
· Are dependency, IAM, or deployment changes buried in general code?
· Did review tools miss directories or file formats?
· Can a failed check be traced to a particular change?
Split changes by feature, risk, or dependency when they exceed reviewable scope. For inseparable migrations or large mechanical transformations, retain separate evidence of the source PR, generated output, regeneration command, sample-review scope, and integrity checks.
An audit trail needs more than who pressed Merge
Merge records should answer these questions.
· Who approved the change intent?
· Was the actual actor a person, app, or service account?
· Which head revision came from which base revision?
· Which identity ran each check?
· Which revision did the reviewer approve?
· Which rules applied and which were bypassed?
· Who performed the final merge, and when?
Agent permission models differ. GitHub Copilot cloud agent may be constrained to an app identity and particular branches; GitLab may use service accounts; other agents may operate with delegated user permissions. Record actual identities and scopes instead of simply AI used.[18]
Do not assume platform audit logs are permanent ledgers. GitHub organization audit logs currently provide 180 days of activity, while Azure DevOps audit events have a default 90-day retention. Longer retention requires a separate policy, such as export or audit streaming.[19]
Emergency Override is not turning off protection
Incidents and serious security issues may leave insufficient time for every normal check and approval. Temporarily disabling branch protection or quietly pushing directly through an administrator account makes emergency changes the hardest to trace.
Emergency Override should be a separate path recording who temporarily accepted unverified risk and why, rather than eliminating normal merge conditions.
Limit bypass rights to a small pre-designated group and prefer bypassing specific conditions on an existing PR over direct pushes where possible. GitLab security approval policies can restrict bypass to users, roles, or service accounts, require reasons through the UI or push options, and log audit events. GitHub ruleset bypass requests and rule insights likewise expose requesters, approvers, statuses, and failed or bypassed rules.[8]
Permanent exemptions differ from emergency bypasses. GitHub describes normal bypass as explicit break-glass action with audit signals, while exempt is a separate configuration that silently skips controls. Broad permanent exemptions make normal automation harder to distinguish from abnormal bypass afterward.[20]
Post-review should rerun omitted checks on the actual merged revision, have domain owners review the diff, and link findings to follow-up PRs or issues. Repeated overrides also warrant examining check duration, ownership, runbooks, and merge-policy structure rather than only individual judgment.
Field | Value to record |
|---|---|
| override_id | "" |
| pull_request | "" |
| head_revision | "" |
| incident_or_change_id | "" |
| reason | "" |
| risk_owner | "" |
| bypassed_controls | |
| bypassed_controls[].control | "" |
| bypassed_controls[].reason | "" |
| override_approver | "" |
| merge_actor | "" |
| approved_at | "" |
| expires_at | "" |
| post_review_due_at | "" |
| post_review_result | "" |
| follow_up_issues | [] |
Merge readiness and release readiness are different decisions
Passing a merge gate means accepting a change as the next state of a protected branch. It does not automatically authorize production deployment or user release.
Release decisions also require the combined effects of merged changes, unresolved defects, operational readiness, observability, recoverability, and residual risk. The parent article on what to check beyond test results when deciding to release owns that overall decision.
Traceability design connects requirements to code and tests. Risk-based regression strategy selects regression scope. The test automation portfolio determines which checks to automate. This article designs the gate ensuring those results become verifiable pre-merge evidence approved accountably by the appropriate people.
