Requiring Human Approval Before an AI Agent Merges a Pull Request via the GitHub MCP Server

What the requirement actually means

An AI agent connected to the GitHub MCP server acts with whatever credentials it is given. If those credentials permit merging, and the server exposes a merge tool such as merge_pull_request, the agent can call it. Whether a human approves is then determined by controls outside the model.

The requirement worth stating precisely is this: for each agent-initiated merge, a distinct, named human makes an explicit decision before the merge executes, and that decision is recorded. Each part matters. "Distinct" rules out an account the agent or its operator controls. "Named" means the approver is attributable. "Before" means the control sits in the path, not in a later review.

NIST guidance on agentic AI points the same way. It advises constraining agents with strict tool scopes and per-action approval, and not giving them broad privileges or open-ended tools. Treat a merge as a consequential action and design for per-action approval rather than a blanket grant.

Layers 1 and 2: Reduce what the agent can reach

Start by shrinking the agent's capability. These steps do not create a human approval, but they decide how often one is needed and how much damage a mistaken call can do.

Where the agent's job is to read and comment, a read-only configuration removes write tools from its reach entirely. Where it needs some write access, restrict the server to the toolsets that job requires. Confirm in your deployed version which tools remain exposed, and check specifically whether a merge tool is among them.

• Inventory agent identities: List every agent and credential that can reach merge-capable tools, and assign an owner to each.
• Restrict toolsets: Expose only the toolsets the agent's task requires. If it never merges, the merge tool should not be available.
• Use read-only mode where possible: Reserve write-capable configurations for agents with a documented need.
• Issue least-privilege, short-lived tokens: Scope each token to the repositories and actions required, and prefer credentials that expire quickly.
• Separate agent identity from human identity: Do not let an agent run on a developer's personal credentials or a shared account.

What branch protection can and cannot guarantee

Branch protection, required reviews and CODEOWNERS define conditions a pull request must meet before it merges. They are necessary and should be configured for any repository an agent touches. Require reviews on protected branches, and use CODEOWNERS so changes to sensitive paths need review from the responsible team. NIST guidance on software supply chain security also describes multiple approvers on merge or pull requests as a mitigation for insider threats.

The limit is what these rules verify. They check that review conditions are satisfied, not that the satisfying party is a distinct human who understood the change. If an account that is not a distinct human reviewer can meet the requirement, the rule passes without the intended oversight. Token permissions have a similar limit: they are coarse, so a token that can merge can merge anything within its scope.

That gap is the reason for a further layer. Native controls describe the state of a pull request. They do not intercept an individual tool call and ask a specific person to decide on it.

Layer 3: Approval at runtime on the tool call

Some MCP clients prompt the user before a tool runs. That is useful, but it is a client-side behavior. Depending on the client, it may be configurable by the user, and some clients offer auto-approve modes. For an enterprise requirement, a confirmation that the person being protected can switch off is a convenience, not a control.

A runtime approval step moves the decision into the execution path. A policy matches the merge tool call, holds it, and routes it to a human approver. The call proceeds only on approval. This also fits NIST's advice not to trust prompt instructions or artefacts from users or other agents: the approval does not depend on the model's own reasoning or on text in the pull request.

Two design decisions need an explicit answer. First, what happens if the approval path is unavailable? Fail-open lets the merge continue, and fail-closed stops it. NIST guidance treats this as a choice that depends on risk tolerance and business need. For merges to protected branches, fail-closed is usually the defensible default. Second, how deliberate is the approval? NIST digital identity guidance notes that approval prompts which can be accepted without comparing anything raise the likelihood of approving without looking. That guidance concerns authentication, so treat it as an analogy. Still, present the approver with the repository, branch, pull request and requesting agent, and require a deliberate action.

Trussed enforces policy in the execution path across agents, tools and MCP servers. The available actions are allow, redact, block, rate limit and escalate for human approval, applied to individual tool calls. A merge call can be escalated, with the decision enforced at runtime, not reviewed after the fact.