A developer discovers that an agent has been merging pull requests directly to main without any human review. The branch protection rule requiring 'at least one approving review' is configured on the repository, but the agent's GitHub App has the 'bypass branch protection' permission enabled. No merge failures have occurred. What is the guardrail failure?
Select an answer to reveal the explanation.
Short Explanation and Infographic
The branch protection rule is the lock; 'bypass branch protection' is a master key. Handing a master key to an automated agent defeats the purpose of the lock. The guardrail failure is the permission grant — branch protection only works as a guardrail if no automated process can bypass it without additional human authorization.
Full explanation below image
Full Explanation
Branch protection rules are a primary guardrail for controlling what changes reach protected branches like main. The 'bypass branch protection' permission exists for emergency scenarios where a designated human administrator needs to push a critical fix without waiting for reviews. Granting this permission to an automated agent eliminates the review guardrail entirely — the agent can merge to main at any time, bypassing the very control that was designed to require human judgment.
The principle of least privilege requires that agents be granted only the permissions necessary for their defined tasks. An agent that creates PRs and requests reviews does not need to also merge those PRs — much less bypass review requirements to do so. If the agent's workflow genuinely requires auto-merging, it should do so only after a human approval has been received (via the PR review mechanism), not by bypassing review.
Option A (require two reviews) increases the guardrail requirement but does not address the root cause: the agent has permission to bypass whatever review requirement is set. Requiring two reviews would still be bypassed.
Option C (separate repository) would isolate the agent's work but would also break the intended workflow if the agent is supposed to contribute to main as part of its function. This is an architectural change that sidesteps rather than fixes the permission problem.
Option D (merges actually failing silently) contradicts the scenario statement that 'no merge failures have occurred' — the merges are succeeding, and that is the problem. The scenario is not about silent errors but about a guardrail correctly describing what is happening.