Most teams that let an AI agent issue refunds start with a simple guardrail: a per-action limit. Each refund the agent issues has to stay under some amount, and anything bigger goes to a person.
That limit is useful, but it answers the wrong question. It tells you how much a single refund can be. It doesn't tell you how much a single order can lose.
Picture an order that's been touched by more than one automated path. A support agent handles the chat. A returns agent processes the return label. A billing agent cleans up a duplicate charge. Each one stays inside its own limit, and each one decides a refund is reasonable.
Three refunds of $100 on the same order is still $300 out the door, and no single rule was broken.
The same thing happens with one agent, too. If a customer opens three chats about the same order, or a retry runs after a timeout, each run sees a fresh request and applies the same per-action check. Nothing in that check knows what already happened.
The fix is to make the limit about the order, not the action:
Store credits, gift cards, and shipping refunds count too. If they're tracked separately, the total is wrong.
You don't need a new system to start. Write down your total refund cap per order, in one sentence, and check whether every refund path, automated or human, can actually see it. If the answer is "only some of them," that's the gap to close first.
If you run agents that can move money, I'm curious how you've handled this: Disclosure: I run AgentRisk, a written risk report for customer-facing AI agents. This post is adapted from one of the short risk tips I publish. More at https://rleffke.com/agentrisk