An organization's policy requires all code changes to the main branch to go through a pull request with at least one human approval before merging. A code generation agent attempts to push commits directly to the main branch, bypassing the pull request process entirely. Which GitHub guardrail configuration BEST prevents this action?
Select an answer to reveal the explanation.
Short Explanation
Branch protection rules enforce the policy at the GitHub API level, so a direct push to main fails even if the agent tries. A system prompt is just a suggestion, and alerts only tell you after the damage. Give the agent write access, then protect main with required pull-request approvals.
Full Explanation
The distinction between policy enforcement layers is critical in agent guardrail design. There are two fundamentally different types of constraints:
Soft guardrails (behavioral instructions): These live in prompts, agent configuration, or monitoring systems. They influence what the agent chooses to do, but they can fail if the model misinterprets instructions, if an adversarial input overrides them, or if the agent finds an alternative path to its goal. They are not enforced by an external system.
Hard guardrails (infrastructure-level enforcement): These are enforced by the platform itself, independent of the agent's decisions. GitHub branch protection rules are the canonical example: when enabled, the GitHub API rejects any direct push to the protected branch with a 403 error, regardless of the requester's identity, their GitHub token's write permissions, or any instruction the agent was given. The enforcement happens in GitHub's infrastructure, not in the agent.
For a policy as important as "no direct pushes to main," the guardrail must be a hard enforcement that the agent cannot bypass through any action within its own scope. Enabling branch protection rules on the main branch, with pull requests required and required approvals enforced, is the best configuration because GitHub itself blocks the direct push no matter what the code generation agent attempts.
Why the other approaches fail: - The system-prompt instruction telling the agent never to push directly to main is a soft guardrail. It can be forgotten, misinterpreted, or overridden by conflicting instructions elsewhere in the agent's context. It provides no enforcement guarantee. - The monitoring-and-alerting approach that watches the agent's git commands and alerts on a direct push attempt is a detective control, not a preventive control. It catches the violation after it occurs. For a direct push to main, the damage, such as broken history or unauthorized code in production, is already done when the alert fires. - The read-only-token approach over-restricts the agent. If the agent needs to push to feature branches, create pull requests, and perform other legitimate write operations, a read-only token prevents all of these necessary functions. The correct approach is write access with branch protection rules, not blanket read-only restriction.
Branch protection rules are the purpose-built GitHub guardrail for policy enforcement at the infrastructure level.