Approval Workflows for AI Agent Actions

An AI agent approval workflow has four parts, and most setups get only the first one right. Decide which actions need a person’s yes. Decide when the yes happens: before the work, at the moment of the action, or after the result. Decide who may give it, which is never the agent and rarely just whoever is nearest. And record what was approved precisely enough that a changed plan does not ride on an old yes. Get those four right and approvals stay few, quick and meaningful. Get them wrong and you have either a queue people click through without reading, or an agent that did something nobody agreed to while holding a genuine approval for something else.

Where a person should step in at all is covered in human in the loop for AI agents, and twelve worked cases are in human in the loop AI examples. This piece is about the mechanics once you know where: how the approval itself is built.

Which actions need an approval

Sort actions by what it costs to undo them, not by how clever they are. Three questions settle almost every case:

• Can it be reversed with one move, and is the reversal recorded? Filing a task, writing a plan, moving a card: no approval, just a record.
• Does it leave the building? Anything a customer, a supplier or the public will see needs a person first.
• Does it touch money, access or data you cannot get back? Payments, permission changes, hard deletes, migrations on live data: always a person.

Everything else runs. The MCP specification↗ (opens in a new tab) says there should always be a human in the loop with the ability to deny tool invocations, and that applications should present confirmation prompts for operations. Being able to deny is the requirement; asking about everything is not.

Before, during or after

There are three places an approval can sit, and each fits a different kind of work.

• Pre-approval, before the work starts. A person reads the plan and says yes to it, with limits. Fits work that is well understood and runs unattended, such as a fix whose steps are written down.
• Per-action approval, at the moment of the risky call. The agent works freely until it reaches one dangerous step, and the tool asks. Fits exploratory work where the risky step only becomes visible part-way.
• Post-review, after the result exists. The agent finishes, and a person checks the evidence before the work counts. Fits everything reversible, and should follow the other two as well.

Most real workflows combine them: approve the plan up front, have the tool ask again at the one irreversible call, and check the result at the end. The mistake is using per-action approval for everything, which produces dozens of prompts an hour and teaches people to approve without reading.

Who approves

• Never the agent. An agent may propose, prepare and ask. It never approves its own plan, and it never approves another agent’s.
• The person with authority over what is affected, not the person who happened to start the session. A developer can approve a refactor; the owner of the billing system approves a change to refunds.
• Someone other than the requester for the riskiest actions. The person who asked for a live migration should not also be the one who signs it off.
• A named deputy. An approval that waits a week because one person is away gets bypassed; name who covers.

What an approval must pin down

An approval is a record, and a vague one is worse than none because it looks like consent. Each one should fix five things:

1. What exactly was approved: the plan or the action as it read at that moment.
2. The limits: “web only, no API change”, “dev database only”, “no more than 50 emails”.
3. Who approved it, by name, and when.
4. What ends it: finishing, a time limit, or any change to what was approved.
5. What happened afterwards: done, given back with a reason, or stopped.

The fourth point is the one most workflows miss. If the plan is edited after the yes, the yes should lapse. Otherwise an approval for “fix the date format on invoices” can quietly cover whatever the plan says by the time an agent picks it up.

Approvals in the tools you already use

Per-action approval is usually a client setting. In Claude Code, permission rules↗ (opens in a new tab) come in three kinds: allow, ask and deny. They are evaluated deny first, then ask, then allow, so a matching ask rule prompts even when a more specific allow rule also matches. The documentation is explicit that these rules are enforced by Claude Code, not by the model: an instruction in CLAUDE.md shapes what Claude tries, but only the rules change what it is allowed to do.

{
  "permissions": {
    "allow": ["mcp__fenbs__fenbs_list_items", "mcp__fenbs__fenbs_comment"],
    "ask":   ["mcp__fenbs__fenbs_delete_item", "Bash(npm run deploy *)"],
    "deny":  ["Bash(git push *)"]
  }
}

A server can insist too. The Claude Code MCP documentation↗ (opens in a new tab) describes a _meta annotation, anthropic/requiresUserInteraction, that makes a tool prompt on every call, even in modes that otherwise skip prompts, and with no “don’t ask again” option. It is meant for tools whose prompt is the point, such as granting access.

Approvals that happen outside the terminal need a different shape. For apps built on claude -p, a PreToolUse hook can return defer, which, as the hooks reference↗ (opens in a new tab) explains, stops at the tool call, lets the calling app collect an answer in its own interface, and resumes the session afterwards. That is the building block for approving from a web page or a chat message rather than a terminal.

The protocol has a mechanism of its own. MCP elicitation↗ (opens in a new tab) lets a server ask the person a question in the middle of a tool call, and the person can accept, decline or cancel. The client must make clear which server is asking and offer clear decline and cancel options. Two rules matter for approvals: form mode must never be used to ask for passwords, keys or payment details, and URL mode, for anything sensitive, must not open the link without the person’s explicit consent.

Recording the approval

A “yes” in a chat window is gone when the window closes. Keep approvals where the work is tracked, on the task itself, so the approval, the plan it covered, the work and the check sit together. When someone asks later why an agent was allowed to do something, the answer should be one page, not a search through transcripts. An audit trail for AI agents explains what that record needs to contain.

A worked example on fenbs

fenbs builds pre-approval and post-review into the task. On a task that has a plan, a person presses “Let AI do this”, with an optional limits line such as “web only, no API change”. A task without a plan cannot be approved, because the approval is of what the plan says. Only a person can press it: on a team board someone with All Access, an Owner or Administrator, and on a personal board you. An AI assistant never pre-approves anything.

The approval is of the task as it reads. If the title, problem or plan changes afterwards, the card says it approved an earlier version, and no assistant takes it until a person approves it again. Comments added later are information for the assistant, not instructions.

1. An assistant with nothing else to do calls fenbs_next_approved_task. It gets the most urgent approved task in its project, with the plan and limits, held for it for a few hours so two assistants never take the same one.
2. It does what the plan says, inside the limits, fills in Testing and moves the task to Completed. If it cannot finish, fenbs_release_task gives it back to Next Up with the reason posted on it.
3. A person can stop it part-way with “Stop it” and a reason the assistant will see, or withdraw the approval with “Take it back”.
4. The card reads “AI done · check it” until a person presses “I’ve checked it”. That is the post-review, recorded against the task.

fenbs deliberately says nothing about committing or deploying: those follow your project’s own rules and your assistant’s permission settings, which is where the per-action approval lives. Filter the board by AI to see what is approved, being worked and waiting to be checked.