Which branch protections should apply when coding agents open pull requests

What changes when an agent opens the pull request

Branch protection was designed around people: one person writes, another approves. Agents change three things. The author is a tool acting with someone's token, so it is not obvious who may approve. Agents push often, sometimes after an approval. And the agent can edit the files that tell it and CI how to behave, including instruction files and workflows.

Instructions in AGENTS.md or a playbook ask the agent to behave. Repository settings decide what can merge. This article covers those settings on GitHub. Reviewing agent code is a separate topic, covered in our guide to AI code review.

A baseline for branches that agents target

On GitHub these are settings in a branch protection rule or a ruleset for the default branch and any release branches. Each line says why it matters more with agents.

• Require a pull request with at least one approval, so every agent change passes a person.
• Dismiss stale approvals when new commits change the diff, because agents keep pushing after review comments.
• Require approval of the most recent push by someone other than the person who pushed it.
• Require review from code owners, with owners named for agent configuration and workflows.
• Require status checks for build and tests, with the expected source app set where possible.
• Keep force pushes and branch deletion blocked, which a protection rule does by default.
• Turn on Do not allow bypassing, because by default admins and roles with bypass permission are exempt.

Make required checks hard to fake

GitHub documents that any person or integration with write permission can set the state of any status check in a repository. An agent token with write access could, in principle, report a required check as passing. Set the expected source of each required check to the GitHub App that runs it, so a status from anyone else does not satisfy the rule.

Two more details matter. Required checks pass when they report successful, skipped or neutral, so a check that skips on agent branches or reports findings as neutral does not block anything. And job names should be unique across workflows, because duplicates make results ambiguous and can block merges.

Decide who counts as the author

Treat the engineer who started an agent as the author, so someone else approves. GitHub builds this into Copilot cloud agent, and only there: the person who asked it to create a pull request cannot approve it, the agent pushes only to its own copilot/ branch or the pull request's branch, and it cannot approve or merge. When Copilot opens a pull request under its own app identity, for example from a shared Slack thread, rulesets require one extra approval by default. GitHub marks that setting as public preview.

Other agents push with the identity you give them: a personal token, a bot account or a GitHub App. Check that it has no admin role, is on no bypass list and cannot change rulesets. Then look at who the last-push rule actually excludes. If commits appear under the engineer's own account, it excludes that engineer. If the agent pushes as a bot or App, it excludes only the bot, and the engineer who started the run can still approve. In that case, have the system that starts the agent record who started it, and add a required check, reported by an app you control, that fails while that person's approval is the only one.

Protect the files that steer the agent

GitHub's guardrail guidance for Copilot recommends protecting agent and MCP configuration files with CODEOWNERS and required code owner review. The same applies to CI workflows and to CODEOWNERS itself. Pull requests use the CODEOWNERS file from the base branch, so an agent cannot change its own reviewers within the same pull request.

/AGENTS.md                         @example-org/platform
/CLAUDE.md                         @example-org/platform
/.claude/                          @example-org/platform
/.cursor/rules/                    @example-org/platform
/.github/copilot-instructions.md   @example-org/platform
/.github/workflows/                @example-org/platform
/.github/CODEOWNERS                @example-org/platform

Rulesets can also require approval from specific teams when a pull request touches certain paths, for example security for authentication code. That gives a path-based rule without relying only on CODEOWNERS ordering.

Verify the settings with a test repository

Settings drift and layer. Several rulesets on one branch are aggregated and the most restrictive version of each rule applies, alongside any branch protection rule. Reading the configuration is not enough, so we test it with the agent's real identity in a throwaway repository that copies the production rules:

1. 1

   Push to the protected branch

   A direct push with the agent's token must fail.

2. 2

   Approve your own agent's work

   The engineer who started the run approves its pull request, and the merge must stay blocked. Copilot enforces this itself; for other agents it holds only if your initiator check is in place.

3. 3

   Push after approval

   A new agent commit after approval must require a fresh approval.

4. 4

   Fake a status

   Setting a required check to success through the commit status API with the agent's token must not unblock the merge.

5. 5

   Edit a steering file

   Mark the test pull request ready for review, since owners are not requested on drafts. A change to AGENTS.md or a workflow must then request the platform team, and the merge must stay blocked until one of them approves.

Repeat the test when you add an agent, change its identity or edit rulesets. Settings like these are part of how we roll out coding agents with platform teams.