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 and Infographic
System prompts suggest; branch protection rules enforce. A guardrail that lives only in an LLM's instructions is not a guardrail — it's a polite request. GitHub branch protection rules are enforced by the GitHub API itself: no direct push succeeds on a protected branch regardless of who or what is trying, full stop.
Full explanation below image
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.
Why the other options fail: - Option A (system prompt instruction) 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. - Option C (monitoring with alerts) is a detective control, not a preventive control. It catches the violation after it occurs. For a direct push to main, the damage (broken history, unauthorized code in production) is already done when the alert fires. - Option D (read-only token) over-restricts the agent. If the agent needs to push to feature branches, create PRs, 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.