Branch Protection Rules That Assume the Author Is a Bot

Before touching branch protection, settle the permissions model. An agent that can both alter a change and approve it has no review boundary at all. The GitButler workflow write-up shows a good instinct in practice: the authors teach Claude Code to use the but CLI for commits and to never run git commit, git add, or git push directly, so every change routes through a controlled tool. That addresses the agent's local commands, not the repository's merge rules, so you need both layers.

GitHub's documentation is explicit that by default the restrictions of a branch protection rule do not apply to people with admin permissions or custom roles with the "bypass branch protections" permission, though you can optionally apply the restrictions to those actors too, per the protected branches reference. That default matters for agents: if an agent runs under a token with admin rights, your rules are decoration. Give agents a scoped token, and audit which tokens carry bypass rights.

The GitHub community discussion on bypassing required status checks is a useful record of how awkward an overbroad bypass list becomes once automation depends on it. The request that started that thread came from someone doing automated versioning who needed an app to push to a protected branch without a pull request, which is the same shape of problem agent workflows create.

The GitKraken overview of agent orchestration questions is worth reading before you design the token model, because it frames the governance questions (who owns the agent, what it can reach, how its changes are attributed) that ultimately decide which branch rules are enforceable.

The first rule for agent PRs is that you require the same checks you require of humans. Do not create a fast lane for bots with fewer checks. The second rule is that you pin those checks.

The mechanism matters. When you configure a required status check, GitHub verifies that a status with that name reports as successful on the pull request's head commit. If the workflow that reports the check lives in the PR branch, an agent can rewrite it: delete a test, stub a script, or rename the job that reports status. The Stack Overflow answer on making GitHub Actions required status checks covers the basics of locating job names in the checks search, but the configuration that survives agent traffic has to handle the source of the workflow, not only its name.

GitHub's own documentation carries a warning that bites teams running many parallel agent workflows: if you use branch protection rules that require specific status checks, make sure job names are unique across all workflows, because using the same job name in multiple workflows can cause ambiguous status check results and block pull requests from being merged, per the protected branches reference. With many small agent-authored workflows in flight, duplicate job names are a realistic hazard.

A workable pattern:

• Run required checks from a workflow file on a dedicated ref such as refs/heads/ci-stable, or from a workflow on main, and configure the check name to match that source.
• Prefer rulesets to classic branch protection where you can. GitHub's guide to managing a branch protection rule notes that only a single classic rule can apply at a time, which makes it hard to predict which rule wins when several target the same branch. Rulesets do not carry that restriction.
• Protect .github/workflows/** and any CI configuration with CODEOWNERS and a required owner review, so an agent PR cannot weaken the pipeline as a side effect of a feature change.
• Keep one aggregator check (a job that depends on test, lint, typecheck and build) as the required check, so the list of required names stays small and stable as jobs change.

Run the required jobs on clean, disposable infrastructure. A long-lived self-hosted runner carries filesystem state, credentials, orphaned processes and environment drift from one job to the next, which is how a job that ran hours ago becomes the root cause of a failure on an unrelated pull request, as the RunsOn comparison of ephemeral and long-lived runners lays out. GitHub's own self-hosted runners reference documents the routing behavior, and the --ephemeral flag makes a runner accept exactly one job before deregistering itself, per this guide to ephemeral runners. For agent-generated code in particular, a runner that remembers yesterday is a runner that can be poisoned today.

The ephemeral model is not free: a fresh machine has to boot and re-download dependencies unless you prebake images or move the warm state off the runner, the same RunsOn analysis notes. Budget for that cold start rather than waving it away.

CODEOWNERS is the lever that turns "someone should look at this" into an enforced approval. The Factory guide to code ownership for agent PRs makes the case in one line: ownership rules connect changed paths to people who understand their operational and security consequences, and an automatic review request without a merge rule is only a notification. Its advice is worth copying directly:

• Start with boundaries that carry distinct failure modes: authentication, payments, deployment manifests, database schemas, public APIs, generated clients.
• Test pattern precedence, because GitHub uses the last matching CODEOWNERS pattern and some familiar .gitignore syntax does not apply.
• Protect the CODEOWNERS file itself, so a change to ownership cannot quietly remove the reviewer required for another sensitive edit.
• Prefer team ownership with documented escalation to a single named person, who becomes a bottleneck the moment they are away.

A compact starting file:

# Sensitive paths: human approval required
/.github/workflows/        @platform-team
/infra/                    @platform-team
/db/migrations/            @data-team
**/secrets*                @security-team
/docs/**                   @docs-team

# Default: any reviewer
*                          @code-reviewers

Enable the code owner review requirement, then check the one thing most teams miss: whether bot accounts can satisfy it. If the agent's service account is listed in an owner pattern, or a team that includes it owns a path, the agent approves its own change. Keep agent accounts out of every owner pattern for sensitive paths, and confirm that a PR authored by a bot cannot satisfy an owner review.

The GitKraken overview of agent orchestration is a useful checklist for the surrounding questions: who reviews agent output, how ownership survives reorganisation, and what evidence a reviewer needs to see before approving.

Parallel agents produce volume. A naive merge process turns that volume into a treadmill: every PR that lands on main invalidates CI for every other open PR, agents rebase, checks rerun, and the queue churns without shipping anything.

The merge queue fixes the invalidation problem by building each merge candidate against the current tip of main plus the PRs ahead of it. The setting that matters for agent traffic is batch size. A small batch means a failing check blocks only that batch and the rest of the queue proceeds. A large batch means one flaky test stalls everything behind it.

A worked example. Six agents, twenty PRs a day, a required test suite that takes 12 minutes and fails spuriously 5 percent of the time. With batch size one, one in twenty queued runs hits the flake, and the queue adds roughly 12 minutes per PR, so about four hours of aggregate queue time per day, with each agent's PR waiting behind a handful of others. Raise the batch to four and a single flake now stalls four PRs and forces their rebuild, so the cost of each flake quadruples while the average wait per PR grows with the batch. The number to optimize is not throughput but time-to-merge variance for the typical agent PR, and small batches keep that variance low.

Configure retry behavior too. A flaky check that fails the queue three times before a human looks at it wastes the same 12 minutes three times. Retry once automatically, then require the agent to push a fix, and label the PR so humans can find PRs that circle.

The Augment Code guide recommends sequential merges of agent branches for the same reason: branches merged out of order produce semantic conflicts that compile fine and disagree at runtime. The merge queue is where that sequencing gets enforced automatically.

Automation handles most agent PRs. A small set of changes should never merge on an agent's approval, however clean the diff looks. The reason is not distrust of the model. These changes are hard to reverse, hard to test, or grant authority that outlives the pull request.

Least privilege for secrets means each credential is scoped to the workload that needs it, and the most common misapplication is issuing a broad secret at build time and never revisiting it, per this least-privilege reference. An agent that can add a secret to a CI configuration has just widened the blast radius of every job.

The agent sandbox guide from Solo.io makes two points that carry into repository rules. First, a proper sandbox is a bundle of boundaries, starting with the filesystem, and the same logic applies to what lands in your dependency tree. Second, interactive permission prompts are a weak control: the write-up cites Anthropic data showing users approved 93 percent of prompts. The discipline that catches more is deterministic: require human approval on this short list, automate the label, the review request, the retry and the merge for everything else.

Once the rules are set, most of the remaining human work on an agent PR is administrative. Automate it: add a label when the author is a bot, request the right owners automatically, post a summary comment listing the checks that ran, retry a flaky check once, and move on. Keep human time for the short list above.

Instrument three numbers every week:

• Share of agent PRs that require no human review, which should climb as the rules mature.
• Median time from open to merge for agent PRs, split by human-reviewed and auto-merged.
• Count of PRs that touched a sensitive path without an owner approval, which should be zero, and any nonzero reading is an incident.

The pattern in multi-agent teams is that the bottleneck moves. First it is merge conflicts, then CI time, then review. Branch protection tuned for bots does not eliminate the bottleneck. It relocates it to where a human adds the most value.

If you run several agents and want sandboxed, prepaid model access without a separate provider contract per session, Quanta Inference exposes text, image, video, audio and embedding models through one OpenAI-compatible API key. If your team would rather install these rules than rebuild the workflow plumbing in each repository, Quanta Skills packages the operational steps into something a coding agent can follow directly.