Human approval gates for AI agents

What is a human approval gate for an AI agent?

A point where the agent's work stops until a person approves, enforced by something outside the agent. The agent can ask for approval, but text in the conversation is not the approval: the yes has to arrive through the mechanism the gate checks, and the record shows whose account sent it.

Three properties separate a real gate from a polite request: the check runs in code the agent does not control, the work actually waits (minutes or days), and the record shows who moved it on.

Gates are one form of human-in-the-loop control. The other common form is review after the fact: the agent acts, a person checks the result. Both are useful. Gates belong where undoing the action is expensive or impossible, review belongs everywhere else.

1. Enforced outside the model: a permission layer, a hook, a platform or an engine.
2. The work waits, and resumes from the same place after the yes.
3. The approval leaves a record you can read later.

Why is "ask me before you deploy" in a prompt not a gate?

Because the model decides whether the instruction applies. Anthropic's Claude Code docs say instruction files are treated "as context, not enforced configuration", and recommend a hook to block an action regardless of what Claude decides.

A prompt rule usually works. It fails in the cases that matter: long sessions, conflicting instructions, a task that does not look like a deploy, or text from a file or web page that tells the agent something else. A gate does not read the situation; it checks a condition.

This matters most for agents that read untrusted input: issues, emails, web pages, documents from customers. Text in that input can tell the agent the change was already approved, or that this case is an exception. A gate checked by code does not read that text at all.

sourcesClaude Code docs: memoryClaude Code docs: hooks

What kinds of approval gates are there?

Gates differ in where they live and how long they can wait. Pick the one whose scope matches the risk. Dedicated approval services are another option; see how ConvOps compares with HumanLayer.

How do I add approval gates in Claude Code today?

Use permission rules for command patterns and PreToolUse hooks for anything that needs logic. Both run outside the model. Rules evaluate deny first, then ask, then allow, and a hook's decision cannot override a deny or ask rule.

Commit .claude/settings.json to the repo so every teammate and every session gets the same ask and deny rules. Personal overrides go in .claude/settings.local.json, which stays out of git.

1. 1

   Ask before risky commands

   Add ask rules to .claude/settings.json in the repo so the whole team gets them. Deny what must never happen.

   {
     "permissions": {
       "ask": ["Bash(git push *)", "Bash(npm publish *)"],
       "deny": ["Bash(git push --force *)", "Read(./.env)"]
     }
   }

2. 2

   Ask on a condition

   A PreToolUse hook can inspect the call and return an ask decision with a reason, for example when a migration touches a production schema.

   {
     "hookSpecificOutput": {
       "hookEventName": "PreToolUse",
       "permissionDecision": "ask",
       "permissionDecisionReason": "Migration touches production tables. Confirm."
     }
   }

3. 3

   Know what happens unattended

   In claude -p with nobody attached, an ask cannot be answered, so it is denied. That fails safe, but the work stops instead of waiting. Claude Code Routines run without stopping for approval, and Anthropic notes the fired prompt cannot act as approval or consent. Dynamic workflows have no mid-run user input.

4. 4

   Gate the deploy on the platform

   For deploys, a CI platform gate also works: GitHub environments can require a reviewer and prevent self-review. As of October 2026, GitHub documents required reviewers on private repositories only for Enterprise plans.

sourcesClaude Code docs: permissionsClaude Code docs: hooksClaude Code docs: headless modeClaude Code docs: RoutinesClaude Code docs: Dynamic workflowsGitHub docs: deployment environments

Where should approval gates go in an agent's process?

Where a wrong move is expensive or hard to undo, and nowhere else. Too many gates train people to click yes without reading, which is worse than no gate.

Give the approver what they need to decide in one screen: the diff or the draft, the test results, and what happens if they say yes. A gate that asks "Ship it?" next to a clear summary gets read. A generic "Continue?" gets clicked.

1. Put the gate on the step, not on the tool, when the risk depends on context.
2. Write what the approver should check in the gate prompt.
3. Review the list every few weeks. Remove gates that never catch anything.

How do approval gates work in ConvOps?

A gate is part of the workflow step, not of the prompt. Claude Code, or any MCP client, works the current step and asks to advance. The engine evaluates the gate on every advance against real state. If it is not met, the cursor stays put and the agent is told exactly what is missing.

Approval has to be passed explicitly on the advance call; it is never inferred from chat text. The advance that passes the gate writes an audit row with field-level before and after on the task and the workflow instance, with two identities: the agent label the caller declares, and the person the server verified from the credential. There is no separate approver field, so the record shows the account behind the advance. Unattended runs stop at the gate and wait for a person.

Not every gate needs a person. wait_for_children holds a parent until its child tasks finish, and require_context will not close a step without a recorded why. Combine a structural condition with requires_approval and a person is asked only once the work is actually ready, which keeps each approval meaningful.

1. 1

   Put the gate on the step

   requires_approval holds the step for a person. Structural keys hold it for real state: wait_for_children, sequential_children, task_status and require_context.

   {
     "id": "approve",
     "gate": {
       "requires_approval": true,
       "wait_for_children": true,
       "prompt": "Ship it?"
     }
   }

2. 2

   Let the agent try

   An early advance is refused with the unmet conditions, verbatim.

   workflow_advance(task_id="…")
   
   {
     "current_step": { "id": "review" },
     "unmet_conditions": [
       "Requires explicit user approval",
       "1 of 1 child tasks are not completed"
     ]
   }

3. 3

   Approve

   You review the work and advance with your approval. The next step arrives; the audit keeps the agent label and your signed-in account.

What happens when the approver says no?

The work should go back to a named step, not stall. A well-designed gate defines the no path as carefully as the yes path: which step rejected work returns to, and what the approver has to see before deciding.

In Claude Code, denying an ask blocks that one tool call; the model is told the call was rejected and chooses what to try next in the same session. Nothing records where the work should go after a no.

In ConvOps, a step can name an on_rejected target, any step of the same workflow. Rejecting the advance moves the run straight to that step, for example from approve-draft back to revise-draft, and the task takes that step's status. The step history keeps a rejected row and the audit marks the verdict. A step with no on_rejected target refuses the rejection, so the run stays at the gate.

{
  "id": "approve-draft",
  "on_rejected": "revise-draft",
  "gate": { "requires_approval": true, "prompt": "Publish this draft?" }
}

workflow_advance(task_id="…", approved=false)
→ current_step: "revise-draft"

How do I remove gates as trust grows?

Start with approvals on every step. As trust grows, let the work run on its own. Remove a gate when the record shows it never changes the outcome, and keep it where the consequence is high.

Frequently asked questions