An AI agent approval workflow is the set of checks and sign-offs that must pass before an AI agent is allowed to take an action with real consequences, such as issuing a refund. Before money moves, the system should verify the customer and order, confirm the refund is eligible under policy, check amount limits and fraud signals, route anything above a threshold to a human, and execute the payment call only from deterministic code with an idempotency key and an audit log.
Key takeaways
- The AI agent should recommend a refund, not execute one directly. The payment call belongs to a deterministic service that enforces policy whatever the model says.
- Approval is tiered: low-value, clearly eligible refunds can be auto-approved; higher-value, unusual or flagged cases go to a human; some cases are blocked outright.
- Every limit the agent must respect, such as amount caps, refund windows and daily totals, should be enforced in code and checked again at execution time.
- Idempotency keys prevent the most expensive agent bug: the same refund issued twice after a retry.
- Log the request, the evidence the agent used, the decision, the approver and the payment result, so every refund can be explained to finance, auditors and the customer.
What is an AI agent approval workflow, and why do refunds need one?
An AI agent approval workflow is a control layer between what an AI agent decides and what the business system actually does. The agent gathers information and proposes an action; the workflow checks that action against identity, policy, limits and risk, decides whether it can run automatically, needs a person, or must be refused, and records the outcome. Refunds are the clearest case for one, because a refund moves money, is often hard to reverse, and is a known target for fraud.
The security community names this risk directly. The OWASP Top 10 for LLM Applications lists Excessive Agency (LLM06:2025) as the vulnerability that lets damaging actions happen in response to unexpected, ambiguous or manipulated model outputs, whatever the cause of the malfunction. OWASP traces it to three root causes: excessive functionality, excessive permissions and excessive autonomy. One of its main mitigations is human-in-the-loop control, requiring a person to approve high-impact actions before they are taken.
A refund agent can go wrong in several ways that an approval workflow is designed to stop:
| Risk | How it happens with an AI agent | What the workflow does |
|---|---|---|
| Wrong customer or order | The model confuses records or trusts an order number the user typed | Verifies identity and ownership in code before any action |
| Policy violation | The model is persuaded the refund window or condition does not apply | Checks eligibility deterministically against policy rules |
| Prompt injection | A message or attachment instructs the agent to refund more, or to another account | Executes only fixed actions with validated parameters; destination is always the original payment method |
| Duplicate refund | A timeout or retry sends the same refund twice | Uses an idempotency key and checks for existing refunds |
| Hallucinated confirmation | The agent tells the customer a refund was issued when it was not | Customer messages are generated from the payment result, not from the model’s intent |
| Abuse at scale | One account or pattern drains refunds through many small requests | Enforces per-customer and daily limits, and fraud signals |
The core design principle follows from this: the AI agent recommends, the workflow decides, and deterministic code executes.
The AB Ark pre-refund checklist: seven gates before money moves
Before an AI agent’s refund recommendation reaches the payment provider, it should pass seven gates in order. Each gate is enforced by code, not by the prompt, and any failure stops the refund or routes it to a person. This is an AB Ark editorial framework for agent design, not an industry standard; adapt the order and thresholds to your policy.
| Gate | What must be true | Checked by | If it fails |
|---|---|---|---|
| 1. Identity verified | The requester is the account holder, verified through your normal authentication, not by details typed into chat | Auth service | Ask the customer to sign in or verify; no refund |
| 2. Order and payment confirmed | The order exists, belongs to that customer, was paid, and has not already been fully refunded | Order and payment systems | Stop and explain; never trust an order ID the model infers |
| 3. Eligibility under policy | Reason, refund window, item condition, delivery status and product type all qualify under the written refund policy | Policy rules engine | Decline with the policy reason, or route to a person if the case is ambiguous |
| 4. Amount within limits | The amount does not exceed what was paid, the per-refund cap for auto-approval, or the customer’s and the system’s daily totals | Limits service | Route to human approval, or block above a hard ceiling |
| 5. Risk and fraud signals clear | No fraud flags, chargeback in progress, unusual refund history or mismatch between account and payment details | Fraud and risk checks | Route to the risk team |
| 6. Approval obtained | The refund’s tier (below) is satisfied: auto-approved by rules, or approved by a named person with authority for that amount | Approval service | Wait; an approval that times out must expire, never execute |
| 7. Execution is safe | The refund goes to the original payment method with an idempotency key, and a fresh check confirms nothing changed since approval | Payment service | Abort and re-run the checks |
Two details in this checklist address the most common design gaps. First, gate 2 and gate 7 both check for existing refunds, because the state can change between the moment an agent proposes a refund and the moment it executes. Second, gate 6 treats a timeout as a rejection. Arthur’s guidance on human-in-the-loop governance for AI agents makes the same point: an approval step that executes when nobody responds provides no control at all.
The agent’s job across these gates is to collect evidence and explain it: the customer’s request in their words, the order record it looked up, the policy clause it believes applies, and its recommended amount. That package is what a human approver sees, and what the audit log stores.
Approval tiers: when the agent can refund on its own
Not every refund needs a person. A tiered approval model lets clearly eligible, low-value refunds complete automatically, sends higher-value or unusual cases to a human, and blocks cases no one should approve through the agent. The tiers are set by business rules, never chosen by the model.
| Tier | Typical conditions | Who approves | What the customer experiences |
|---|---|---|---|
| Auto-approve | All seven gates pass; amount below your auto-approval cap; standard reason (for example, item not delivered and carrier confirms); clean account history | Rules engine | Immediate confirmation, generated from the payment result |
| Human review | Amount above the cap; partial or goodwill refunds; reason outside standard categories; first refund on a new account; any soft risk signal | Support lead or finance, with authority for that amount | “Your request is being reviewed” with an expected response time |
| Escalated review | High value; repeated refunds; possible fraud; dispute or chargeback open | Risk or finance team | Holding message; follow-up by a person |
| Block | Ineligible under policy; identity not verified; already refunded; destination differs from original payment | No one through the agent | Clear decline with the policy reason, and a route to a human if they disagree |
Set the auto-approval cap from data, not intuition. Start with a low cap, measure how often human reviewers overturn the agent’s recommendations in each category, and raise the cap only for categories where the agent’s recommendations are consistently upheld. The right cap for a software subscription will differ from the right cap for electronics or travel.
Example (illustrative, not a recommendation): an online retailer might auto-approve undelivered-item refunds below a set amount when the carrier shows no delivery scan, send all damaged-item claims to a person until photo checks are proven reliable, and block any refund to a payment method other than the original one.
The refund approval workflow, end to end
The full AI agent approval workflow for a refund runs in one direction: the customer’s request reaches the agent, the agent proposes, the refund service runs the gates and assigns a tier, and only approved refunds reach the payment provider.
AI agent refund approval workflow · request to payout in three tiers
Every path ends in the audit log, including blocked and rejected requests, and the customer’s message is written from the outcome, not from what the agent intended.
How to implement the approval workflow
Implementation comes down to four engineering decisions: give the agent a narrow tool that proposes rather than pays, enforce every rule in a separate refund service, make execution idempotent, and log everything. Agent frameworks now provide the approval pause; the business rules remain your code.
1. Give the agent a proposal tool, not a payment tool
The agent should never hold payment-provider credentials. Expose a tool such as propose_refund(order_id, amount, reason, evidence) that creates a refund request record. A separate refund service, which the agent cannot bypass, runs the seven gates, assigns the tier and, only when approved, calls the payment provider.
// Called by the agent. Creates a request; never moves money.
async function proposeRefund(input: RefundProposal, session: Session) {
const order = await orders.getForCustomer(input.orderId, session.customerId); // gate 2
if (!order) return { status: “rejected”, reason: “order_not_found_for_customer” };
const request = await refunds.createRequest({
orderId: order.id,
amount: Math.min(input.amount, order.refundableAmount), // never more than paid
reason: input.reason,
evidence: input.evidence, // stored for the approver
});
return refundService.evaluate(request.id); // gates 3-6, returns tier and status
}
// Runs only after approval. Re-checks state and pays once.
async function executeRefund(requestId: string) {
const req = await refunds.lockForExecution(requestId); // gate 7
const order = await orders.get(req.orderId); // state may have changed
if (req.status !== “approved” || req.amount > order.refundableAmount) return;
await payments.refunds.create(
{ payment: req.paymentId, amount: req.amount }, // original method only
{ idempotencyKey: `refund-${req.id}` } // same key on every retry
);
}
2. Use your framework’s approval pause, but keep the rules outside it
Agent frameworks support a pause before sensitive tool calls. In the OpenAI Agents SDK, tools can require approval, and the run records an approval interruption instead of executing the tool until a person resumes it. The same guide notes that agent-level input and output guardrails do not run around every tool call, and recommends tool guardrails and approval interruptions at the boundary where side effects happen. Treat these as the mechanism for pausing; keep amount caps, eligibility rules and tier logic in the refund service so they apply whichever framework or model you use.
3. Make execution idempotent
Retries are normal in agent systems: model timeouts, network errors and resumed approvals can all repeat a call. Payment providers handle this with idempotency keys. Stripe’s documentation explains that an idempotency key lets you safely retry a request without performing the operation twice; Stripe stores the result of the first request for a key and returns that same result to later requests with the key. Derive the key from your refund request ID, as in the sketch above, so every retry of the same refund carries the same key; a fresh random key per attempt defeats the purpose.
4. Log an audit trail for every refund
Record, for every request: the customer’s original message, the records the agent read, the policy clause it cited, its recommended amount and reasoning, each gate’s result, the tier, the approver’s identity and decision, the payment provider’s response, and the message sent to the customer. Store these outside the agent’s own memory or transcript, so they cannot be edited by the agent and survive model or framework changes.
Failure modes to design out
Most refund-agent failures come from trusting the model with something code should own. Each failure mode below has a structural fix.
- Approval only in the prompt. “Always ask a manager before refunding over the limit” in the system prompt is advice, not a control. Enforce limits in the refund service.
- Approvals that default to yes. A request left unanswered must expire, and the customer must be told; it must never execute on timeout.
- Rubber-stamp reviews. If approvers see a one-line summary, they approve by habit. Show the evidence package and the specific gate that triggered review, and track how long reviews take.
- Stale approvals. An approval granted on Monday should not execute on Friday after the order changed. Give approvals an expiry and re-check state at execution.
- Customer messages written from intent. The agent says “your refund is on its way” before the payment call succeeds. Generate confirmations only from the payment provider’s response.
- Over-broad tools. A general “update order” or database tool lets the agent change amounts or payment details. Expose only narrow, typed tools.
- Untested adversarial inputs. Test the workflow with manipulative messages, fake order numbers, requests for other customers’ orders and repeated small refunds before go-live, and after every model or prompt change.
Metrics to track
| Metric | What it tells you |
|---|---|
| Auto-approval rate by refund category | How much work the agent removes, and where |
| Human override rate | How often reviewers reverse the agent’s recommendation; the main signal for raising or lowering caps |
| Time to refund decision, by tier | Customer experience cost of each approval tier |
| Refunds reversed or disputed after approval | Quality of decisions that passed the gates |
| Duplicate refund attempts blocked | Whether idempotency and state checks are doing their job |
| Blocked requests by gate | Which policies customers hit most, and possible abuse patterns |
| Review queue age | Whether human approval capacity matches volume |
Frequently asked questions
Can an AI agent issue refunds without human approval?
Yes, for a defined set of low-risk cases. An AI agent can complete refunds automatically when every check passes in code, the amount is below a set cap and the case fits a standard category. Higher-value, unusual or flagged refunds should go to a person. The agent should never decide its own approval tier; business rules decide it.
What is the difference between guardrails and human-in-the-loop approval?
Guardrails are automatic checks that validate inputs, outputs or tool calls and block what breaks a known rule. Human-in-the-loop approval pauses an action until a person decides. Refund workflows need both: guardrails and policy checks clear routine cases at machine speed, and human approval covers cases that need judgment.
How do you stop an AI agent from issuing duplicate refunds?
Check the order’s remaining refundable amount immediately before execution, and send every refund call with an idempotency key derived from the refund request ID. Payment providers such as Stripe return the original result when a request is retried with the same key, so a retry after a timeout cannot pay twice.
How do you protect a refund agent from prompt injection?
Limit the agent to narrow tools that propose refunds, never tools that move money or edit payment details. Validate every parameter in code, look up orders only for the authenticated customer, send refunds only to the original payment method, and require human approval above a threshold. These controls hold even if a manipulated message changes what the model wants to do.
Which frameworks support approval steps for AI agents?
Most current agent frameworks offer a way to pause a tool call for human approval and resume it later; the OpenAI Agents SDK, for example, records an approval interruption before a sensitive tool runs. Durable workflow engines are also used to hold long approvals reliably. Whatever you use, keep refund policy and limits in your own service rather than in framework configuration or prompts.
The rule to build around
Before an AI agent issues a refund, identity, ownership, eligibility, limits, risk and approval must all be confirmed by code, and the payment must run once, to the original method, with a full audit trail. Let the agent gather evidence and recommend; let your refund service decide and execute. Start with a low auto-approval cap and raise it only where human reviewers consistently agree with the agent.
If you are deciding whether to build a custom agent for support workflows like this, AB Ark’s comparison of custom AI agents and off-the-shelf tools covers the trade-offs. To scope an agent with approval workflows built in, you can request a project estimate.
Head Of Engineering Department
