Your team has deployed an autonomous agent that creates and merges pull requests for infrastructure-as-code changes. After a near-miss where the agent merged a Terraform change that would have deleted a production S3 bucket, the team wants to implement a hard gate that prevents any merge action until an approval is explicitly granted. Which mechanism BEST enforces this gate?
Select an answer to reveal the explanation.
Short Explanation and Infographic
If you want to make sure someone can't start the car without the keys, you don't leave the keys in the ignition with a sticky note saying 'don't drive yet.' You take the keys away. Removing the merge tool from the agent's registry means it physically cannot merge — no prompt instruction, no timing parameter, no self-imposed wait changes that. A separate human-triggered workflow holds the actual merge capability.
Full explanation below image
Full Explanation
Preventing premature agent action requires structural guarantees, not behavioral instructions. When the stakes are high — such as merging infrastructure changes that could delete production resources — the only reliable gate is one that removes the capability entirely from the agent's reachable tool set.
Option B is correct. By removing the merge tool from the agent's tool registry, it becomes architecturally impossible for the agent to merge a PR, regardless of what it reasons about or what instructions it receives. The agent's responsibility ends at creating and documenting the PR. A separate human-triggered workflow (e.g., a GitHub Actions workflow_dispatch triggered by a reviewer who has read the plan and diff) holds the merge capability. This creates a mandatory human-in-the-loop step that cannot be circumvented by prompt manipulation or model drift.
Option A (system prompt warning) is the textbook example of an insufficient behavioral constraint. System prompt instructions can be overridden by in-context reasoning, ignored during long-running agentic loops, or triggered incorrectly. A near-miss already occurred despite the agent presumably having reasonable behavior — a warning in the prompt will not close the gap.
Option C (agent posts comment and waits) still leaves the merge tool in the agent's registry. After 10 minutes with no response, the agent may proceed under its configured timeout behavior. Even if it waits indefinitely, the capability to merge remains within the agent's reach — the gate is behavioral, not structural.
Option D (max_steps=1) is a rate limiter, not an approval gate. It limits how many actions the agent takes per invocation but does not remove the merge capability. An invocation with max_steps=1 that triggers 'merge' as its single step would still merge the PR.
The exam objective is: 'Prevent agent action until the agent checked and approved.' The pattern is capability removal from the agent's tool registry, with the destructive capability delegated to a separate, human-initiated workflow.