Naming a code owner does not require their approval: what to check before AI opens pull requests against your repo

A&A perspective

A&A's reading is that there is a step between those two sentences. CODEOWNERS decides where a review request is sent; whether an answer comes back, and whether an approval is required to merge, is decided by a different setting. Teams that treat both as the same operation feel protected the moment they add a name and only discover later that they were not. The trigger for that discovery is often a merge that should have been blocked.

A&A perspective

In deployments where an AI agent opens pull requests, repositories are often added without rechecking this two-layer relationship. When a template repository is copied to create a new repository, the CODEOWNERS file is duplicated, but the branch protection configuration is not automatically the same as the source. What appears to be a horizontal rollout can therefore mix repositories where required approval is enforced with repositories where it is not. The integration lead has to inspect the CODEOWNERS contents and the branch protection settings on the target branches as two separate pieces of evidence.

A&A perspective

The shortest way to check this in practice is to open the branch protection rule for the relevant branch in the GitHub UI and look at whether the item that requires review from code owners is enabled. When the newer repository ruleset feature is used at the organization level instead, verify that the equivalent required-review item is present under whatever label the UI shows today. Do not decide from a documentation snippet; have the person responsible open the actual settings for the target repository and read them.

A&A perspective

It is technically possible for an AI agent to submit a pull request that adds CODEOWNERS on its own working branch, but that pull request itself is reviewed while the base still does not carry the file. Routing based on the new entries only takes effect from subsequent pull requests, once the change is merged into the base. Changes that edit ownership records therefore need the base branch's own protection to be in place first, so that the ownership change itself is subject to required approval.

A&A perspective

In teams that run AI agents daily, when CODEOWNERS and branch protection drift apart, merges start happening without the intended reviewer seeing them. Three drifts are common. First, CODEOWNERS is populated, but the branch protection option requiring code owner review is off. Second, code owner review is required, but the required approval count is one, so a colleague who is not the owner can approve an AI-authored pull request and unblock the merge. Third, the CODEOWNERS pattern order has not been updated to reflect a change in team responsibility, so the last-match owner is still the previous team.

A&A perspective

None of these are AI-specific defects; the same drifts can arise for human-authored pull requests when the two-layer meaning of these settings is not understood. What AI changes is the frequency: an agent that opens many small pull requests per day exposes the drifts sooner, which is an operational advantage if the team notices. The integration checkpoint that turns this into an advantage is a review, at introduction time, in which the target repository's CODEOWNERS, the target branch's protection settings, and the most recent merged pull requests' approver lists are read side by side.

A&A perspective

Before turning on wider AI-driven changes, verify four items on each target repository. First, CODEOWNERS lives on the base branch and the intended owner appears in the pattern that matches last for the paths in question. Second, the target branch's protection rule or ruleset has required review enabled and code owner review specifically required. Third, the required approval count matches the risk of the code that branch carries. Fourth, open a handful of the most recently merged pull requests and confirm that the required approvals were actually present at merge time. Widen the AI's scope only after all four pass.

A&A perspective

This checklist tends to surface a separate operational question: how many owners really exist for each area, and what happens when they are on leave. Tighter required approval means merges pause when the owner is unavailable. That pause is desirable in some cases and too costly in others, and the trade-off is a business decision, not a security default. Because CODEOWNERS can name a team rather than an individual, moving from a single person to a small team as the owner preserves the safety property while reducing single-point-of-failure pauses. Treat the settings as something to revalidate against merge history whenever they are changed.

A&A perspective

A&A's suggestion for a small development team is to fill in the four items as a single-page table for each repository before broadening AI's remit, and to fix drifts starting with the repositories where AI is most active. It is more productive to complete one repository than to leave many partially covered. Our related article "After AI says the work is done, how do you actually verify the business outcome" extends the same separation of layered checks to the moment when a person confirms an execution result.