Human Approval Gates in Agent Workflows

Agent approval gates are checkpoints where an autonomous agent pauses before a consequential action and waits for a human to confirm, edit, or reject it. You need them the moment an agent can do something you cannot cheaply undo: send an email, charge a card, delete a row, push code, or call a paid API. This article walks through where to put agent approval gates, how to build them with plain tool interception, with LangGraph's interrupt primitive, and with MCP elicitation, plus the logging and timeout details that separate a demo from something you can run in production.

Why Agent Approval Gates Matter Now

Agent frameworks make it trivial to hand an LLM a list of tools and let it loop: read a request, pick a tool, run it, observe the result, decide the next step. That loop is powerful and also indifferent to consequences. The model has no innate sense that delete_customer is scarier than list_customers. It will call either one with the same confidence if the prompt nudges it that way, and prompt injection from a tool result or a scraped web page can nudge it in ways you did not intend.

Agent approval gates fix this by putting a human (or a deterministic policy) between "the agent decided to act" and "the action actually ran." This is different from just reviewing agent output after the fact. Post-hoc review catches mistakes once the email is already sent. A gate catches them before the side effect happens, which is the only point where catching them is free.

Three properties make a good agent approval gate:

• It intercepts at the tool-call boundary, not inside the model's reasoning. You cannot reliably stop a model from "wanting" to do something; you can reliably stop the function call that would do it.
• It shows the reviewer enough context to decide fast: which tool, with what arguments, and why the agent chose it.
• It has a default behavior on timeout or ambiguity that fails closed (deny or pause), never open (auto-approve).

Where to Place Approval Gates in a Workflow

Not every tool call needs a gate. Gating everything turns the agent into a chatbot with extra steps and burns out your reviewers, who will start rubber-stamping after the tenth "approve read-only search" prompt in a row. The useful pattern is a risk tier per tool, decided once at design time:

• Tier 0, auto-run: read-only calls with no side effects, like searching a knowledge base, querying analytics, or fetching a webpage. No gate.
• Tier 1, log and run: reversible writes with a cheap undo, like creating a draft or adding a label. Run immediately, but log the call so a human can audit or revert later.
• Tier 2, gate required: irreversible or costly actions, like sending an external message, moving money, deleting data, deploying code, or calling a metered third-party API above a spend threshold. These always stop for approval.

Assign the tier to the tool definition itself, not to the agent's judgment. If the agent decides on the fly whether an action is risky enough to ask about, you have reintroduced the exact problem you were solving. The tier belongs in code, next to the tool's schema, so it cannot be talked out of it by a clever prompt.

Designing an Approval Gate: Patterns

There are three common shapes for an agent approval gate, and most production systems end up using a mix.

Synchronous blocking gate. The agent process pauses mid-execution and waits on a queue, a webhook, or a CLI prompt until a human responds. Simple to reason about, but it ties up a worker for however long the human takes, so it only works well for short-lived agent runs or when you can checkpoint state and resume later.

Async ticket gate. The agent proposes the action, writes it to a pending-actions table or a Slack channel as a card, and ends its turn. A separate process (or a cron job) checks for approvals and resumes the agent, or a person just clicks "approve" and a webhook fires the actual tool call. This scales better for long-running or multi-day workflows and lets you use whatever review UI your team already lives in.

Policy-plus-human gate. A deterministic policy (dollar threshold, allowlist of recipients, rate limit) auto-approves the easy 90% and routes only the remainder to a human. This is the pattern that actually survives contact with volume, because a human reviewing 500 approvals a day stops reading them carefully.

Whichever shape you pick, the gate needs to live outside the agent's own control flow. If the "ask for approval" step is just another tool the agent can call, an agent that has been prompt-injected can simply skip calling it and call the risky tool directly instead. The gate has to be enforced by the code that executes tool calls, not by the model choosing to be polite.

Implementing Approval Gates with Tool Interception

The most portable pattern works with any LLM SDK that returns tool-use requests as structured objects instead of directly executing them: intercept the tool call before you execute it, check its tier, and only run it if it is auto-approved or a human has approved it.

Here is a minimal version using the Claude API's tool-use loop in Python:

import anthropic

client = anthropic.Anthropic()

GATED_TOOLS = {"send_email", "charge_card", "delete_record", "deploy_service"}

def call_tool(name, arguments):
    if name == "send_email":
        return send_email(**arguments)
    if name == "search_docs":
        return search_docs(**arguments)
    raise ValueError(f"unknown tool: {name}")

def request_human_approval(tool_name, arguments, reasoning):
    print(f"APPROVAL NEEDED: {tool_name}({arguments})")
    print(f"Agent reasoning: {reasoning}")
    answer = input("Approve? [y/N/edit]: ").strip().lower()
    if answer == "y":
        return True, arguments
    if answer == "edit":
        raw = input("New arguments (JSON): ")
        import json
        return True, json.loads(raw)
    return False, arguments

def run_agent_turn(messages, tools):
    response = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        tools=tools,
        messages=messages,
    )

    tool_results = []
    for block in response.content:
        if block.type != "tool_use":
            continue

        if block.name in GATED_TOOLS:
            approved, final_args = request_human_approval(
                block.name, block.input, reasoning="see prior assistant text"
            )
            if not approved:
                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": "Action denied by human reviewer.",
                    "is_error": True,
                })
                continue
            result = call_tool(block.name, final_args)
        else:
            result = call_tool(block.name, block.input)

        tool_results.append({
            "type": "tool_result",
            "tool_use_id": block.id,
            "content": str(result),
        })

    return response, tool_results

The important line is if block.name in GATED_TOOLS. The check happens after the model has decided what it wants to do, but strictly before call_tool runs anything with side effects. If the human denies the action, the agent gets a normal tool result saying so and can adapt, apologize, or try a different approach, but the email never went out.

For an async version, replace request_human_approval with a function that writes a row to a pending_approvals table and returns immediately, then a separate resume worker picks up the approval later and re-enters the loop with the tool result filled in. The shape of the interception does not change, only whether it blocks or checkpoints.

Human-in-the-Loop with LangGraph's Interrupt

If you are building on LangGraph, you get a built-in primitive for this instead of hand-rolling the queue: interrupt. It pauses graph execution at a node, returns control to your application, and resumes exactly where it left off once you call the graph again with a resume value.

from langgraph.graph import StateGraph, END
from langgraph.types import interrupt, Command
from langgraph.checkpoint.memory import MemorySaver

def propose_action(state):
    return {"proposed_tool": "send_email", "proposed_args": state["draft_email"]}

def approval_gate(state):
    decision = interrupt({
        "tool": state["proposed_tool"],
        "args": state["proposed_args"],
        "question": "Approve this email before it sends?",
    })
    if decision.get("approved"):
        return {"approved_args": decision.get("edited_args", state["proposed_args"])}
    return {"approved_args": None}

def execute_action(state):
    if state["approved_args"] is None:
        return {"status": "denied"}
    send_email(**state["approved_args"])
    return {"status": "sent"}

graph = StateGraph(dict)
graph.add_node("propose", propose_action)
graph.add_node("gate", approval_gate)
graph.add_node("execute", execute_action)
graph.set_entry_point("propose")
graph.add_edge("propose", "gate")
graph.add_edge("gate", "execute")
graph.add_edge("execute", END)

app = graph.compile(checkpointer=MemorySaver())

Running this stops at approval_gate and returns an __interrupt__ payload to your caller instead of finishing. Your application shows that payload to a human in whatever UI you have, be it a Slack message or an internal dashboard, then resumes with:

config = {"configurable": {"thread_id": "email-42"}}
app.invoke({"draft_email": {"to": "customer@example.com", "body": "..."}}, config=config)

# later, once a human clicks approve in your UI:
app.invoke(Command(resume={"approved": True}), config=config)

The checkpointer persists state between the pause and the resume, so this works even if the human takes a day to respond, and it works across process restarts because the state lives in the checkpoint store, not in memory. This is the pattern to reach for once your agent approval gates need to survive longer than a single request-response cycle.

Approval Gates for MCP Tool Calls

When an agent's tools come from an MCP server rather than functions you wrote yourself, you have two extra layers to gate: the MCP client (the agent host, like Claude Code or Claude Desktop) and the MCP server itself.

On the client side, most MCP hosts already support per-tool approval settings. In Claude Code, you control this in your settings file:

{
  "permissions": {
    "allow": ["mcp__filesystem__read_file"],
    "ask": ["mcp__filesystem__write_file", "mcp__stripe__create_charge"],
    "deny": ["mcp__filesystem__delete_file"]
  }
}

allow runs without a prompt, ask triggers an interactive confirmation with the tool name and arguments shown to you, and deny blocks the call outright regardless of what the agent wants. This is the same tiering idea from earlier, just expressed as host configuration instead of application code.

On the server side, the MCP specification has an elicitation capability that lets a tool ask its caller for missing information or confirmation mid-call, rather than relying entirely on the client's static permission list. A payments MCP server can implement its create_charge tool so that any charge over a threshold triggers an elicitation request back to the human operating the client, even if the client's own permission config would have auto-approved it. Building this in at the server layer means the gate travels with the tool: any agent that connects to your MCP server gets the same safety check, instead of every integrator having to remember to configure it themselves.

Logging, Audit Trails, and Timeout Handling

An approval gate that is not logged is a liability disguised as a safety feature, because nobody can later answer "why did the agent do that" or "who approved it." At minimum, record for every gated call:

• the tool name and full arguments as proposed by the agent
• the agent's stated reasoning or the preceding assistant message, if you have it
• who approved or denied it, and when
• whether the arguments were edited before approval, and what changed
• the actual result of the call once it ran

def log_approval_event(tool_name, args, reasoning, reviewer, decision, edited_args=None):
    event = {
        "tool": tool_name,
        "proposed_args": args,
        "reasoning": reasoning,
        "reviewer": reviewer,
        "decision": decision,
        "edited_args": edited_args,
        "timestamp": datetime.utcnow().isoformat(),
    }
    audit_log_table.insert(event)

Timeouts need explicit handling too. Decide up front what happens if nobody responds: does the pending action expire after a set window and get auto-denied, does it escalate to a second reviewer, or does the agent's whole run stay paused indefinitely. For most workflows, auto-deny-on-timeout with a clear notification is the safest default, since a silently expired approval that nobody noticed is worse than an agent that asked and got told no.

Common Mistakes When Building Approval Gates

Gating in the prompt instead of in code. Telling the model "always ask before sending an email" in the system prompt is a suggestion, not a control. A well-crafted injected instruction in a tool result can override it. The enforcement has to sit in the code path that actually invokes the tool.

Showing raw JSON to reviewers. A wall of nested arguments is slow to review and easy to rubber-stamp without reading. Render the gated action in plain language: "Send an email to customer@example.com with subject X" reads faster and gets a more honest yes or no than the raw payload.

No edit path. If the only options are approve or deny, reviewers will often approve a slightly-wrong action just to avoid restarting the whole agent run. Letting a human tweak the arguments before approving, like the amount on a refund or the recipient on an email, keeps the workflow moving without lowering the bar.

One tier for every tool. Gating a read-only search the same way you gate a wire transfer trains reviewers to stop reading. Keep the risk tiers real and keep the truly automatic tools automatic.

Forgetting the deny path is a real outcome. Build and test what happens when a human says no. The agent should get a clear tool result explaining the denial and be able to continue the conversation sensibly, not crash or silently retry the same call.

FAQ

What is an agent approval gate? It is a checkpoint in an agent's workflow where a proposed tool call is paused before it executes, so a human (or a deterministic policy) can approve, edit, or reject it before any real-world side effect happens.

Which agent actions actually need a human approval gate? Anything irreversible, costly, or externally visible: sending messages, moving money, deleting data, deploying code, or calling a metered API past a spend threshold. Read-only actions like search or lookup usually do not need one.

Can I just tell the model in the system prompt to ask before risky actions? No, not on its own. That is a suggestion the model can be talked out of via prompt injection or a confusing tool result. The gate needs to be enforced by the code that executes tool calls, with the system prompt used only to shape the agent's behavior, not to guarantee it.

How do I handle an agent that needs approval mid-multi-day workflow? Use a framework with resumable state, such as LangGraph's interrupt with a persistent checkpointer, or build an async ticket system where the agent writes a pending action and a separate resume worker picks it up once approved.

Does MCP have built-in support for approval gates? Yes, in two places. MCP hosts like Claude Code let you set per-tool permissions (allow, ask, deny) in configuration. MCP servers can also implement the elicitation capability so a tool asks its caller for confirmation mid-call, which keeps the safety check attached to the tool itself rather than relying on every client to configure it.

What should happen if nobody responds to an approval request? Decide this explicitly rather than leaving it open-ended. Auto-deny after a fixed timeout with a notification to the requester is the safest default; escalation to a second reviewer is a reasonable alternative for time-sensitive workflows.