5 ways to limit AI agents that move money, ranked

AI agents now issue refunds, agree payment plans and settle claims, far faster than any team can check. Regulators have not written separate rules for them, and for most actions they do not need to. The limits already exist in law, and they apply to the company whoever does the work: a person, an automated workflow or an AI agent.

So every risk team will face two questions this year. Which limits apply to our agents? And how do we make them stick? Below is what the rules already require, then 5 ways to enforce them, ranked, with what each one gets right and where it fails.

This matters for more than the audit. Risk teams only approve automation whose limits they can prove, so where your limits sit decides whether the agent goes live at all.

What the rules already demand

TL;DR: across finance, the rules already require caps on single actions and on running totals (card payments, large exposures), a person who can step in (GDPR, CCD2, AI Act), records that cannot be altered (DORA, ISO 27002, AI Act) and controls on what an automated system may change in a customer's contract (CCD2, GDPR, AI Act). Where a rule sets no number, it says who must: the board sets the limit, and a risk team independent of the business checks it (EBA governance, DORA, SR 26-2). None of these rules makes an exception because software took the action.

What each rule means for an AI agent

• GDPR: an automated decision that affects someone's rights needs a way to reach a person and a way for the customer to challenge it.
• Card payments: above the caps the customer has to confirm again. An automated fraud check may skip that step only up to €100, €250 or €500, and only while the payment provider's fraud rate stays low.
• Bank exposure to one client: whatever an agent lends or guarantees to a client counts toward the same limit as every other part of the bank, and a breach goes to the regulator at once.
• EBA governance: the people who check an agent's limits must be separate from the team that runs the agent.
• DORA: a separate team controls the risk of the systems the agents run on, and their records must survive tampering and deletion.
• CCD2: a borrower can ask a person to review any automated credit decision, and the lender must consider easier repayment terms before enforcing the debt.
• AI Act: the more the system acts on its own, the stronger the oversight must be. A person can overrule, reverse or stop it, and since 2 August 2026 customers must be told when they are dealing with an AI.
• ISO 27002: refused attempts are recorded too, and neither the agent nor the people who run it can delete their own records.
• SR 26-2: AI agents fall outside the US model rules, so the bank's own controls must cover them.
• CRI framework: senior leadership or a board committee approves the limits, the points where a person steps in are built into the AI system where possible, and the same limits apply to vendors' AI.
• MAS guidelines: people must be able to step in, higher-stakes AI needs a stop switch, and the combined risk of all AI use is reviewed.
• MAS SAFR: every action an agent proposes is carried out, sent to a person or refused before it runs, and recorded.

The 6 demands across the rules

Together, the rules ask for these 6 things, whether a person, a workflow or an AI agent acts:

1. A cap on each action.
2. A cap on the running total, across everyone who acts.
3. A person who can step in before the outcome is final.
4. A way to stop the system which the system cannot switch off.
5. A record nobody involved can change, including what was refused.
6. Limits set and changed by someone other than the team they apply to.

Why this matters now

(open full screen)

Every control in that list was built for people working at human speed: a supervisor samples a few calls, an approver signs above a set amount and an auditor tests a quarter after it ends. An agent works at a different speed. A check that looks at one action at a time misses the total, a sample sees almost none of what happened and an approver facing a full queue approves everything.

Getting it wrong costs money in both directions. Set the limits too loose and a run of small refunds adds up to a loss nobody chose. Set them too tight and every action waits in a queue, so you pay for the automation and still pay the checking department.

The second change is who acts. The agent issuing refunds may belong to a vendor, and its log is the vendor's account of what it did. The rules do not move with it. If the vendor's agent breaks your limit, you broke it.

It is already happening. In a Cloud Security Alliance survey of 418 respondents, 65% said their organisation had an AI agent incident in the past 12 months, and 35% reported financial losses as a result (Cloud Security Alliance, April 2026).

The 5 ways to enforce limits on AI agents, ranked

5. Write the limits into the prompt

The agent's instructions say "never refund more than 500 euros without approval". This is where almost every pilot starts.

Pros

• Free, and it takes one line.
• It works in the demo.

Cons

• A prompt is a request, not a control.
• The model can misread it, and a determined customer can talk around it.
• Nothing counts the total.
• The only record is the agent's own.
• It would not count as a control under any of the rules above.

4. Set limits inside each system

The payment system, the ERP and the vendor's agent platform each get their own limit. Engineering teams often put a rules checker in front of each system, either a tool like OPA or Cedar or their own code, with a running count in a database and records sent to the security team.

Pros

• Predictable: the same input always gets the same answer.
• Already paid for, or cheap to build.
• Your engineers own it.

Cons

• Each limit counts only what passes through its own system.
• The refund from the helpdesk and the refund from the vendor's agent never meet, so nobody holds the total.
• A rules checker judges one action and forgets it, so the running count has to be built separately.
• The team that runs each system can raise its own limit, and nothing records who approved the change.

3. Put a person on every action

The agent prepares the refund and a person approves each one, through an approval step in the workflow tool or a queue in the ERP.

Pros

• Meets "a person can step in" to the letter.
• Every auditor recognises it.

Cons

• At agent volume the approver approves everything.
• You pay for automation and keep the queue.
• Nobody sees the total across the queue.
• One click is the only evidence the person looked.

2. Rely on the agent platform or a guardrail

The software the agent is built on sets the limits: the agent builders inside the big business software suites, and security products made for AI agents. They give every agent an identity, decide which tools it may use and, in newer products, check each action before it runs.

Pros

• Real checks before each action.
• Good at controlling who the agent is and what it can reach.
• Some send hard cases to a person and keep a record that shows tampering.

Cons

• They govern the agent, not the refund.
• A person issuing the same refund from the back office is outside them.
• Limits are checked one action at a time, so 10 refunds under the limit all pass. Totals, where they exist, are kept per agent.
• Many still rely on prompts and tool permissions rather than a separate rule on the money.
• The rules sit in the vendor's settings, and the record is kept by whoever runs the platform.

1. Use dedicated internal controls for AI

A separate control system, like Stategram, holds the limits for the thing being changed (the refund, the settlement, the claim) rather than for any one agent or system. The risk owner signs off the rules, and the system turns them into a check that everyone must pass before acting: the support agent, a collections agent from another vendor and the person in the back office. Inside the limits the action goes through on its own. Above them a named person decides, and every decision leaves a signed record, including the refusals.

Each line of the rules answers one row of the table above. A simplified example:

Pros

• All 6 demands sit in one place.
• AI governance tools limit each agent separately. This keeps one limit and one running total for every agent and every person acting on the same money, whatever system they use.
• Inside the rules the agent works without a review queue, so people see only the exceptions.
• Your worst day becomes a number you chose: the daily total cannot be crossed, whoever acts.
• Risk can sign off the automation because the limits are enforced rather than described, so it goes live instead of staying a pilot.
• A new agent or a new vendor points at the same rules, so nothing is rebuilt when you switch.
• Changing any number creates a new signed version, so the team the limit applies to cannot change it quietly.
• An auditor can check any record without having to trust the vendor or you.

Cons

• Every action makes one more call before it runs.
• If the control system cannot be reached, the action waits rather than going ahead.
• Each system that acts has to ask for permission first, which takes some integration work.
• It is a new category: few vendors, little track record and one more supplier for procurement to approve.

What about agent wallets and agent banks?

Agent wallets, the card networks' agent tokens and the new banks built for agents put hard caps on what an agent spends from an account they hold. That solves agent purchases. It does nothing inside your own books: a refund, a settlement discount, a claim payout or a change to a loan's terms never passes through their account.

The scorecard

The rules are already written. The question left is where your agents' limits live: inside the systems they limit, or in a separate layer that none of them controls. Stategram is that layer: stategram.io.