Human in the loop AI agent approval: when to ask and how to bind it

What human in the loop AI agent approval is

Human in the loop AI agent approval is a control that pauses a specific agent action until an authorized person approves it. The person approves one call: this operation, with these arguments, on this record, for this requester. Then the call runs once.

The OWASP AI Agent Security Cheat Sheet, from the Open Worldwide Application Security Project, sets the baseline: "Require explicit approval for high-impact or irreversible actions," "Implement action previews before execution," and "Set autonomy boundaries based on action risk levels." It also makes a point many designs miss. Deciding that an action needs review "does not grant permission to run a tool." An approved call must still pass per-call authorization and spending limits.

Approval suits decisions that need judgment a rule can't encode. Is this refund reasonable given the customer's history? Is this email safe to send outside the company? It is the wrong tool for things a rule can decide. If approvers always say yes to a request type, write a rule that allows it. If they always say no, write a rule that forbids it. Human-in-the-loop for agents is one control in a wider AI agent security program.

When to require approval: risk tiers

Set approval by risk tier, so people approve AI agent tool calls only where judgment helps. Judge risk from the arguments as well as the tool name. send_email to a colleague and send_email to a personal address are different actions.

OWASP's example puts read_file at low risk, write_file at medium, send_email and execute_code at high, and database_delete and transfer_funds at critical. Only low-risk tools skip review; unknown tools default to high. That is a safe start. The table below relaxes medium-risk writes, which suits teams with limits and audit in place.

An action moves up a tier when it can't be undone, leaves the company, moves money, touches many records, changes privileges or is new for this agent.

Bind the approval to the exact call and its arguments

An approval that says yes without saying to what is a blank check. The OWASP cheat sheet says a user_confirmed flag "is insufficient." The approval record should include the actor, tool name, target resource, normalized parameters, timestamp and expiry. The execution component must verify that the approval matches the current actor and the exact tool call. Any change to the target or parameters needs a new approval.

Online banking faced the same problem with transaction signing. OWASP's Transaction Authorization Cheat Sheet calls the principle "What You See Is What You Sign." Significant data must be "generated and stored on a server," and "any attempt to modify transaction data after user entry is an attack on the system." OAuth has a standard shape for the same idea. Rich Authorization Requests (RFC 9396) carry authorization_details, such as an instructedAmount and a creditorName, so consent covers one payment rather than a broad scope.

In practice, normalize the call: agent, person acted for, operation, record ID and arguments in canonical form. Store it on the server. Show the approver that stored version. At execution, compare the call to it field by field. Any difference means a new request.

Single use and expiry

An approval should be consumed by the call it approved. The OWASP cheat sheet says to check and consume it "in one atomic step immediately before execution," so concurrent or repeated requests can't reuse it. It also calls for short-lived authorization artifacts and replay protection for irreversible operations.

Match expiry to the business. Minutes suit an interactive refund. A few hours may suit a scheduled payment run. After expiry, the agent needs a new request.

An approval doesn't freeze the world. Re-run the policy and limits at execution, because the record or the budget may have changed since the approver looked. In the Northwind lab demo (Northwind is a simulated company used in AgentFort's demos), a Finance approver approves a $450 refund. It runs once, and the same request again is held again.

Separation of duties: who may approve agent actions

The US National Institute of Standards and Technology (NIST) defines separation of duty as "the principle that no user should be given enough privileges to misuse the system on their own." Its example: "the person authorizing a paycheck should not also be the one who can prepare them." For agent action approval, that becomes four rules.

• The person the agent acts for can't approve its request. Otherwise a hidden instruction plus a busy user equals self-approval.
• The approver owns the resource. Finance approves refunds. The owner of the customer relationship management (CRM) system approves bulk changes to customer data. Security reviews anything leaving the company.
• The approver is a person, signed in. The OWASP cheat sheet asks for step-up authentication for critical actions such as payment initiation, privilege changes, bulk deletion and production deployment.
• Critical actions get two people. NIST notes that separation can be enforced dynamically, at access time, and gives the two-person rule as an example.

Enforce these rules in the approval service, not through approvers' goodwill. Check eligibility when the approval is submitted, and record why each approver was eligible. Watch for pairs of people who routinely approve each other's requests.

Approval fatigue and how to avoid it

Approval fatigue sets in when people see so many requests that approving becomes a reflex. Security teams know it from sign-in prompts. A fact sheet from the US Cybersecurity and Infrastructure Security Agency (CISA) describes "push bombing," where an attacker can "generate hundreds of prompts on the user's device over a short period of time" until the user approves one. A manipulated agent can do the same to an approver. Normal volume can wear people down without any attacker at all.

Ways to keep each approval meaningful:

• Raise thresholds where limits already protect you. Let small refunds run under spending limits, and send people only the ones that need judgment.
• Batch only like with like. A batch shares one operation, one approver and one tier. It lists every item and lets the approver reject items one by one.
• Rate-limit requests. Cap pending approvals per agent. Deny a request repeated after a denial automatically, and tell the owner.
• Make the approver engage with the key value. CISA recommends number matching, which "forces the user to enter numbers from the identity platform." For critical actions, ask the approver to type the amount or the last digits of the destination account.
• Measure. Track approval rate and time to decision per approver. If nearly everything is approved within seconds, the step has become a rubber stamp.

Approvals and prompt injection: what the approver must see

The approver is the last check, which makes them a target. The OWASP Top 10 for Agentic Applications (2026) names this risk ASI09 Human-Agent Trust Exploitation. Its examples include a poisoned vendor invoice that leads a finance copilot to recommend an urgent payment to an attacker's bank account, which a manager approves. Another is an agent that fabricates a convincing explanation to hide what an action really does.

So build the request from facts, not from the agent's story. OWASP's mitigations ask for a "plain-language risk summary (not model-generated rationales)" and for previews that block state-changing calls, so opening a preview never triggers the action. An illustrative layout, facts first:

Refund approval · request A-2291 · expires in 30 min
Action      billing.createRefund, runs once
Amount      USD 450.00
Invoice     INV-1042, read from billing: customer C-77,
            paid USD 1,200.00, refunded this week USD 40.00
Agent       invoice-agent (owner: Billing Operations)
Acting for  Support lead J. Rivera (not eligible to approve)
Held by     Refunds over USD 100.00 need Finance
Agent note  UNVERIFIED, written by the agent: "Duplicate charge"
[Approve once]  [Deny]  [Report as suspicious]

Flag any value that came from untrusted content. If bank details arrived in an inbound email, say so, and show the details on file beside them. Data protection for agents can catch hidden instructions before the agent acts on them.

Approval channels and audit

Approvals reach people through a console queue, a chat tool such as Slack or Microsoft Teams, email, a ticketing system or a mobile push. The channel matters less than four properties:

• The approver signs in. A link that approves for whoever clicks it can be forwarded, opened by a link scanner or phished.
• Every channel shows the same summary, generated by the server.
• The decision returns over an authenticated path, tied to the request ID.
• Unanswered requests expire to "deny," with escalation to a backup approver.

OpenID Connect's Client-Initiated Backchannel Authentication (CIBA) is a useful model. It separates the device where an action starts from the device where a person approves it. Its optional binding_message is displayed "on both the consumption device and the authentication device to interlock them together for the transaction." Showing the same short code on the request and on the approval prompt helps an approver spot a mismatched request.

What to record about each approval

Record the request, the exact summary the approver saw, who approved and how they signed in, the decision, timestamps, expiry, the policy version and the execution result. Link them by one approval ID to the call's receipt. The OWASP cheat sheet lists "approval identifier" and "policy version" among the metadata to log for high-risk actions. It also asks teams to monitor "repeated approval bypass attempts" and drift in approval behavior. Record denials, expiries and ineligible approvers too, because manipulation shows up there. Redact sensitive values rather than logging them in plain text. An auditor should be able to answer, for any refund, who approved it, what they saw and whether the call that ran matched. See AI agent audit trails.

Checklist for approving AI agent tool calls

Use this list when you add approval to any agent workflow.

• Classify every operation by risk tier, using arguments as well as the tool name.
• Send new and unknown tools to approval until someone classifies them.
• Bind each approval to the normalized call: agent, person acted for, operation, record and arguments.
• Consume approvals atomically, once, and expire them.
• Re-check policy and limits at execution.
• Block the person the agent acts for from approving its requests.
• Route approvals to the resource owner, with step-up sign-in for critical actions.
• Build the summary from the system of record, and label the agent's explanation as unverified.
• Separate preview from effect.
• Cap pending requests per agent, and auto-deny repeats after a denial.
• Track approval rate and time to decision, and add rules where approvals are reflexive.
• Log every request, decision, expiry and execution result.

How AgentFort handles this

In AgentFort Access, a call that needs approval is held, and the approver sees the exact call and approves it. It runs once; asking again needs approval again. The person an agent acts for can't approve that agent's request. At Northwind, refunds under a threshold run, and larger ones are held for Finance. AgentFort Isolation applies the same rule to a sandboxed agent's one way out. Anything leaving the company is held for a person. The person the agent acts for can see a held message but can never approve it; a security reviewer decides. Every decision leaves a receipt, chained so a missing or edited entry shows. See AgentFort Access and AgentFort Isolation, watch a demo or become a design partner.