Require Human Approval Before an AI Agent Opens or Merges a Pull Request

Why approval must be enforced rather than assumed

AI coding agents can interact with a code repository to create and commit pull requests and resolve merge conflicts. Asynchronous agents now produce entire pull requests, typically as a draft that a developer then reviews, revises, or merges. Draft-then-review is a sound pattern, but on its own it is a convention. Nothing in the pattern stops an agent from opening a pull request, or merging one, if its credentials allow it.

The agent decides which API endpoints to call and what data to send. That means a request can be authenticated and valid yet not intended by any human, for example after a prompt tricked the agent into using a tool it legitimately holds. NIST describes this as an excessive agency threat. A valid token shows what the agent was able to do. It does not show that a person wanted the action.

Native branch protection and required reviewers help, but they do not always distinguish an agent-initiated action from a human one, and they do not necessarily stop an agent from opening a pull request. Agents may also act through service accounts, MCP servers, or tool calls that sit outside the intended review path. The design problem is therefore enforcement at every path, not a better review process.

Comparing the control points

No single layer covers both opening and merging across every path an agent can use. The table summarizes what each layer is good for and where it stops.

• Repository settings: Strength: required approvals and merge-approval permissions, including the rule that a developer cannot approve their own merge. Limit: centered on merging, may not tell agent actions from human ones, and does not by itself gate opening a pull request.
• Identity and token scoping: Strength: ephemeral, per-task, least-privilege credentials with zero standing privilege, and merge permission withheld from the agent. Limit: scope defines what is possible, not whether a human intended a permitted action. An agent that must open pull requests needs write access.
• CI checks: Strength: can require evidence of an approval before a merge proceeds. Limit: runs after the pull request exists, so it cannot prevent opening, and it only helps where the check is mandatory.
• Tool-call policy: Strength: a centralized policy decision on each request, with the option to hold a call for human approval before it executes. Limit: covers only the paths routed through it, so credentials must not be usable around it.

Approver identity, self-approval, and failure behavior

Self-approval is the most common gap. If the approver can be the agent's own credentials, or a service account the agent can use, the approval is decorative. Keep merge-approval permission away from the agent identity and bind each approval to an authenticated human. How to link agent identity to a human owner so that human-in-the-loop authorizations are verifiable is still an open question in NIST's work on agent identity, so treat this binding as something you design deliberately rather than inherit.

Decide in advance what happens when no one responds. A timeout should be treated as a denial, not as permission to proceed, and the agent should receive a clear refusal it cannot retry around. Denials and timeouts deserve the same record as approvals.

NIST describes human-in-the-loop as a spectrum from controlled approval to autonomous action. Define the risk thresholds that trigger human review and record which agent actions fall in which category. For example, a draft pull request to a sandbox repository may be allowed, while any call that targets a protected branch is escalated.

Where enforcement in the execution path fits

Repository settings, scoped credentials, and CI checks all act on the source control side or on the credential. They are necessary, and they remain your last line of defense. What they lack is a decision point at the moment the agent attempts the action. Centralized authorization middleware, which checks each request against a central policy instead of leaving authorization to each endpoint, fills that role. NIST guidance also names per-action approval as a way to constrain agent behavior.

Trussed enforces policy in the execution path across agents, tools, MCP servers, and coding assistants. For a pull request tool call, policy can allow, block, or escalate the call for human approval, enforced at runtime, not reviewed after the fact. Each decision generates audit-ready evidence. The scope is individual interactions and tool calls. It complements native source control controls and does not replace them, and it does not trace an agent's full workflow.

The pattern holds whichever tooling you choose. Keep an approval point in front of every route an agent can use, and make the approval record as durable as the code change it authorized.