A GitHub Copilot agent is attempting to perform a force push to the main branch, which violates the organization's branch protection policy. How should the guardrail system respond?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A building's fire suppression system doesn't ask the fire for permission before activating — it detects the condition and acts. Policy-violating actions like force pushes to main must be blocked at the system level, not logged after the fact or left to the agent's own judgment.
Full explanation below image
Full Explanation
Guardrail systems must enforce organizational policies as hard blocks, not soft suggestions. Actions that violate security, compliance, or operational policies must be prevented before they are executed.
Why C is correct: When the agent attempts a force push to main — an action that violates branch protection policy — the guardrail system should immediately block the execution attempt, prevent any data from being pushed, and generate a structured alert that explains which policy was violated and why. This creates both prevention and accountability.
Why A is wrong: Allowing the force push to proceed and logging it afterward means the damage is already done. Post-hoc review is a detective control, not a preventive one. Force pushes to main can rewrite history, lose commits, and affect the entire team — these effects are not easily undone.
Why B is wrong: Sending a notification and allowing a retry with different parameters does not block the violation — it delays it. If the agent's goal is to force-push, it may find other ways to accomplish this if the notification-based approach doesn't specifically prevent the action.
Why D is wrong: Asking the agent to determine whether its own policy violation is appropriate is fundamentally flawed. An agent that has decided to force-push main will likely justify that decision when asked. Policy enforcement must be external to the agent's reasoning.