To keep AI-generated changes from merging without a person reviewing them, enforce approval on the destination branch—not just in CI. Require a pull request or merge request, require approval from an eligible human, and make the relevant CI checks a separate merge condition. Also decide whether new commits invalidate earlier approvals and restrict who can bypass or change the rules.
Separate human review from CI status
A passing test or security scan shows that an automated check succeeded; it does not show that a person reviewed the change. Configure both conditions if you need both: a required human approval and selected passing CI checks. If production release also needs authorization, configure that as a distinct deployment gate.
As an Amazon Associate I earn from qualifying purchases.
The enforcement point is normally your code-hosting platform’s branch or merge policy. A workflow that comments on a pull request, or a green CI result by itself, does not establish a required human approval.
Choose the review policy before configuring it
- Protect every destination branch in scope. Require changes to arrive through a pull request or merge request and restrict direct pushes. Otherwise a contributor or agent may avoid the review gate.
- Require at least one eligible human approval. Use a larger count or a file-aware rule such as Code Owners when the project needs additional oversight. Ensure an AI review cannot count as the required human approval.
- Decide what a new commit does to approval. Dismissing stale approvals makes a changed diff require another review. Requiring approval of the latest push can ensure someone other than the latest pusher approved, while allowing earlier approvals to remain.
- Limit exceptions. Review who can push directly, dismiss reviews, edit rules, unprotect a branch, or bypass the merge requirement. A configured approval count is not a guarantee against permitted bypasses.
Configure GitHub
- Open the repository’s Settings → Branches and create or edit a branch protection rule for each destination branch. GitHub’s protected-branches documentation describes the available controls.
- Enable Require a pull request before merging, then set Required approvals to at least one. GitHub states: “If you enable required reviews, collaborators can only push changes to a protected branch via a pull request that is approved by the required number of reviewers with write permissions.”
- For sensitive files, require review from Code Owners. If different teams own different paths, define ownership in the repository and enable the corresponding requirement.
- Choose the post-push behavior. Enable Dismiss stale pull request approvals when new commits are pushed when any changed diff should be reviewed again. Alternatively, require approval of the latest reviewable push when you need a reviewer other than the latest pusher but do not want every earlier approval dismissed. GitHub describes stale-approval dismissal as the safer choice when the concern is unreviewed content added after approval.
- Enable Require status checks to pass before merging and select the checks that matter. This is separate from the approval requirement; a passing check does not replace a human review.
- Review any additional requirements you need, such as resolving conversations or using a merge queue, then examine the rule’s bypass settings. Restrict bypass and rule-editing permissions to the trusted people who genuinely need them.
GitHub also offers rulesets with overlapping controls that can target repositories or organizations. Check the configured targets and bypass permissions rather than assuming a rule applies to every repository or branch.
Copilot cloud-agent specifics
GitHub documents extra safeguards for Copilot cloud-agent pull requests: the agent cannot mark its pull request ready for review or approve or merge its own request. In the documented case, the person who assigned the task cannot count their own approval toward the required approval. When Copilot opens a pull request under its own app identity, GitHub documents one additional approval if the repository already requires at least one.
The corresponding ruleset behavior is documented as a public preview and may change. GitHub also documents an optional Copilot code-review feature that can allow AI approvals to satisfy merge requirements; that feature is also a public preview. If the requirement is specifically human approval, configure the policy so an AI review cannot substitute for it. Do not assume Copilot-specific protections apply to other agents.
Configure GitLab
- In the project, open Settings → Merge requests and configure the merge-request approval rules for the relevant target branch. Set the approval count above zero and choose the eligible users or groups.
- For path-specific review, configure Code Owners and the matching approval rule. GitLab Ultimate also supports security approvals tied to vulnerability findings; availability depends on the offering and tier.
- Check the controls for preventing approval by the merge-request creator and, if required, by users who added commits. Also review whether authors can alter approval rules on individual merge requests; disable rule overrides when authors should not be able to weaken the project policy.
- Require a successful pipeline separately if passing CI is also a merge condition. GitLab approval rules can coexist with a failed-pipeline merge blocker.
- Protect the destination branch and restrict who may push to it. GitLab warns that users allowed to push to a protected branch can skip merge-request approval rules.
Available settings vary across GitLab.com, Self-Managed, and Dedicated, as well as by plan and instance policy. Verify the controls available on your specific installation. GitLab’s approval controls are general merge-request rules; the reviewed documentation does not establish a separate trigger based on AI authorship.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
GitHub and GitLab controls at a glance
| Control | GitHub | GitLab |
|---|---|---|
| Human review gate | Approval count in branch protection or a ruleset | Merge-request approval rules |
| File-aware review | Code Owners; rulesets can require specified teams for matching paths | Code Owners and branch-targeted approval rules |
| Approval after new commits | Dismiss stale approvals or require approval of the latest reviewable push | Approval-reset settings can remove approvals after source-branch changes |
| Author or committer separation | Pull-request authors cannot approve their own pull requests; Copilot cloud-agent behavior has additional documented specifics | Options can prevent approval by the merge-request creator and by committers |
| AI-specific behavior | Documented Copilot cloud-agent safeguards; some ruleset behavior is public preview | No AI-specific approval trigger established in the reviewed documentation |
| CI merge condition | Require selected status checks separately from review | A failed CI/CD pipeline can separately block merging |
| Bypass concern | Check ruleset or repository bypass and review-dismissal permissions | Users with protected-branch push rights can skip merge-request approval rules |
Verify the gate before relying on it
After configuring the policy, use a test pull request or merge request to confirm the behavior on the actual destination branch. This is a verification checklist, not a claim that a test has been performed:
- Attempt to merge without an eligible human approval; the platform should block the merge.
- Attempt to merge while a required CI check is failing; the platform should block the merge independently of the approval result.
- Approve the request, push a new commit, and confirm that the selected stale-approval or latest-push policy behaves as intended.
- Review direct-push, rule-edit, review-dismissal, and bypass paths with the permissions held by agents and contributors, not only administrators.
Vendor settings, plan availability, permissions, and preview status can change. Check the current documentation and the policy available on your GitHub or GitLab installation when implementing these controls.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
