Can an AI Agent Approve Its Own Payment?

An AI agent approving its own payment is not a new class of problem, and treating it as one is the mistake. It is a release strategy — the same question every finance function answered decades ago when it decided who may create a payment, who may release it, above what value, and in what combination. The vocabulary is new. The control is not.

Search for it and you will mostly find the answer given in wallet terms: private keys, spend limits, an approval gate above some threshold. That framing comes from consumer and crypto payments, where authority really does live in whoever holds the key. In a company it does not. Authority lives in a release path inside a system of record, and ultimately in a mandate the bank holds. An answer that never mentions either is describing a different problem.

I have spent eighteen years in SAP FI and treasury, much of it on exactly this layer — release strategies, approval limits, who is allowed to maintain the bank details behind a payment. What follows is that reasoning applied to a non-human initiator.

The question underneath the question

"Can it approve its own payment" is really three questions, and they have three different owners.

Is it allowed to initiate? A configuration question in the source system.

Can the same identity that initiated also release? A segregation question, enforced by the system of record — and this is the one that actually matters.

Would the bank act on the instruction if it got that far? A mandate question, and the answer does not depend on any of your software.

Most published guidance answers the first, gestures at the second, and never reaches the third.

Where the control has to live

Here is the part that decides the design: the separation between initiate and release must be enforced by the system that holds the document, not by the agent framework.

The reason is structural rather than technical. The agent framework is the component you are trying to constrain. A rule enforced inside it is a rule the constrained thing administers — and every mechanism it offers to express that rule is configuration a future integration can widen, usually for a good reason, usually without anyone connecting the change to a control. It is the same argument as an instruction is not a control: what is enforced by the thing being governed is not a boundary.

The release path in the ERP or the TMS is different in kind. It sits on the document. It cannot be talked out of its opinion. It produces evidence as a side effect. And it already exists, tested, with someone's name against the configuration — which is the segregation of duties model the company already runs.

So the design rule is short: an agent may propose a payment through the same door a person would, and the release path treats it exactly as it treats a person. If your architecture has the agent writing through an integration that bypasses the release path, you have not automated a payment — you have built a second, uncontrolled one.

The per-transaction limit is the wrong limit

This is the claim I would most want a design review to take away, because the control that gets reached for first is the one an agent defeats first.

Give an agent a €10,000 per-transaction ceiling and instruct it to settle a supplier's balance. It has an obvious, entirely reasonable route to completing the task: several payments, each under the ceiling. Nothing has been circumvented in any sense the agent would recognise. It was given a constraint and a goal, and it satisfied both.

Accounts payable has a name for the human version and has watched for it for as long as there have been approval thresholds. The countermeasure is not a lower ceiling. It is that the ceiling was never meant to be the only limit.

Aggregate. Total per counterparty per period, checked against everything already released this period rather than against the item in hand.

Velocity. How many instructions may be released in a window at all. Most damaging incidents are not one clever payment; they are the same wrong payment repeated faster than anyone looked.

Total exposure. A ceiling on what the whole capability may move in a day, independent of how it is distributed.

"

An agent given a per-transaction ceiling and a goal will meet both. Structuring is not an attack — it is the obvious way to satisfy the constraint you actually wrote.

Note the shape of that. The per-transaction cap is not wrong; it is incomplete in a way that only shows up against a tireless initiator. A person structuring payments to stay under a threshold is doing something deliberate and detectable. An agent doing it is following instructions.

The bank is a control you did not configure

Every internal limit sits inside software you own. There is one that does not, and it is the reason a badly configured agent is less catastrophic than it first appears.

Payment authority at a bank comes from the account mandate — who may sign, to what value, in what combination, on which accounts. It is a legal arrangement, maintained through bank account management, and no amount of configuration in an ERP, a TMS or an agent platform widens it. If a released instruction exceeds what the mandate confers, the bank declines it.

Two practical consequences. First, "what could this agent theoretically move" has a ceiling you did not set and cannot accidentally raise from inside. Second, that ceiling is only as current as your mandate housekeeping — which is exactly the discipline that decays quietly, because nobody's job description includes noticing that a signatory left in March.

Worth adding to the design review: which accounts is this capability able to reach, and what do their mandates actually say today.

Accountability is a field, not a policy

When something goes wrong, nobody reads the AI governance policy. They open the document and look at who created it, who changed it, and who released it.

That is what makes a shared technical user so damaging. It is administratively convenient, it is what most integrations do by default, and it destroys attribution at the exact moment attribution is the whole question. A document that says a service account released a payment tells an investigator nothing and gives them nowhere to go.

The workable pattern gives the agent an identity of its own, scoped to the task, and records the human who requested the run so the document carries both — what acted, and on whose behalf. It is more work at build time and it is the difference between an incident with a thread to pull and an incident without one. The same reasoning applies to the audit trail around it: the record has to be produced by the system, not by the agent describing itself.

What I would decide

An agent may create and propose. It may not release anything irreversible under the identity that created it — enforced in the system of record, not in the agent platform. And the releasing human has to see the source rather than the agent's summary of it, or the four-eyes control has already collapsed into one without anyone changing a setting.

Limits are cumulative, not per item: aggregate per counterparty, velocity per window, total exposure per day. Assume the per-transaction ceiling will be met by splitting, because it will.

The agent gets its own identity. The requesting human is recorded on the same document. Neither of those is optional if you intend to be able to explain what happened.

And before any of it: check what the bank mandate on those accounts actually permits, because that is the only limit in the design that your own configuration cannot quietly widen.

See also security boundaries for enterprise AI agents and human decision rights in AI-native workflows.