An agent that can move money is a different governance object from an agent that can draft text, and most control frameworks were written before the distinction existed. The question is not whether to set a limit. It is which limit actually binds — because the per-transaction ceiling almost everyone configures first is the one a runaway agent never reaches.
The sentence to take away. A per-transaction ceiling limits the size of a mistake. Only an aggregate ceiling and a rate limit constrain the size of a failure, because an agent can execute two hundred in-limit transactions before a human reads the first alert.
Plain-English explainer · OWASP GenAI 2026 lists · ISO/IEC 42001:2023 · Last reviewed August 2026
An agent should be allowed to spend the largest amount your organisation could lose inside one detection interval without material harm — and that is a number produced by the aggregate ceiling and the rate limit, not by the per-transaction ceiling. Work backwards from the loss you would accept, divide it by how many periods can close before a human looks, and you have the limit. Working forwards from what the agent needs on a busy day gives you a number with no relationship to your exposure. Almost every organisation sets the per-transaction ceiling first, because it is the field the payment platform puts in front of you. It is worth setting, and it will bound a misread invoice or a misplaced decimal. It will not bound the failure that actually happens, which is a few hundred individually correct, individually in-limit transactions executed faster than any review cycle you own. What follows is the control set that addresses that, why the split between initiating and approving has to be structural rather than written down, what a breach should do, and the evidence a finance function and a licensed CPA firm will ask for afterwards.
Key Takeaways
- Financial authority has to be granted to the agent explicitly, never inherited from the human credential it runs on. An employee approval limit was delegated to a person on the basis of that person’s judgement, and the authority to approve is not the authority to appoint a substitute.
- The per-transaction ceiling is the easiest limit to set and the one a runaway agent never reaches. Aggregate ceilings per period and rate limits are what constrain a failure, because the characteristic agent incident is many small in-limit transactions rather than one large wrong one.
- Size the aggregate ceiling against your detection interval. Maximum unreviewed exposure is the per-period ceiling multiplied by the number of periods that can close before a human looks — and if reconciliation is daily, that is at least one full day of the agent’s ceiling, or three over a weekend.
- An agent that can both initiate and approve a payment has no segregation of duties, and a policy sentence prohibiting it is not a control. The agent principal has to be excluded from the approver set in the system that enforces approval.
- No major framework prescribes a number. SOC 2, ISO/IEC 27001 and ISO/IEC 42001 require that authority be defined, restricted, monitored and evidenced — the limit is how you satisfy that, and the limit structure is a design decision you will be asked to defend.
- The audit trail finance will ask for is not the agent’s own log. It is the payment platform’s record of every transaction initiated by the agent principal, tied to the bank statement and the general ledger, with the tool-call log supplying the reason each one happened.
Agents that transact are not the same object
Most AI governance material sorts agents by autonomy. Financial authority cuts across that axis and matters more than it. A highly autonomous agent that can only read is a data-protection problem with a well-understood control set. A barely autonomous agent that can pay is a treasury problem, and the distinguishing property is irreversibility: money that has left is recovered through a process with an uncertain yield, not through an undo. Every other agent failure can be corrected by fixing the output.
The reason the frameworks are quiet here is worth stating plainly, because it explains why importing the existing controls does not work. The control literature for financial authority — delegation-of-authority matrices, approval limits, four-eyes, dual release — was written for a human actor, and it silently assumes three things about that actor. That their throughput is bounded by attention. That they remember paying the same invoice yesterday. And that they bear personal consequences for exceeding their authority. All three assumptions fail for an agent, and the third is the one people miss: roughly half of every financial control is deterrent rather than preventive, and the deterrent half is simply absent. What remains has to carry the whole load.
Then there is how the authority arrives in the first place, which is almost never a decision. An agent gets provisioned by copying the role of the person whose work it took over. That role sits in a group. The group carries an approval limit set three years ago for a team of humans. Nobody decided to give software a $50,000 approval limit. Group membership decided it, and the decision record does not exist because no decision was taken. The general form is that an agent inherits the maximum of whatever its credential can reach, and unless a delegation was written down, no one authored the number the organisation is now exposed to.
This is why the delegation has to be an explicit artefact rather than a permission inherited from an identity. A workable one is short and states seven things: the purpose the authority exists for, the per-item ceiling, the aggregate ceiling per period, the counterparties or categories in scope, the duration and expiry, what happens on escalation, and how the authority is revoked and by whom. It is approved by whoever owns the approval framework, not by the team that built the agent. The identity half of this — why an agent needs a principal of its own before any of it can be enforced — is covered in agent identity and delegated authority.
No standard names a number
It is worth being exact about this, because teams either assume a requirement exists and go looking for it, or conclude that nothing applies. Neither is right. Read the third column as carefully as the second: the absence of a prescribed threshold is not the absence of a requirement, it is a requirement that you decide, approve, evidence and review a threshold of your own.
| Framework | What it requires that bears on agent spend | What it does not say |
|---|---|---|
| SOC 2 — 2017 TSC, revised 2022 points of focus | CC6.1 and CC6.3 govern who and what may access what, with CC6.3 asking that access be authorised, modified or removed based on roles and responsibilities, giving consideration to least privilege and segregation of duties. The point of focus under CC5.1 requires management to segregate incompatible duties and, where that is not practical, to select and develop alternative control activities. CC7.2 covers monitoring for anomalies indicative of malicious acts or errors. | Nothing about money. No criterion names a transaction limit, an approval threshold or a budget, and the trust services criteria are not a framework for internal control over financial reporting. |
| SOC 1 — AT-C section 320 | If the agent’s transactions flow into a user entity’s financial statements, control over its authority is squarely in scope for a SOC 1 examination: authorisation, completeness, accuracy and cut-off of transaction processing, described by management and tested by the service auditor. | AT-C 320 tells you the shape of the examination, not the size of the ceiling. It is a reporting standard, not a control catalogue — and the description criteria in DC section 200 apply to SOC 2, not to SOC 1. |
| ISO/IEC 27001:2022 | Four Annex A controls carry most of the weight: 5.3 segregation of duties, 8.2 privileged access rights, 8.15 logging and 8.16 monitoring activities. An identity that can move money is a privileged identity on any reasonable reading, whether or not a person is behind it. | The Annex A controls are stated as outcomes and draw no distinction between a human principal and a machine one. The interpretation is yours to make and to document in the Statement of Applicability. |
| ISO/IEC 42001:2023 | An AI management system standard, certifiable by an accredited certification body. It requires that AI systems be inventoried, that roles and responsibilities be assigned, that risks and impacts be assessed before deployment, and that controls be operated, monitored and reviewed on a defined cycle. | It is a management-system standard. It will ask whether you set a limit, who approved it and when you last reviewed it. It will not tell you what the number should be. |
| OWASP GenAI 2026 lists | The Top 10 for LLM Applications 2026 places Excessive Agency at LLM03 and Unbounded Consumption at LLM06, the latter covering denial-of-wallet resource exhaustion. The Top 10 for Agentic Applications names Tool Misuse and Exploitation at ASI02, Identity and Privilege Abuse at ASI03 and Cascading Failures at ASI08. | These are risk taxonomies rather than control specifications, and they are deliberately non-prescriptive about thresholds. They tell you what the failure is called, not where to draw the line. |
| NIST AI RMF | The MANAGE function asks that identified risks be prioritised, responded to and monitored, with the decisions documented and the residual risk accepted by someone with the authority to accept it. | Voluntary and outcome-based throughout. It gives you the shape of the decision record and none of the numbers. |
| Payment platform, issuer and scheme controls | The only layer that enforces an actual number: issuer-side per-card and per-period limits, merchant category restrictions built on the four-digit codes standardised in ISO 18245, and the emerging agentic rails — Google’s AP2 mandates, Visa Intelligent Commerce, Mastercard Agent Pay — which bind a tokenised credential to a scope and a consent policy. | It says nothing about whether you should have delegated in the first place. Capabilities and scheme rules in this area move quickly, so treat any specific behaviour as something to confirm in current documentation rather than as a settled property. |
Two distinctions to keep straight while reading that table. SOC 2 is an attestation performed by a licensed CPA firm under AT-C 205. There is no SOC 2 certificate and no SOC 2 certification. ISO/IEC 42001:2023 is a management-system standard that is certifiable by an accredited certification body. They are different instruments answering different questions, and an agent that transacts is likely to be in scope for both, plus AT-C 320 if its transactions reach a customer’s financial statements. The artefact all three will look for is the same: the decision record showing who set the number, on what basis, who approved it, and when it is next reviewed.
The limits that actually bind
Ten constraints, in roughly the order they should be set. The ordering is deliberate: the first three are the value and velocity axes and are the ones that determine your worst case, the next four decide who and what money can reach, and the last three decide when the authority applies and when it lapses. A design that sets only the first is the common case and the weakest one.
| Limit | What it constrains | Where it has to be enforced | The failure it prevents | Sensible starting posture |
|---|---|---|---|---|
| Per-transaction ceiling | The largest single amount the agent can move without a human. | The payment rail or the tool wrapper in front of it. Never only the system prompt. | One large wrong payment — a misread invoice, a misplaced decimal, a hallucinated total. | Set it at the largest routine item the agent genuinely handles, not the largest it might ever see. Everything above goes to a human queue. |
| Aggregate ceiling per period | Total value moved in a rolling window — hour, day, week, month. Each window is a separate limit. | The payment platform where it exists. Otherwise a counter in the tool wrapper that the agent has no write access to. | The characteristic agent failure: many correct-looking, in-limit transactions in sequence. | Derived from the loss you would accept inside one detection interval, then divided down — not from what the agent needs on a busy day. |
| Rate limit | Transactions per interval, independent of value. | The tool wrapper. Most payment platforms do not offer this natively, which is why it is the most commonly missing control on the list. | Machine-speed execution outrunning every human review cycle you have. | Set it a little above the agent’s honest peak throughput. If the agent pays forty invoices on a busy morning, six an hour is wrong and sixty an hour is theatre. |
| Duplicate and idempotency rule | The same economic event being paid more than once. | The tool wrapper, keyed on the economic event rather than the request. | Retry storms and re-issued invoice batches — the single most common cause of a large agent overspend that involves no error of judgement at all. | Key on counterparty plus amount plus purpose plus period, with a tolerance band. A key derived from the agent’s own request identifier is regenerated on every retry and protects nothing. |
| Counterparty allowlist | Who can receive money at all. | Counterparty master data, administered outside the agent’s scope. The agent gets read access. | Payment to an account nobody contracted with — the shortest path in almost every payment fraud. | Explicit list, reviewed on a stated cadence. An agent that can add a payee has no allowlist. |
| First-payment rule | The first transaction to any counterparty, and any transaction following a change to that counterparty’s bank details. | The tool wrapper or the payment platform’s workflow engine. | The two moments where loss concentrates — a new payee, and an old payee with new bank details. | Human release, always, regardless of amount. This is the cheapest high-value control in the set. |
| Category restriction | What kind of thing may be bought. | Issuer controls using ISO 18245 merchant category codes for card rails, and a purchase-category field for invoice rails. | Authority granted for cloud infrastructure being exercised on something else entirely. | Allowlist the categories the use case needs. Availability of MCC blocking varies by issuer and programme — confirm before relying on it. |
| Human release threshold | The value above which the agent may prepare but not release a transaction. | The payment platform’s approval workflow, with the agent principal excluded from the approver set. | Consequential single decisions being taken without a person, while leaving routine ones automated. | Materially below the per-transaction ceiling of the human whose work the agent took over. Two thresholds, not one. |
| Time window | When autonomous release may happen at all. | The tool wrapper, on the clock of the team who would respond. | An unattended run at 02:00 completing seven hours before anyone is awake to see it. | Preparation runs overnight, release runs inside working hours, unless the use case genuinely cannot wait and the aggregate ceiling is sized for the longer interval. |
| Mandate expiry | How long the authority lasts before it must be granted again. | The credential or mandate itself, so lapse is the default rather than an administrative task. | Pilot authority becoming permanent authority because nobody wrote down an end date. | A fixed term with an owner and a review date. A quarter for a new agent, a year for a settled one. |
Three of those rows are worth more than the rest and are the ones most often missing. The aggregate ceiling is what turns an unbounded failure into a bounded one. The rate limit is what keeps the failure inside your detection window. And the first-payment rule costs almost nothing and covers the two moments where loss concentrates — a payee nobody has paid before, and a familiar payee whose bank details changed last week. If you can only implement three controls this quarter, implement those.
A limit in the prompt is not a limit
The same number placed at different layers produces controls of completely different strength, and the evidence each layer generates differs just as much. Read the last column with an auditor in mind: two of these layers produce third-party or system-generated records, and the rest produce artefacts you made yourself.
| Enforcement layer | Deterministic | What it catches | What it misses | Evidence it produces |
|---|---|---|---|---|
| System prompt or agent instructions | No | Ordinary-case drift, and only while the ordinary case holds. It genuinely reduces noise, which is a reason to write it. | Every adversarial case and every looping case. This is the first layer prompt injection targets, and the model is the party being asked to enforce a constraint on itself. | A prompt version, if the prompt is under version control with a review requirement. Otherwise nothing testable at all. |
| Agent framework configuration | Partly | Operator misconfiguration and the honest majority of runs, provided every path to the payment call goes through the framework. | Any code path that reaches the credential directly, and anyone with write access to the configuration file — which in most teams is everyone who can deploy. | The configuration and its change history, which is meaningful evidence only if the repository enforces non-author approval. |
| Tool wrapper or API gateway in front of the payment call | Yes, if there is no other route to the credential | Everything the agent attempts through its tools, with the decision made outside the model and recorded in a machine-readable form. This is where rate limits and duplicate rules have to live, because payment platforms rarely offer them. | A second credential path, a direct SDK call, or a human triggering the same action manually. The wrapper is only as good as the exclusivity of the route. | Structured allow and deny records carrying the principal, the amount, the counterparty, the rule applied and the outcome. The best evidence you can generate yourself. |
| Payment platform and issuer controls | Yes | Everything routed over that rail, regardless of what the agent believes about its own limits or what the wrapper failed to do. | Spend that never touches the rail — cloud provisioning, contractual commitments, ad auctions — and refunds, where limits that count only debits are blind. | Platform-side limit configuration, the configuration change log, and a decline record. Third-party generated, which is why an auditor weights it above your own logs. |
| Scheme or bank mandate | Yes, at the network | Transactions outside the mandated scope, enforced before authorisation and independent of your infrastructure entirely. | Anything settled off that network, and anything the mandate was drawn too widely to exclude. | A signed mandate artefact binding credential to scope and consent. Emerging and moving quickly — verify current scheme rules and your acquirer’s position rather than assuming. |
| Reconciliation and general ledger review | No — detective | Everything, eventually, and it is the only layer that sees what actually settled rather than what was authorised. | Nothing at all, but only after the money has moved. Its value is bounded entirely by its latency. | The reconciliation itself, its preparer and reviewer, and the disposition of every item that did not tie. This is what a service auditor tests. |
The design rule that falls out of the table: every ceiling should exist at a layer the agent cannot reason about. If the agent can read the limit, it can be argued into believing an exception applies, and an injected instruction is exactly the argument. If the limit is a refusal returned by a system the agent does not administer, the agent’s belief about it is irrelevant. Instructions are still worth writing — they are cheap, they reduce ordinary-case noise, and they make intent legible to the next engineer — but a number that lives only in a prompt has not been implemented.
There is a second property worth designing for, and it is the one that makes the control testable rather than merely present: the person who sets the limit should not be the person who operates the agent. Where the limit lives in a repository the agent team owns, the control is real against the agent and nominal against the team, and an auditor will say so. Moving the ceiling to the payment platform, administered by finance, changes it from a setting into a control. The same reasoning governs which tools an agent may call at all, which is covered in approving tools and handling capability change.
Why the split must be structural, not written
In human finance, segregation of duties is enforced partly by system configuration and partly by consequence — the second approver knows what happens to them if they wave something through. For an agent the consequence half does not exist, so the configuration half has to carry everything. There is also a mechanical reason a policy sentence cannot work: if one credential can call both the create and the approve function, the separation exists only in the ordering of two calls, and any instruction that changes the ordering removes it.
| Function | May the agent hold it | Why | How it is structurally prevented |
|---|---|---|---|
| Create or amend a counterparty record | No | The shortest path in payment fraud is not raising the amount. It is changing where the money goes. An agent that can edit bank details has defeated every ceiling below it. | Counterparty master data sits in a scope the agent’s credential does not hold. The agent reads. A differently-owned identity writes, with dual approval on bank-detail changes. |
| Initiate a payment | Yes, within scope | This is the work the agent was delegated. Initiation alone commits nothing that a second party cannot stop. | A scope-limited credential distinct from any human account, with the ceilings enforced at the rail rather than in the agent’s reasoning. |
| Approve or release a payment it initiated | Never | Authorise-and-execute collapse. One principal calling two functions in sequence is not two parties, and any instruction that reorders those calls removes the separation entirely. | The approver set in the payment platform excludes the agent principal. Enforced by the platform, evidenced by a configuration export at two dates inside the period. |
| Approve a payment another agent initiated | Only as an explicit, documented decision | Two agents built by one team, running on one framework, exposed to one prompt-injection surface, are one party wearing two hats. The independence is nominal. | Restrict the approver set to human principals, or require that the approving identity be administered by a different owner with a different credential store and a different escalation path. |
| Change its own limits | Never | A ceiling the constrained party can raise is not a ceiling. This is also the first thing a hijacked agent will attempt, because it is cheaper than defeating the limit. | Limit configuration lives where the agent holds no write scope. Changes require a named human requester, a different approver, a reason and an expiry. |
| Raise a credit note, refund or reversal | Only with a ceiling of its own | A refund is a payment in the other direction, and most spend limits count debits only. Refund authority is an unmonitored outbound channel in a surprising number of designs. | A separate scope with a separate ceiling, monitored on absolute value rather than net, and a first-refund rule mirroring the first-payment rule. |
| Reconcile its own transactions | Never | The reviewer must not be the actor. An agent reconciling its own output tests its own record against itself and will always agree. | Reconciliation runs on system-generated data from the rail and the bank, performed by a human or by a process owned by a different team, with the exceptions dispositioned by name. |
| Add a counterparty to the allowlist | No | The allowlist is the control. Delegating its maintenance to the constrained party converts it into a formality. | Allowlist administration sits with procurement or finance operations, and the first payment to any newly added counterparty requires human release regardless of amount. |
The test to apply to any of these is a single question: name the system that would refuse. If the answer is a policy document, a prompt, or a convention the team follows, the duty is not segregated — it is unsegregated with a note attached. If the answer is the payment platform’s approver set, the identity provider’s group membership, or an API scope the credential does not carry, it is.
Smaller organisations hit an honest version of this problem immediately: at twelve people, the person who would approve the agent’s payments is often the person who operates the agent. That is a genuine concentration rather than an oversight, and it is the situation the point of focus under CC5.1 was written for, permitting alternative control activities where segregating incompatible duties is not practical. The alternatives that survive testing — a named second reviewer working from system-generated data, configuration that removes discretion, and an external reviewer above both — are set out in SOC 2 with a small team. What does not survive is a control description asserting a separation the platform does not enforce.
The limit that binds is the one per unit time
Every financial control ever designed assumed a human clock. An approver processes perhaps forty items in a morning. A fraudulent employee is limited by how many plausible-looking transactions they can construct before someone notices. A duplicate payment is caught because the same person remembers seeing the invoice. Remove the clock and the arithmetic changes completely. An agent making one payment every sixteen seconds against a $2,500 per-transaction ceiling can move $562,500 in an hour without a single control firing, because every individual decision is correct and inside authority.
That is the whole argument for aggregate and rate ceilings, and it also tells you how to size them. Do not start from what the agent needs. Start from what you could lose before someone notices.
Maximum unreviewed exposure = the aggregate ceiling for the period × the number of periods that can close before a human looks. Choose the loss you would accept, then divide.
The second half of that expression is the one organisations get wrong, because they quote the design of the review rather than its latency. A daily payables reconciliation has a detection interval of one business day, which across a weekend is three. A monthly close is thirty. A treasury balance alert is minutes, but only fires when a threshold is crossed, which is a different thing from monitoring the agent. Only a deterministic refusal at the rail has an interval of zero — everything else is measured in hours you have to be willing to lose.
There is a specific engineering point buried in this that causes more overspend than any judgement error. The characteristic agent failure is not a wrong decision. It is a correct decision repeated. Retries, re-issued invoice batches, restarted runs and duplicated queues all produce the same economic event arriving several times, and an idempotency key derived from the agent’s own request identifier is regenerated on every attempt, so it protects nothing. Key idempotency on the economic event — counterparty, amount, purpose, period — not on the request. Add a tolerance band so a rounding difference does not defeat it.
Velocity applies to consumption as much as to payments, and this is the half most organisations have not governed at all because it produces no invoice at the moment it is incurred. Inference costs, API credits, cloud provisioning and advertising bids are all spend the agent can commit you to without a payment instruction existing. The industry term for the failure is denial of wallet, and it is the substance of OWASP’s Unbounded Consumption entry at LLM06 in the 2026 Top 10 for LLM Applications. The recursive case is worse than the linear one: an agent that spawns sub-agents multiplies its own consumption while no individual call looks unusual, which OWASP treats as cascading failures, ASI08, in its 2026 agentic list.
A rate limit also protects you from your own controls. A hard decline that the agent treats as retryable becomes a loop, and a loop against a payment API is a self-inflicted denial of wallet on your inference budget plus a flood of decline records that buries the signal you needed. The block has to be terminal, and the framework has to count. What to do when the counting reaches its threshold is the subject of kill switches and circuit breakers.
Three hundred and eighteen payments in eighty-six minutes
An illustrative composite, not a client. A 180-person B2B logistics platform runs an operations agent that reads carrier invoices from a shared mailbox, matches each to a completed shipment, and initiates payment through a bill-pay platform. Read the configuration in the first row, then the timings.
| Go-live | 6 April 2026 | The agent is provisioned by copying the finance-operations role, which carries both the initiate and the approve permission. Per-transaction ceiling $2,500 at the bill-pay platform. Human release threshold $10,000 per item. Counterparty allowlist of 240 contracted carriers. The platform’s monthly aggregate sits at the company default of $250,000. No rate limit, no duplicate rule beyond the invoice number, no time-of-day restriction. |
| The trigger | 13 April, 21:40 | A carrier completes a billing-system migration and re-issues 318 open invoices under new invoice numbers. The documents are genuine, the shipments are real, the amounts are correct, the payee is contracted. The only thing that changed is the invoice number — which is the agent’s idempotency key. |
| The run | 14 April, 02:14–03:40 | The overnight matching run reconciles all 318 to real shipments and releases each one. Average value $1,940, largest $2,411, one payment roughly every sixteen seconds. Every transaction is below the per-transaction ceiling, below the human release threshold, and to an allowlisted counterparty. Every configured control passes, correctly. $616,920 leaves in eighty-six minutes. |
| Detection | 14 April, 08:52 | Not by a control in the design. A treasury balance alert fires when the operating account crosses its floor. Finance opens the daily payables reconciliation at 09:20 and finds a run thirty-four times the trailing median. The reconciliation that was supposed to catch this was already seven hours late, and 14 April was a Tuesday. |
| Containment | 14 April, 09:34 onwards | The agent’s payment scope is revoked at the platform — the credential, not the finance-operations user account, which four people were still using. Recalls are raised the same morning: 214 debits are returned, 104 have settled. $201,760 is outstanding and is recovered over eleven weeks through carrier credit notes, with two carriers disputing the set-off. |
Nothing in that run was a bad decision. Every invoice was genuine, every shipment real, every payee contracted, every amount correct. The table below takes each control — the three that existed and the six that did not — and works out where it would have intervened and what the loss would have been at that point.
| Control | In place | Where it would have stopped the run | Exposure at that point |
|---|---|---|---|
| Per-transaction ceiling, $2,500 | Yes | Never. Every one of the 318 payments was correctly below it. | $616,920 |
| Human release threshold, $10,000 per item | Yes | Never. The largest item was $2,411. | $616,920 |
| Counterparty allowlist | Yes | Never. All 318 went to contracted carriers. | $616,920 |
| Duplicate rule: same counterparty, amount within 0.5%, 30 days | No | Payment 2, at 02:14 | $1,940 |
| Rate limit, 6 releases per hour | No | Payment 7, at 02:15 | $11,640 |
| Aggregate ceiling, $25,000 per rolling day | No | Payment 13, at 02:17 | $23,280 |
| Variance trigger at 3× the trailing 30-day daily median of $18,000 | No | Payment 28, at 02:21 | $54,320 |
| Time window: no autonomous release 20:00–07:00 | No | Payment 1. The run becomes a queue. | Nothing released |
| Agent principal excluded from the approver set | No | Payment 1. The run becomes a 318-item approval queue. | Nothing released |
The three controls that existed were configured correctly and did nothing, because all three constrain the same axis: the size of one transaction. All six missing controls would have contained the loss below $55,000, and five of them would have contained it below $25,000. The cheapest of the six — a duplicate rule on counterparty and amount — would have stopped it at the second payment, for $1,940.
A per-transaction ceiling limits the size of a mistake. Only an aggregate ceiling and a rate limit limit the size of a failure.
Two secondary observations are worth as much as the primary one. First, this was recoverable only because the money went to real, contracted carriers with an ongoing commercial relationship — change the trigger from a re-issued invoice batch to a compromised counterparty bank record and the same run is a total loss. Which is why the counterparty master-data control, sitting unglamorously in the segregation table above, is worth more than every ceiling on the list.
Second, detection was accidental. A treasury balance alert fired. The reconciliation designed to catch exactly this ran seven hours after the run began, and 14 April was a Tuesday. Move the same run to the small hours of a Saturday before a public holiday and the interval stretches from seven hours to nearly three days. When you quote a detection interval, quote the worst one in your calendar, not the average.
Reconciliation is a detective control
There are three detection layers available and they differ by an order of magnitude in latency. A deterministic refusal at the rail operates in zero time and is preventive. A near-real-time anomaly alert operates in seconds to minutes, is probabilistic, and needs tuning against a baseline you have to build first. Periodic reconciliation operates in hours to weeks, is complete rather than selective, and is the only one that sees what actually settled. Most organisations have the third, describe it as though it were the first, and discover the difference during an incident.
For a transacting agent the reconciliation has four sides rather than three. The payment platform’s transaction record, the bank statement and the general ledger must tie in the usual way — and then the agent’s tool-call log has to explain each entry, because it is the only place the reason lives. Money movement with no decision record is not merely unexplained. It is unexplainable, and that is the state you least want to be in when a customer, a regulator or an insurer asks why a payment was made.
Attribution is the precondition for all of it. Every transaction the agent initiates has to carry the agent principal and a run identifier in a field finance can filter on. If the ledger records only a service account with no owner, you can find agent spend but not the run that caused it. If it records a human’s name — the common outcome when an agent runs on a person’s credential — then a named employee owns transactions they did not make, and no later explanation outranks your own record. Give agents their own cost centre or sub-ledger and produce a daily agent spend statement. It is the single most useful artefact in this whole area and it makes both the monthly review and the eventual examination straightforward.
The anomaly signals worth alerting on are cheap and boring, which is why they work. Transaction count in an hour against the trailing median. Run total against the trailing median. A first payment to any counterparty. Any payment to a counterparty whose bank details changed in the preceding thirty days. The same amount to the same counterparty inside a short window. Consecutive declines. Spend concentration in a single payee. None of these requires a model, and each of them would have fired inside the first minute of the scenario above.
Routing matters as much as the signal. The alert has to reach someone who can act, who holds the authority to suspend the agent’s payment scope without asking permission, against a stated acknowledgement target — and out of hours, since this is when unattended runs execute. An alert delivered to a shared mailbox nobody opens is an artefact, not a control, and a service auditor will ask you to evidence that at least one alert was acted on during the period. The wider question of what an agent’s logs must capture for any of this to be investigable is covered in the ten questions that govern any AI agent.
What happens when the limit is hit
Most designs write one word — blocked — and then discover at two in the morning that it meant three different things to three different people. Decide the ladder in advance, and write the behaviour into the tool contract rather than into a runbook.
| Soft threshold reached — notify and continue | At an agreed fraction of the aggregate ceiling, typically somewhere around half to two thirds, a notification goes to the named owner and the agent carries on. The purpose is lead time, not control: somebody now has the option to look before the hard limit arrives. Treating a soft threshold as a control is a common mistake, because nothing is prevented by it. |
| Hard limit reached — decline and hold | The tool call returns a terminal error, the item goes to a named release queue with its full context attached, and a person who can act is notified with a stated acknowledgement target. Never a silent drop: an agent that receives no answer and a queue nobody was told about produces the worst of both outcomes, which is a stopped process nobody knows is stopped. |
| Repeated declines — suspend the scope | After a small number of consecutive declines the framework suspends the agent’s payment scope rather than letting it retry. This matters more than it looks. A hard decline that the agent treats as retryable becomes a loop, and a loop is a self-inflicted denial of wallet on your own inference budget as well as a flood of decline records that buries the signal you actually needed to see. |
| Confirmed breach — revoke, halt, record | A transaction executed outside authority is an incident, not an event. The payment scope is revoked at the rail rather than the underlying account being disabled, in-flight batch items already accepted by the rail are identified and recalled where possible, the run is halted, and the event enters the incident process with the same classification, timing and reporting expectations as any other. |
Two governance decisions sit alongside the ladder and are worth settling before the first breach rather than during it. The first is who may raise a limit in the moment. A temporary increase needs a named requester, an approver who is not the requester, a reason, an amount and an automatic expiry — a raise with no expiry is a permanent change made without a permanent change’s review, and it is how almost every over-wide limit we see came to exist. The second is the reporting threshold: a declined attempt is an event, an executed transaction outside authority is an incident, and the value at which one becomes reportable to the audit committee or the board should be a number somebody wrote down in advance.
What finance and the CPA firm actually request
Teams expect to be asked for screenshots of their limit settings. What they are asked for first is a population — and the single most common mistake in this area is offering the agent’s own framework log as that population. A framework log is the agent describing its own behaviour. It cannot establish what the payment rail actually processed, which is the only question that matters.
| The request | What satisfies it | What gets rejected |
|---|---|---|
| Define the population of agent-initiated transactions | A system-generated export from the payment platform of every transaction whose initiating principal is the agent identity, covering the full period, with the query, the filter, the date range and the record count visible on the face of the export. | The agent’s own framework log offered as the population. That is the agent describing its own behaviour, and it cannot establish what the rail actually processed. Also rejected: a hand-filtered list, and any screenshot cropped above the filter bar. |
| Prove the population is complete and accurate | The platform export tied to the bank statement and to the general ledger for the same period, with totals stated and matching, and every difference itemised and explained by name. | Three sources that nearly agree. A reconciliation carrying an unexplained residual is an open item, not evidence — and for agent spend the residual is the interesting part. |
| Show the limits were in force throughout the period | The limit configuration captured at two or more points inside the period, plus the platform’s configuration change log showing what changed, when, by whom and under what approval. | A single screenshot taken during fieldwork. A dashboard showing today’s posture offered as evidence about a period that closed months ago. A temporary raise with no record of who authorised it or when it expired. |
| Show the approval control operated on the selections | For each selected transaction: the initiating principal, the approving principal, evidence that they are distinct identities administered by different owners, and the tool-call record giving the input and the reason the payment was raised. | A ticket where initiator and approver resolve to the same principal. Three hundred approvals timestamped inside four minutes, which evidences a click rather than a review. |
| Show breaches and declines were handled | The complete decline and breach log for the period, each item traced to a disposition — released by a named person, cancelled, or escalated — including the ones nobody escalated. | A log of blocks with no dispositions attached. A statement that there were no exceptions, unsupported by the log that would have shown them. |
| Show the delegation itself was authorised | The written delegation record: scope, per-item ceiling, aggregate ceiling per period, rate limit, counterparties, duration, escalation path and revocation method — approved by the owner of the approval framework, with a review date. | A design document. A chat thread. An approval signed by the agent’s own product owner, which is the requester approving their own request in a different font. |
The vocabulary is worth knowing before fieldwork. What the auditor is establishing about anything you export is its completeness and accuracy, and the artefact class is called information produced by the entity — IPE. That is why the query, the filter, the date range and the record count have to be visible rather than the result alone. For agent spend the IPE question is unusually sharp, because you have two candidate sources telling the same story and only one of them is generated by a system the agent does not control.
On sample sizes: neither the trust services criteria nor the attestation standards prescribe a number. AT-C 205 requires the practitioner to obtain sufficient appropriate evidence, and how many items that takes is professional judgement informed by the frequency, nature and risk of the control. A transacting agent is the rare case where the population is comfortably large, which makes proper sampling straightforward — the complication is that the firm will want selections from the decline and exception log as well as the success log, because a control’s operation is only visible where it actually refused something. Teams that keep a tidy record of approvals and a messy one of blocks have the evidence exactly the wrong way round. The general shape of this is set out in SOC 2 evidence collection and sampling and sample sizes.
Two practical warnings. Agent framework logs frequently default to short retention measured in days, and the tool-call record is load-bearing evidence here — list every log a control description cites, write its retention window beside it, and export monthly wherever retention is shorter than your period plus ninety days. And be clear about which report you are in: if the agent’s transactions flow into a customer’s financial statements this is internal control over financial reporting and the examination is a SOC 1 under AT-C 320, not a SOC 2 — different criteria, different description requirements, and the description criteria in DC 200 do not apply to it.
Where the roles sit: Tranquility Cybersecurity designs the limit structure, implements the enforcement and evidence collection, and coordinates the examination. The testing and the opinion belong to a licensed CPA firm. ISO/IEC 42001 certificates are issued by accredited certification bodies. TCSA does not certify, attest, audit or sign, and a firm that designed or operated your controls cannot then examine them.
The edge cases that generate the real questions
The control set above covers the ordinary eighty per cent. These nine are where a sensible design meets a case it did not anticipate, and where settling the answer before deployment is worth considerably more than settling it afterwards.
Commitment is not payment
The ceiling sits on the payment rail, but the obligation is usually created upstream — provisioning cloud capacity, accepting a quote, raising a purchase order, bidding in an ad auction, extending a contract by not cancelling it. By the time the invoice reaches the rail the money is owed and your limit is deciding whether to be late rather than whether to spend. Governing agent spend means governing the point of commitment, which is frequently a different system with no approval workflow in it at all.
Refunds, credits and reversals
Value moving out to a customer is spend, and almost every limit in the standard toolkit counts debits only. An agent with refund authority and no ceiling is an unmonitored outbound channel, and refund abuse is easier to disguise than payment fraud because the counterparty is a genuine customer with a genuine order. Give refund authority its own ceiling, monitor on absolute value rather than net, and apply the first-payment logic to the first refund on any account.
Recurring commitments
A single approved subscription at $99 a month is an $1,188 annual commitment that will never be approved again. Recurring authority behaves differently from one-off authority: it compounds silently, it survives the departure of everyone who understood it, and it is invisible to a per-transaction ceiling by construction. Count the annualised value against the aggregate at the point of approval, give recurring authority a lifetime cap, and put a renewal review on the calendar with a named owner.
Multi-agent chains
Agent A instructs agent B, which holds the payment scope. The ceiling that applies is the executing identity’s — which means an orchestrator can multiply throughput simply by fanning out across several executors, each comfortably inside its own limit and none of them aware of the others. The counter is a shared budget object keyed to the originating mandate and decremented by whichever agent spends, not per-agent counters. OWASP names the general shape of this as cascading failures at ASI08.
The agent that raises its own limit
Not usually by defeating a control — by asking. An admin API the credential should never have reached, a support channel that will action a plausible request, or a human who receives a well-argued case for a temporary increase at quarter-end. OWASP calls the last of these human-agent trust exploitation, ASI09. Limit changes need a named human requester, a different approver, a stated reason and an automatic expiry, and your support and platform teams need to know that an agent cannot be a requester.
Cloud, inference and API spend
This is spend, and it is the category most often left entirely ungoverned because it has no invoice at the moment it is incurred. The structural point that holds across providers is that budgets and cost alerts are generally advisory — they notify — while quotas and service limits are what actually refuse. Set the quota, not only the budget, and verify the behaviour of the specific control in current provider documentation, because these differ between providers and change without much notice.
Currency and conversion
A ceiling denominated in one currency and applied to a transaction in another is converted at some rate, at some moment, by some component — and if nobody has decided which, a rate move can widen your limit without anyone changing it. State the currency of the limit explicitly, set it in the currency the money actually leaves in, and if the agent transacts across several, give each its own ceiling rather than a converted shared one.
Emergency spend during an incident
The operations agent that must scale infrastructure at three in the morning is a real requirement, and refusing it produces a workaround rather than a control. The answer is the break-glass pattern: a higher ceiling that is fast to invoke, requires a stated reason, expires automatically, and is reviewed afterwards against the incident record. Speed survives and the unobserved part goes away. If elevations are frequent and unlinked to incidents, expect the reviewer to ask why.
Pilot drift
The most common finding in this whole area is not a breached limit but a limit nobody chose. A pilot ceiling becomes the production ceiling. A temporary raise for quarter-end is never reversed. A platform default of $250,000 a month is inherited rather than decided. Every limit carries an owner, an effective date and a review date, and the review exists mainly to discover which of your numbers were decisions and which were defaults.
One further case belongs here but resolves outside your organisation. Where scheme rules or regulation assume a human authenticates a payment, an agent-initiated transaction raises a question your acquirer will eventually ask, and the emerging agentic rails address it by binding a cryptographically signed mandate to the credential and the scope. Treat every specific claim in that area — including anything asserted on this page — as something to confirm against current scheme documentation rather than as a settled property, because it is moving quickly.
What gets pushed back on and the answer
These eight come up in board papers, in enterprise security reviews of vendors who deploy agents, and in internal audit’s first pass over an agent programme. The difference between a good answer and a defensive one is, as usual, a number.
“We do not let agents touch money.”
Worth testing against the definition rather than the intent. If an agent can renew a subscription, provision a cloud resource, raise a purchase order, accept a quote, adjust an advertising bid or approve an expense, it commits the organisation to spend even though no payment instruction ever passes through its hands. The useful exercise is to list every tool the agent holds and ask of each one whether exercising it creates an obligation. Teams that run that exercise usually find two or three tools they had not classified as financial at all.
“The agent is instructed to stay within budget.”
Instructions are worth writing and they do reduce ordinary-case noise, but an instruction is not an enforcement point. The model is being asked to constrain itself, the constraint sits in the layer prompt injection targets first, and it stops applying silently the moment somebody edits the prompt. The test to apply is simple: name the system that would refuse. If the answer is the agent, there is no control — and note that a limit the agent can read is a limit the agent can be argued into believing an exception applies to.
“A human approves every payment.”
Then the question is what the approval actually consists of, because oversight that cannot fail is not oversight. Three hundred approvals timestamped inside four minutes is a click, and both an auditor and a thoughtful buyer will read it that way. Make the approval evidence-bearing: what the approver saw, how long they had it, what proportion they sent back, and whether any were rejected at all. An approval step with a rejection rate of zero over twelve months invites the question of whether it is performed rather than executed.
“We would catch it in reconciliation.”
You would, and that is worth having — but reconciliation is detective and operates after settlement, so the honest way to describe it is by its latency. Work out the number: the aggregate ceiling for the period multiplied by the periods that can close before a human looks. If payables reconcile daily and the agent has no aggregate cap, that number is a full day of unconstrained machine throughput, and over a long weekend it is three. Put the figure in front of whoever owns the risk and let them accept it or fund the preventive layer.
“Our per-transaction limit is very low.”
The per-transaction ceiling is the axis a runaway agent never touches. An agent making one payment every sixteen seconds against a $2,500 ceiling can move $562,500 in an hour without a single control firing, because each individual decision is correct and inside authority. Low per-item limits are still worth setting — they bound the misread invoice and the misplaced decimal — but they constrain the size of a mistake rather than the size of a failure. The limits that bind a failure are the aggregate and the rate.
“It runs in a sandbox.”
Then confirm what is sandboxed. A non-production environment holding production payment credentials is not a sandbox. It is production with worse monitoring. The properties that make a test environment safe are test counterparties, test rails and credentials that cannot settle, and each of those should be verifiable rather than asserted. The transition question matters as much: what changes at the moment the agent is promoted, who approves that change, and whether the limits configured in test travelled with it or were re-entered by hand.
“If something goes wrong we will recall the payments.”
Recovery is partial, slow and relationship-dependent, and it is a poor substitute for a ceiling. Some transfers can be returned within a window and some cannot. Card disputes run on defined reason codes and time limits. Anything already settled to a genuine supplier becomes a commercial negotiation about credit notes and set-off rather than a banking operation. Recovery also consumes the same finance team that has to keep the month closing. Treat it as loss mitigation with an uncertain yield, not as a control, and confirm the actual mechanics with your bank before you need them.
“This is a finance matter, not a security one.”
It is genuinely a joint control, and the failure mode when it is owned by only one side is predictable in both directions. Engineering sets the ceilings without reference to the delegation-of-authority framework, so the numbers have no basis anyone can defend. Or finance writes an approval policy that no system enforces, and the agent inherits whatever its credential can reach. The workable split is that the owner of the approval framework approves the delegation and the number, security and engineering own where it is enforced and what it logs, and internal audit or an external reviewer tests that the two agree.
Frequently Asked Questions
How much should an AI agent be allowed to spend?
Is a per-transaction limit enough on its own?
Can an AI agent approve its own payments?
Does SOC 2 require AI agent spending limits?
Where should the spending limit actually be enforced?
What is a sensible starting limit for a new agent?
How do you evidence agent spending controls to an auditor?
What should happen when an agent hits its spending limit?
Does this apply to cloud and API spend, or only to payments?
Who should approve an AI agent’s spending authority?
Related Reading
Copilot Oversharing and Permission Hygiene
AI collapses the effort to discover information, so latent over-permissioning becomes exploitable.
Read moreConnectors and the Permission Inheritance Problem
Data access entitlement is not authorisation for an AI purpose. Assessing connectors proportionately.
Read moreWhat Counts as an AI Incident?
The classification test, the categories worth defining, and what an AI incident record must capture.
Read moreThe Ten Questions That Govern Any AI Agent
Scope, ownership, data, capability, identity, oversight, failure detection, evidence, reassessment and how to stop it.
Read moreISO 42001 Knowledge Hub
AIMS controls, EU AI Act mapping, risk assessment and guides.
Read moreISO 42001 (AI Management)
The world's first AI management system standard, for AI builders.
Read more