AI agent spending limits: how to cap refunds, credits and payments

What AI agent spending limits are

AI agent spending limits are policy rules that cap how much money an agent can move through business actions such as refunds, credits, discounts and payments. They apply per call, per record, per period and per agent. They are enforced outside the agent, at the point that executes the action.

Access control can't express them. A support agent that may call the refund API may refund any amount the API accepts. The payment provider's own ceiling is usually the charge itself. Stripe's refund API, for example, raises an error "when trying to refund more money than is left on a charge." That stops a $5,000 refund on a $1,200 invoice. It doesn't stop a $1,200 refund that should have been $12.

The Open Worldwide Application Security Project (OWASP) already treats unguarded business flows as an API risk: API6:2023, Unrestricted Access to Sensitive Business Flows. For agents, the OWASP Top 10 for Agentic Applications (2026) recommends usage limits on tools under ASI02 Tool Misuse and Exploitation, such as rate limits and budgets that throttle or cut off an agent that exceeds them. Spending limits are the money version of that ceiling. They work alongside per-call authorization and human approval as part of a wider AI agent security program.

Per-call, per-record, per-period and per-agent limits

Each limit makes two choices: what it counts against, and over what period. A per-call limit caps the largest single action. A per-record limit caps the total on one invoice, order or customer. A per-agent limit caps what one agent moves across all records. The period sets the window for each total, such as a week per invoice or a day per agent. A total per person acted for stops one person from steering several agents into several full budgets.

Prefer rolling windows to calendar windows. With a calendar week, an agent can spend the full cap on Sunday night and again on Monday morning.

Currency and unit pitfalls

Most payment APIs take amounts as integers in the currency's smallest unit. As of October 2026, Stripe's currency guide is explicit: 1000 charges 10 USD, while 10 charges 10 JPY, because the yen is a zero-decimal currency. An agent that sends 450 meaning $450 has asked for $4.50. A limit of 100 written in dollars and checked against cents blocks almost everything. Written in cents and checked against dollars, it is 100 times too generous.

Exceptions exist even within one provider. Stripe represents the Icelandic króna (ISK) as a two-decimal value for backward compatibility, although you can't charge fractions of it. So:

• Normalize every amount to a pair: currency code plus integer minor units, using the exponent table of the API you call.
• Do the conversion at the enforcement point, from the API schema, never from the model's wording.
• State every limit with its currency. "$2,000" is a USD limit. Refunds in EUR need their own limit or a named conversion rate.

Missing amounts, lists and retries

Three more traps catch teams that get units right:

• Missing amount. In Stripe's refund API, amount is optional, and you "can optionally refund only part of a charge." Leave it out and the rest of the charge is refunded. A limit check must treat a missing amount as the largest value the call could move, read from the record.
• Lists. A tool that takes an array of line items, or a quantity and a unit price, needs the limit applied to the computed total and to each record in the list.
• Retries. Stripe's idempotency keys let a client retry "without accidentally performing the same operation twice," and Stripe errors if the parameters differ. Count budget by business effect. A retry with the same key consumes budget once; a new key is a new refund.

Counting AI agent budgets across services and agents

The same money can leave through several doors. A refund in the billing API, a credit note in the finance system, a goodwill credit in the customer relationship management (CRM) system and a gift card from the support tool all move value to a customer. If each door has its own limit, an agent blocked at one tries the next. Map every money-moving operation to one normalized "value out" measure and count them all against shared limits.

Counters must live outside the agent, in a store the enforcement point controls. The agent's memory isn't a ledger. Two concurrency traps follow:

• Races. Two parallel calls each see $1,900 spent against a $2,000 cap, and each adds $90. Reserve the amount atomically before calling the service, and release it if the call fails.
• Stale decisions. A workflow can check a limit when it starts, then act hours later, after the limit has been lowered. Evaluate limits when the action executes, not when the agent plans it.

Decide too whether amounts waiting for approval count. Treating them as reserved stops an agent from spending the remaining headroom while a large request waits.

What happens at the limit: block or hold for approval

Every limit needs a defined outcome. There are three:

• Run. Under every threshold, the call proceeds and is logged.
• Hold for approval. Above a soft threshold, the exact call waits for a named approver who isn't the person the agent acts for. If approved, it runs once.
• Block. Above a hard cap, the call is refused, and no approval can lift it.

Decide per limit which kind it is. A per-call threshold is usually soft: large refunds are sometimes right, and a person should look. A per-record weekly cap is usually hard. If an invoice has already had $2,000 back this week, another refund is a pattern to investigate, not a request to approve. The human approval guide covers how to bind an approval to the exact call.

Return a short reason code and a reference number to the agent. Don't return the rule or the record's data. Then watch the pattern. An agent that keeps hitting the same limit is misconfigured or being steered, and its owner should hear about it. Make holds expire, so a forgotten request can't be approved weeks later.

Rate limits, money limits and LLM token budgets are different controls

Three different controls all get called "budgets." They count different things and stop different failures. Only the third concerns the large language model (LLM) itself.

HTTP 429 Too Many Requests comes from RFC 6585, which deliberately doesn't define how a server counts requests. The model-cost side is covered by OWASP's LLM10:2025 Unbounded Consumption. The OWASP AI Agent Security Cheat Sheet tells teams to "enforce token, cost, retry, and tool-chain limits." Those limits govern what the agent consumes, not what it gives away. You need all three. A token budget won't stop one cheap call that refunds $4,500, and a refund cap won't stop a loop that burns model spend.

Worked example: limiting AI agent refunds at Northwind

Northwind is a simulated company used in AgentFort's recorded lab demos. Its billing owner wrote four rules in plain English:

1. Support agents may issue refunds up to $100 without approval.
2. Larger refunds need approval from Finance, and the person the agent acts for can't approve.
3. No more than $2,000 may be refunded per invoice per week.
4. A refund must be for an invoice that belongs to the customer on the case.

Here is what happened to four requests from a support agent working for Priya, a support lead:

The per-call threshold sent the $450 request to a person. It didn't block it. The weekly cap on the invoice did the blocking. Splitting doesn't get around it, because rule 3 counts every refund on the invoice. The last request shows that a limit alone isn't enough: the amount was fine, but the record was wrong. The full story is in How to stop an AI agent issuing a $4,500 refund.

Checklist for AI agent payment controls

Run through this list for every agent that can move value.

• List every operation that moves value: refunds, credits, discounts, gift cards, payouts and payments.
• Normalize each amount to currency plus integer minor units, using the API's own exponent table.
• Treat a missing amount as the largest value the call could move.
• Set per-call, per-record and per-period limits, plus per-agent and per-person totals.
• Keep counters outside the agent, shared across services, and reserve amounts atomically.
• Decide which limits an approval can lift and which are hard stops.
• Evaluate limits when the action executes, not when the agent plans it.
• Count retries that reuse an idempotency key once.
• Return a reason code to the agent, not the rule or the remaining budget.
• Alert the agent's owner when it hits a limit repeatedly.
• Track LLM token spend separately from business budgets.

How AgentFort handles this

AgentFort Access checks every call an agent makes to a service, including its arguments and the record it touches, so limits can be written on amounts and on records. Budgets and limits are set per argument and per period, such as $2,000 per invoice per week. Refunds under a threshold run. Larger ones are held for a Finance approver, who sees the exact call and approves it; it runs once, and asking again needs approval again. The person the agent acts for can't approve. AgentFort reads the invoice itself before deciding. Every decision, including denials, leaves a receipt, chained so a missing or edited entry shows. Owners write these rules in plain English and replay them against past requests before publishing. See AgentFort Access, watch a demo or become a design partner.