Policy-gated actions: letting AI issue refunds without risk

AI refunds automation is the point where most support teams hesitate, and rightly so: a wrong answer costs goodwill, but a wrong refund costs money and, repeated, invites fraud. Policy gating is how the risk is bounded. The business writes the rules under which a refund or return is automatically acceptable. An agent may act only inside those rules, and the rules are enforced in code where the agent cannot override them. Anything outside goes to a person with the case already prepared.

This article explains how gates are designed, what a refund policy looks like when it is written for a machine, how gates widen over time, and what the finance team should expect to see.

What policy gated AI actions are and why the prompt is not enough

A gate is a rule, evaluated by code at the moment an action is about to happen, that returns one of three results: allow, require approval, or refuse. The agent calls the refund tool; the tool evaluates the gate; the money moves only if the answer is allow. If the answer is require approval, the tool returns that result and the agent prepares the case for a person. If refuse, the agent explains and escalates.

Putting the rule in the prompt instead ("only refund orders under a certain value") does not work, for three reasons. The model may misread the value. A customer may argue, and models are trained to be helpful. And content the agent reads, such as an email with hidden instructions, can override prompt rules. A gate at the tool layer holds regardless. The broader guardrail design is in How to build an AI agent that is safe to run unattended.

Gate outcomes at a glance

Writing a refund policy a machine can evaluate

Most refund policies are written for humans and contain judgement words: "reasonable", "at our discretion", "where appropriate". The first task of an AI returns automation project is translating that into conditions a program can check. In practice the conditions are a short list.

• Value. Refund amount relative to a per-action cap, and cumulative amount per customer per period.
• Timing. Days since delivery, and whether the return window has passed.
• Evidence. Whether required proof exists: a delivery scan, a photo of damage, a carrier claim.
• History. Number of refunds or returns for this customer in a period, and any open disputes.
• Product. Categories excluded from automatic handling, such as perishables or personalised items.
• Channel and identity. Whether the customer is verified on this channel and the order belongs to them.

Each condition gets a threshold, an owner and a change process. The judgement cases, such as "customer says the item never arrived but tracking shows delivered", are not automated; they are gated to a person with the evidence assembled. The policy owner is usually the head of support with finance sign-off, and the translated policy becomes configuration the agent reads at runtime and the tool enforces.

How safe AI support actions widen over time

Gates start narrow. In shadow mode the agent proposes every refund and a person approves, which builds a record of how often the proposal matched what the person would have done. When an intent is promoted, the value cap begins low and the frequency limit tight. Each week, the support lead reviews the approval queue and a random sample of automatic refunds. If the sample is clean and the queue is full of cases the agent got right, the cap widens. If either shows a problem, it narrows, and the case joins the evaluation suite. The staged approach is described in Shadow mode.

Two thresholds tend to stay in place permanently: a hard per-action maximum above which no automatic refund happens whatever the evidence, and a daily total across all customers that pauses automation and alerts a person if reached. These are the circuit breakers, and they are set by finance rather than by support.

The approval queue is a product, not an inbox

When a gate returns "require approval", the quality of what the person receives decides whether gating is a saving or a bottleneck. The case should contain the customer's request, the order and delivery details, the evidence gathered, the rule that triggered the gate, the agent's proposed action and its reasoning, and one-click approve, edit and reject controls with a reason. A support lead should be able to clear a well-prepared case in a fraction of the time it would take to handle from scratch. Rejection reasons feed the weekly review and the evaluation suite, exactly as in How to measure an AI agent.

Fraud and abuse patterns

Automated refunds attract people who test the rules. The gate design answers this with frequency limits per customer, per address and per payment instrument; with evidence requirements that are checked against systems of record rather than taken from the customer's message; and with pattern flags that route repeat cases to a fraud review rather than to a support lead. The audit trail, with every refund tied to the rule that allowed it and the evidence used, is what lets finance and the fraud team investigate afterwards. Payment providers publish their own dispute and refund rules; Stripe's refunds documentation is a useful primary source on what happens on the gateway side once a refund is issued.

What finance sees

Finance wants four things: total automatic refund value per period against the circuit-breaker limit, the distribution of refunds by rule (which conditions are allowing most of the money out), the sample-review error rate, and the number of gated cases and their approval outcomes. Presented monthly alongside handling time returned, this is the evidence for widening the gates or holding them. The measurement framework for the support side is in AI ticket deflection is the wrong metric.

A worked example

A direct-to-consumer brand handled returns and refunds over WhatsApp with a small support team. Their written policy was two paragraphs of judgement. Translating it produced six conditions with thresholds the founders signed off, plus a per-action maximum and a daily circuit breaker set by their finance lead. The agent ran in shadow mode, proposing every refund; the acceptance rate on low-value damaged-item cases was high quickly, while "not received" cases were deliberately kept human.

Once promoted, low-value refunds with photo evidence and a delivery scan ran automatically inside a tight cap; everything else went to the approval queue with the case prepared. The cap widened over subsequent weeks as sample reviews stayed clean, and a frequency flag caught a small number of repeat claimants that the team had not previously noticed. The personalisation and WhatsApp agent case study describes the deployment; the build is a customer service agent.

Team and timeline

Policy translation takes a week with the head of support and a finance owner, and is part of the first two weeks of a customer service agent build, from $12,500 or ₹8 lakh, rising with the number of intents and systems. The tool layer that enforces gates over your order and payment systems is built by a backend engineer, often as an MCP server as described in MCP explained, and where refunds are one step in a wider multi-system process the scope becomes a multi-agent system. Shadow mode runs two to four weeks. After launch, a Standard Care Plan at $2,500 or ₹1,60,000 a month covers the weekly sample review support and eval reruns. Prices are on the pricing page; if you run on TheEazy CXM, the tool layer is already available.

Before you start: a checklist

• Rewrite the refund and returns policy as conditions with thresholds
• Name the policy owner and the finance owner who signs circuit breakers
• Confirm evidence sources: delivery scans, carrier claims, photo storage
• Decide which cases stay human permanently, such as not-received claims
• Set the per-action maximum and the daily total that pauses automation
• Design the approval queue with one-click controls and mandatory reasons
• Add frequency limits per customer, address and payment instrument
• Build eval scenarios including argumentative customers and hidden instructions

Questions clients ask

• Will customers game the agent? Some will try. Frequency limits, evidence checked against systems of record and the circuit breaker bound the exposure, and the audit trail catches patterns.
• Can the agent be talked into a refund? Not above the gate. The prompt can be argued with; the tool cannot.
• What if our policy really is discretionary? Then the discretionary cases are gated to a person and only the clear ones are automated. That still removes most of the volume.
• Does this work for exchanges and store credit? Yes; each is a separate tool with its own gate, and store credit often gets a wider cap than cash.

Related reading

AI customer service agents: resolve, don't deflect covers the wider support agent design, How to build a support agent that knows the customer's order covers the account access refunds depend on, and the WhatsApp AI chatbot article covers the channel most D2C brands use.

Write the rules down, enforce them where the model cannot reach, and refunds become the intent your support team is happiest to hand over.