Branch Protection Rules for Agent Commits: What to Require

A required status check is only as good as the name you selected. GitHub warns that job names must be unique across workflows, because using the same job name in multiple workflows can cause ambiguous status check results and block pull requests from being merged about protected branches. The inverse problem is worse: a shared name can let the wrong run satisfy the requirement.

Two rules make the check trustworthy for agent commits.

First, the required check should be the one that runs the tests you actually rely on, at the exact commit being merged. A green run on an earlier commit proves nothing about the current head. This matters more for agents than for humans because an agent will happily push another commit six seconds after the checks go green.

Second, the check should be fail-closed on removed proof. A diff that deletes a test file, drops a table-driven case, or turns an exact assertion into a truthiness check removes evidence, and a remaining green suite cannot prove that the removed check was redundant QA skills guide on deleted and weakened tests. If you want that as a gate, run a diff-aware job that maps each removed test to the flow it protected before the pull request can merge.

The same principle applies to mutation testing, which is the strongest signal you can put behind a required check when generated tests are involved. A suite can be all green with full line coverage and still miss bugs, because coverage measures which lines ran, not whether an assertion caught a defect CircleCI on mutation testing. Mutation testing injects small faults, runs the suite against each one, and reports survivors: a mutation that leaves the tests passing marks a place where an assertion pulled no weight CircleCI on mutation testing. For AI-generated code, coverage and mutation score diverge, and mutation score is the number that tells you whether the tests detect injected faults across Java, JavaScript and Python toolchains Augment Code guide on mutation testing for AI-generated code.

Be careful about turning a whole-repo mutation score into a required check for every agent pull request. Mutation runs are expensive, and teams routinely restrict them to changed files and run the full campaign on a schedule instead the Stryker diff-scoped issue. A practical arrangement is a fast required check that runs the suite plus a diff-scoped mutation run over changed files, and a nightly full run whose score is tracked but not blocking.

A worked boundary example shows why the required check needs a sharp oracle, not just a passing one. Take a shipping function that charges 500 cents below a cart threshold and zero at or above it. A test that asserts shipping is nonnegative at 1,000 and 6,000 cents exercises both branches and still accepts a fee of 1 cent. Change the comparison from < to <= and both sample totals still produce the expected branch outcome, so the mutation survives unless a test asserts the exact value at the boundary itself PracHub on surviving mutants and meaningful assertions. The lesson for an agent gate: require the check, but also require that someone agreed what the assertion is allowed to see.

The review setting that matters most for agent commits is not the count, it is the freshness. One required human approval is usually enough for an agent change if that approval is bound to the current head commit. Raising the count to two does not help if both approvals predate a weakening commit.

GitHub offers two related options, and they are not the same. Dismiss stale approvals when new commits are pushed invalidates the approval. Require approval of the most recent push requires an approval from someone other than the last person to push, and users who already reviewed can reapprove after the most recent push to meet the requirement the comparison on Stack Overflow. For an agent that pushes repeatedly, enable both. The first stops an old approval from carrying forward; the second stops the pusher's own account from satisfying the gate.

Then make sure the reviewer is not the agent. GitHub documents that it is best to review changes file by file, leaving comments and marking files as viewed before approving or requesting changes reviewing proposed changes in a pull request. That workflow is easier to follow when the reviewer is a person who did not produce the diff. If your CODEOWNERS file maps a directory to a team that includes the agent's account, the review requirement can be satisfied inside the automation.

There is a reviewable design that reduces the whole problem: separate the tests from the code in different pull requests. Submit the test change first, merge it, then submit the implementation without touching the tests, so reviewers validate the requirements in one pass and the implementation in another, and cannot be tempted to loosen a test to fit the code Yegor Bugayenko on code and tests in different pull requests. For agent work this is a strong default. An agent asked to make a failing suite pass has an obvious incentive to edit the suite, and a two-pull-request flow removes that incentive from the reviewed change.

Merge request approvals in GitLab work on the same principle, configured as default rules with a required count greater than zero, optionally combined with code owners so that both the feature group and any oversight group approve GitLab merge request approval rules. Approval policies can enforce that users who authored or committed changes to a merge request cannot approve it, and can prevent pushing or force pushing to the default branch GitLab merge request approval policies. Those two clauses together are the closest GitLab equivalent of the GitHub combination above.

Force push and deletion restrictions are the cheapest controls to enable and the easiest to forget when a rule is copied between repositories. By default, each GitHub branch protection rule disables force pushes to matching branches and prevents those branches from being deleted, and you can optionally disable those restrictions about protected branches. Leave them on. An agent that rewrites history on a protected branch has effectively bypassed every review that ever happened on it.

The bypass list deserves more attention than it usually gets. On GitHub, actors may only be added to bypass lists when the repository belongs to an organization managing a branch protection rule. That means a personal repository cannot express the exception at all, and an organization repository can express it too broadly.

Three rules keep the list honest:

1. Name a group, not individuals. A break-glass group with two or three named humans is auditable; a list of service accounts is not.
2. Separate the break-glass account from the agent account. The account that runs the agent should never appear in the list, because a compromised agent token then inherits the bypass.
3. Review the list on a schedule and on every incident. The list changes silently when people change roles.

GitLab expresses the same idea through protected branch settings and approval policies that can block pushing or force pushing to the default branch GitLab merge request approval policies. If your GitLab project has a maintainer group that can push directly, you have a bypass list whether or not you called it one.

A short check you can run against the API keeps the audit current:

# List protected branches and their push/merge access levels.
# Requires an admin or maintainer token; response shows which roles may push.
curl --silent --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "https://gitlab.example.com/api/v4/projects/$PROJECT_ID/protected_branches" \
  | jq '.[] | {name, push_access_levels, merge_access_levels}'

On the GitHub side, verify that administrators are included in the rule and that the required check names match the workflows that actually run. The settings page is not evidence. The API response is.

The table below is the rule set I would start from for a repository where agents open pull requests on the default branch. Adjust the counts, not the structure.

If you want a single decision rule: require one human approval on the current head, one required check that runs the suite at that head, stale approval dismissal, and no force push. Everything else is tuning. If any of those four is missing, the rest of the configuration is unlikely to stop an agent that is trying to merge.

For the mutation check specifically, a gate that fails closed looks like this in a CI step, scoped to changed files so the run stays short:

BASE=$(git merge-base origin/main HEAD)
CHANGED=$(git diff --name-only "$BASE" HEAD -- '*.ts' ':(exclude)*.spec.ts' | paste -sd, -)

if [ -z "$CHANGED" ]; then
  echo "No source files changed; mutation gate skipped."
  exit 0
fi

npx stryker run --mutate "$CHANGED"

The downside, as the maintainers of the diff-scoped approach note, is that path globs from the Stryker config have to be replicated in the command the Stryker diff-scoped issue. Keep the glob list in one script so the duplication is in a single place.

An agent will produce more commits per hour than a person, and each commit invalidates approvals when stale dismissal is on. That is the point, but it changes the review rhythm. Reviewers learn to stop approving early drafts and wait for the agent to signal done. If you have a pull request template, put the signal in it: a label, a comment, or a draft state that clears when the agent finishes.

Agents also tend to touch more files per change. A diff that spans thirty files is harder to review file by file, which is the workflow GitHub recommends reviewing proposed changes in a pull request. A useful guard is a size check as a required status, alongside the test suite, so an oversized agent change fails before a reviewer spends an hour on it.

Finally, agents regenerate tests. That is fine when the regenerated test still proves the same flow, and dangerous when it silently narrows the assertion. The distinction between retesting and regression testing is worth making explicit in your review checklist: retesting asks whether the fix works, regression testing asks whether the fix broke something else, and both are needed after a code change Drizz on regression testing. An agent asked to fix a failing test will do the former and may skip the latter.

If you are running several agents against several repositories, wiring them through one inference endpoint keeps the credentials and the audit trail in one place. Quanta Inference serves text, image, video, audio and embedding models through a single OpenAI-compatible API key, prepaid and priced in US dollars, which is one fewer set of tokens to rotate when you audit which account touched a protected branch: https://quantaintelligence.ai/inference.