How to Add Human Approval to AI Coding Agents

An AI coding agent that can turn an issue into a pull request is only as safe as the points where a person gets to say no. Most teams have exactly one of those points — pull request review — and it comes at the end, after the agent has already decided what to change and written all of it. This guide covers the four places you can put a human checkpoint in an AI coding workflow, what each one protects against, and how to set it up on GitHub.

The four checkpoints

1. Before work starts — who is allowed to send an agent to work at all.
2. Before code is written — a person approves the agent's plan.
3. Before merge — a person reviews and merges the pull request.
4. Before deploy — a person approves the release to production.

You do not need all four for every change. But each one catches a different kind of mistake, and the earlier ones are much cheaper: rejecting a plan costs a minute, rejecting a finished 600-line diff costs the reviewer's afternoon and the agent's whole run.

1. Before work starts: control the trigger

Agents are usually started by something on GitHub — an issue label, an assignment, a comment command. Whoever can perform that action can spend your AI budget and point an agent at your code. Check who that is:

• On GitHub, applying labels needs at least triage access to the repository. If your agent starts on a label, everyone with triage access can start it. Review that list.
• Use a dedicated label (for example ai-task) rather than a common one like bug, so nobody starts an agent by accident while triaging.
• Never trigger an agent from content written by people outside the team — issue bodies on a public repository are untrusted input, and an agent will read them as instructions.

2. Before code is written: approve the plan

This is the checkpoint most setups skip, and the one that matters most. Ask the agent to write a plan first and stop. A useful plan states:

• the steps it will take, in order, each with what "done" means;
• the files it expects to change;
• the commands that will prove the change works;
• how risky the change is, and how to roll it back.

A reviewer can read that in a minute and catch the expensive mistakes: the agent misunderstood the issue, plans to touch the payments module for a copy change, or intends to "fix" a failing test by deleting it. Approving should be an explicit action by a named person — and the approver needs three options, not two: approve, reject, or modify with instructions, which sends the agent back to re-plan.

If you build this yourself, the simplest version is a two-stage workflow: the agent posts its plan as an issue comment and only continues when a team member replies with an approval command. Make sure your workflow checks that the commenter is actually a team member before continuing.

3. Before merge: enforce review on the branch

Pull request review is the checkpoint you probably have already, but with agents it has to be enforced, not assumed. In your repository's branch protection rules or rulesets for the default branch:

• Turn on Require a pull request before merging with at least one required approval.
• Add a CODEOWNERS file and require review from code owners, so changes to sensitive paths — authentication, billing, infrastructure, the tests themselves — need the people who own them.
• Make sure the agent's identity cannot approve its own pull requests and is not on the ruleset's bypass list. A token with admin rights can bypass protection rules.
• Do not let the person who requested the change be the only approver. Requesting and approving are different checks.

4. Before deploy: protect the environment

If merged code deploys automatically, merge is effectively deploy. For production, use a GitHub Actions environment with required reviewers: deployment jobs that target it wait until one of the listed people approves. This is the same control you would want for human-written code; the point is to make sure agent-written code does not reach production on a path that skips it.

Make approval fast, or people will route around it

An approval step that takes a day to clear gets disabled within a month. Three things keep it fast:

• Send it where people already are. An approval request in Slack or Teams with an Approve button gets answered; one buried in a dashboard does not.
• Put everything needed to decide in the request. The plan, the files, the risk. If the approver has to open three tabs, they will rubber-stamp it instead.
• Make links safe to click. Approve and Reject links in emails or chat should be signed, single-use, and expiring, so a forwarded email or an old message cannot approve something new.

Avoid approval fatigue

If every typo fix needs the same ceremony as a schema migration, approvers stop reading. Two ways to keep attention on the changes that need it:

• Scale by risk. Show a risk level on every plan, and let a small set of people pre-approve routine, low-risk tasks they create themselves — while still recording that approval and still requiring a reviewed pull request.
• Keep plans small. One issue, one focused change. A plan with twelve steps across five modules should be split, not approved.

Record every decision

Approval is only useful afterwards if you can prove it happened. For each change, you want a record of who requested it, what plan was approved, by whom and when, what ran, and what passed. GitHub records the pull request review; the plan approval and everything before it need their own log — ideally one that cannot be edited.

How Dualzo handles this

Dualzo builds checkpoints 1 to 3 in: work starts from a label or a prompt, the agent writes a plan and waits, the plan goes to your team by email, Slack, Microsoft Teams, Google Chat or Discord with signed single-use links, and the result opens as a pull request for your normal review. Every decision is written to an append-only audit log. Read more about human approval in Dualzo.