Agentic AI Branch Protection: The Agent That Wrote It Cannot Approve It

What is agentic AI branch protection? Agentic AI branch protection is a rule on the repository that stops any pull request from merging until someone other than its author approves it. The agent that wrote the change cannot approve it. That rule lives in GitHub, not in the agent, so the agent cannot talk its way past it.

The agent that wrote it cannot approve it. A second identity can.

New here? I publish one agentic AI governance post every weekday. Subscribe to the blog and it lands in your inbox the moment it goes live.

Why does self-review fail?

Self-review fails because the reviewer shares every assumption the author made. That was true for humans before agents arrived. It is worse with an agent, because the author and the reviewer can be the same model, on the same context, holding the same blind spot. A coding agent will check its own work and pass it. So will a second call to the same model with the same prompt.

The case I plan against in regulated loan origination looks like this. An agent rewrites a validation rule, runs the tests it also wrote, and reports green. The tests encode the same misunderstanding as the code. Nothing in that loop can catch it, because nothing in that loop is independent.

The fix is old. Auditors call it separation of duties. Git calls it a required review. Either way, the person who made the change is not the person who signs it off.

How does GitHub enforce it?

GitHub enforces it through branch protection rules and rulesets on the target branch. Once you require a pull request before merging, collaborators can only land changes through a pull request approved by the required number of reviewers. The author of a pull request cannot count as one of those reviewers. That is the whole control in one setting.

Three options make it hold. You can dismiss stale approvals when new commits are pushed, so an agent cannot get approval and then push more. You can require approval of the most recent push by someone other than the pusher. And you can require a review from a code owner, so the right human sees the change and not just any human.

These are enforcing controls. The agent has no vote. It cannot merge, and it cannot approve. Compare that with a skilldotmd file that says “always request review.” That is advice, and the agent can ignore advice.

What does an agent’s pull request need?

An agent’s pull request needs its own identity, its own narrow token, and no path to approval. Anthropic’s Claude Code GitHub Action runs as a GitHub App, and Anthropic’s own security guidance says to keep workflow permissions minimal and validate all outputs. I read that as a design rule, not a tip. The agent gets contents write on its branch and pull-requests write to open the request. It never gets the bypass list.

The identity matters more than people think. If the agent commits under a developer’s personal token, GitHub sees the developer as the author. Then the developer cannot review it either, and you need to find a second human. Give the agent its own bot identity instead, and the developer who prompted it becomes a valid reviewer. I covered the token side in my post on scoping credentials for agents.

Can an AI reviewer be the second identity?

An AI reviewer can be a second identity only if it is a different identity with a different context. Anthropic ships an automated security review action that reads the diff and posts findings as comments. It is useful. But a comment is not an approval, and agentic AI branch protection only counts approvals. And Anthropic itself warns the action is not hardened against prompt injection, so it should review trusted pull requests only.

So my rule is simple. An AI reviewer can add evidence to the pull request. It cannot be the required approval on a protected branch. The required approval belongs to a human code owner until the agent has earned a higher autonomy tier. Even then, the approving identity must not be the authoring identity.

What do I set first?

I set the required review on main first, before the agent gets write access to anything. Then I turn on dismiss stale approvals, because an agent pushes fast and often. Then I add a CODEOWNERS file for the paths that touch money, credit decisions, or customer data. Those paths get a named human, not a team alias.

Then I check the bypass list, twice. Branch protection is only as strong as the shortest bypass. If the agent’s app, or the developer’s admin account, sits on that list, the control is decoration. In regulated origination the bypass list is empty, and I keep it that way.

Where does this sit in the six layers?

Agentic AI branch protection sits in the enforcement layer of the six-layer architecture, next to hooks, managed settings and credential scoping. It is the merge gate. The intent layer says what the agent should build. The evidence layer shows what it built. Branch protection decides whether it lands.

It also feeds the autonomy layer. An agent that clears human review for three months, with no reverted merges, has earned something. Widening its band is then a decision backed by a record. Without the gate there is no record, and there is nothing to earn.

Roadmap diagnostic: can the identity that authored the change also approve it on your main branch? If yes, you are not governing the merge.

The bottom line

Agentic AI branch protection is the cheapest enforcing control you will ever turn on. It is one repository setting. It costs nothing at runtime. And it is the only thing standing between “the agent said it was fine” and a change in production. I wrote about the wider control set in Agentic AI and about earning the band in Earned Autonomy.

My books go deeper on both: Intent In, Outcomes Out (mybook.to/AgenticAI) and Earned Autonomy (mybook.to/Autonomy).

Instructions in, results out was IT. Intent in, outcomes out is agentic AI. But an outcome still needs a second signature. Who approves your agents’ pull requests today, and are you sure it is not the agent?

Dr. Harish Kotadia, Ph.D., is an Enterprise AI Architect with 20+ years of IT consulting experience serving Fortune 100 clients, specializing in agentic AI systems built on Anthropic Claude, AWS Bedrock, and Google Vertex AI.

Disclaimer:

This blog post is based on publicly available academic publications, vendor documentation, open standards, and news items from reputed media sources linked above. This post is intended for educational purposes, to help the enterprise agentic AI community build a shared vocabulary from public, authoritative sources.

Views and opinions expressed here are my own and do not represent those of any employer or client, past or present. The analysis presented is my independent interpretation of the published sources linked above and does not constitute legal, financial, or consulting advice of any kind.