How to stop AI agent refunds when every check says yes
Your support agent is allowed to call the refund API. Your identity provider says so, your gateway says so, and the API key works. So when the agent decides a customer deserves $4,500 back, every check you have says yes.
That is the problem. Most controls for AI agents answer one question: can this agent reach this system? For a refund, the risk isn't in reaching the billing system. It is in the call itself: how much, for which invoice, on whose behalf, and how often.
So to stop AI agent refunds you never meant to allow, you need payment controls that work at the level of the call. AI agent payment controls are checks that look inside each payment or refund request: the amount, the record and the person the agent acts for. Reach is only the first question. This article walks through those checks on one refund flow and shows where they belong. For the wider picture, see our practical guide to AI agent security.
Access is a yes or no. Refunds aren't.
Picture a support team that gives its agent a refund tool so customers stop waiting for a person. A sensible finance team would want five things answered before any refund goes out:
- Is this agent allowed to issue refunds at all? Access control answers this one, and it is the only one most setups answer.
- Is the amount within limits? Per refund, per invoice, per week.
- Does the invoice belong to the customer on this case? An agent that can be talked into refunding someone else's invoice is an agent that can be robbed.
- Who is the agent acting for, and who approves the big ones? The person asking shouldn't approve their own request.
- Can we prove what happened later? Every decision, including the ones that said no.
Questions 2 to 5 depend on the arguments of the call and on data the agent doesn't hold. A prompt can't enforce them, because a prompt is a request, not a rule: a hidden instruction in a customer email can talk an agent out of it.
What it looks like when each action is checked
Northwind's support agent works for Priya, a support lead. Here is what happens to four refund requests when every call is checked against Northwind's billing rules:
| Request | What happens |
|---|---|
| $40 on a customer's invoice | Runs straight away |
| $450 on the same invoice | Held for Dana in Finance. Priya can't approve it, because the agent acts for her. Once Dana approves, it runs once; asking again is held again |
| $4,500 | Blocked: Northwind allows at most $2,000 per invoice per week |
| A refund on an invoice that belongs to another customer | Denied: the invoice is read first, and it isn't this customer's |
The agent gets a short reason and a receipt number, never the rule's details or the invoice's data. When the same agent looks a customer up in the CRM, the social security number comes back masked, because the agent has no business seeing it.
Two different controls are at work here. The $2,000 cap is a spending limit on a record over a period. The $450 hold is human approval for one specific call.
(Northwind is a simulated company used in AgentFort's recorded lab demos.)
Write AI agent refund limits the way finance says them
None of this needs code in the agent. Northwind's billing owner writes rules in plain English:
- Support agents may issue refunds up to $100 without approval.
- Larger refunds need approval from Finance, and the person the agent acts for can't approve their own request.
- No more than $2,000 may be refunded per invoice per week.
- A refund must be for an invoice that belongs to the customer on the case.
Each rule becomes a precise policy the owner can read, test against examples and replay against last week's real requests before it goes live. A second person approves it, and only then does it take effect.
Precise policy languages make the edge cases explicit. In Cedar, for example, a request with no matching permit is denied, and an explicit forbid always overrides any permit. That is the behavior you want for money: anything not granted is refused, and a hard limit can't be loosened by a broader rule elsewhere.
Enforce at the service, not in the agent
You could build these checks into your own agent. They would protect that one agent. The billing API is also called by your vendor's agents, by the coding agent a developer runs on a laptop, and by whatever team ships an agent next quarter.
OWASP's guidance on excessive agency points the same way: implement authorization in downstream systems rather than relying on a language model to decide whether an action is allowed. So the checks belong in front of the service:
- The gateway holds the credentials. Agents never get the billing key, so going around the checks isn't possible.
- The network agrees. Agents can reach the gateway and nothing else.
- It fails closed. If the policy service is unreachable, the gateway keeps the last signed rules for a short lease, then refuses every call.
- Every call leaves a receipt, chained so that a missing or edited entry shows, and stored in your own account. See audit trails for AI agents.
In our lab tests the gateway added about one millisecond at the 95th percentile. Your agent won't notice; your auditor will. None of this means replacing the API gateway you already run; we cover that in where decisions about agent actions belong.
A checklist for any agent that touches money
- List every agent that can call a payment, refund or billing API, including vendor and coding agents. If you can't name them all, start with AI agent discovery.
- Give each one its own identity and an owner. No shared keys.
- Take the API credentials away from the agents. Something in front of the service should hold them.
- Write limits per call, per record and per period, not just "allowed".
- Check that the record belongs to the customer the agent is serving.
- Route large actions to a named approver who isn't the person asking.
- Keep a tamper-evident record of every decision, including denials.
- Decide what happens when the checks are down. The right answer is "nothing gets through".
Where AgentFort fits
Your agent is allowed to call your billing API. AgentFort decides whether this $4,500 refund should happen. It checks the call itself: the operation, its arguments, the record it touches, who the agent acts for, the budget, and what comes back. Enforcement runs on your side, next to your services, alongside the gateway and identity provider you already run. AgentFort calls the billing API with its own credential, scoped to that one operation, so agents never hold the key. Owners write rules in plain English, and AgentFort compiles them into Cedar rules they can read, test and replay before publishing. You can watch the $40 and $450 refunds in the AgentFort Access demo. If you are putting agents on systems that move money or hold regulated data, we are recruiting design partners for evaluations in their own cloud. Write to [email protected].
Frequently asked questions
How do I set refund limits for an AI agent?
Put limits on the arguments of the call, not only on access. A common pattern has three tiers: small refunds run on their own, larger ones need a named approver, and a cap per record per period, such as per invoice per week, stops many small refunds adding up. Keep the running totals where the call is executed, outside the agent, so a manipulated agent can't reset or ignore them.
Can a system prompt stop an AI agent from issuing refunds?
No. A system prompt guides the model; it doesn't enforce anything. OWASP describes indirect prompt injection, where instructions arrive in content the model reads, such as a website or a file. A customer email can carry one. Use the prompt for tone and process, and enforce amounts, records and approvals in the system that executes the refund, where the model's output can't change the rule.
Who should approve a large refund requested by an AI agent?
Someone outside the request, usually Finance or the billing owner. Never the person the agent acts for, because that person is effectively the requester. The approver should see the exact call, including the amount, the invoice and the customer, and the approval should cover that one call. A repeat request should need a fresh approval, so a single yes never becomes standing permission.
Is rate limiting enough to control AI agent payments?
No. Rate limiting counts requests. Kong's Rate Limiting plugin, for example, limits how many HTTP requests can be made in a given period. A payment limit counts money against a record over a period, which means reading the amount from the request and keeping a running total per invoice or customer. Ten requests an hour is a modest rate, but at $4,500 each it moves $45,000. Use both.