Ask whether AI agent payments are safe and you get two different articles. Security vendors answer a threat model question: can the agent be attacked. Law firms answer a consent question: did the payer agree to what the software did. A finance lead needs both, because the second question only starts once the first has already gone wrong.

Held apart, each half reads reassuringly. Put together, they describe the actual position: the technology is attackable in ways payment systems have not had to handle before, and the rule that decides who pays for the worst of those attacks has not been written yet.

The useful conclusion is unglamorous. Safety in agent payments is mostly a property of the layer underneath the model, not of the model. An academic systematisation of security in agentic commerce reaches the same place from the other direction, finding that failures propagate out of the reasoning and tooling layers into custody, settlement and compliance exposure, which makes this a cross-layer problem rather than an AI problem. What your agent runs on decides more than which agent you run.

What actually goes wrong

Three properties make an agent payment different in kind from a scheduled transfer, and all three come from the same source: the agent to agent threat model sets out delegated authority, machine speed and on-chain settlement as the structural changes, then lists the attacks each one opens.

Prompt injection is the failure that reaches the money

An agent takes instructions in natural language and turns them into actions. Crafted input can therefore turn it into an instrument of someone else's intent, producing an unauthorised payment or redirecting a legitimate one. Identity spoofing does the same trick from a different angle, since anyone can stand up an agent and claim to be a trusted counterparty. Both get worse when agents delegate to each other, because one manipulated instruction at the top of a chain becomes a cascade of payments below it.

This is not a bug class you can test out of a model. It is the cost of the interface.

Machine speed removes the pause you were relying on

Most payment controls in a finance function are really just delay. Someone notices. An approver hesitates. An agent settling in milliseconds gives you none of that, and no human review sits between the decision and the debit unless you engineer one back in.

Irreversible settlement removes the second chance

Much agent activity has landed on rails that do not reverse. The Keyrock data on the market shows why: agents settled over 73 million dollars across 176 million blockchain transactions between May 2025 and April 2026, with 98.6 percent in USDC and a median transaction between one and ten cents, and 76 percent of those payments fell below the 30 cent card fee floor where conventional rails are not economic. Micropayments at machine scale went where the fees were near zero. That choice also removed the recall.

We covered the mechanics of that in AI agent stablecoin payments and where x402 fits. The point here is narrower: irreversibility converts every control question into a prevention question.

Who bears the loss under the rules that exist today

This is where most agentic payment writing stops and hand-waves. It does not have to. A solicitor's analysis of how the Payment Services Regulations 2017 apply to an agent-initiated payment maps the position regulation by regulation, and the following is that reading rather than ours.

Regulation 67: consent to a transaction, or to a series

A payment is authorised only where the payer consented to that transaction, or to a series it forms part of, in the form and procedure agreed with the provider. An agent acting inside a defined delegation can be authorised. An instruction outside that scope may not be. Critically, the parameters you configure in a dashboard are not automatically the payer's legal consent; whether they amount to it is fact-specific and depends on the contract.

Regulation 76 and 77: the refund duty and the cap

Where a transaction was not authorised under regulation 67, regulation 76 obliges the payer's provider to refund it. Regulation 77 then caps payer liability at 35 pounds for a lost, stolen or misappropriated instrument, and makes it unlimited only on fraud or an intentional or grossly negligent breach of the security obligations in regulation 72. Regulation 75 puts the burden of proving authentication on the provider, and recorded use of an instrument is not in itself necessarily sufficient to prove the payer authorised anything. Regulation 74 gives you 13 months from the debit to notify, subject to a stated exception.

Regulation 63(5): the one thing a business can move by contract

A payer that is not a consumer, a micro-enterprise or a charity may agree with its provider to disapply regulations 75 and 77. So a business can contract away both the evidential burden and the liability cap, which is the opposite of the protection most readers assume they have. Regulation 76 is not on that list, so the refund duty for an unauthorised transaction survives a business agreement.

Read those together and the practical test is not how clever the agent is. It is whether the delegation was defined tightly enough, and recorded well enough, that someone can establish after the event what you actually consented to.

The case the rules do not cover yet

Now the hard one. An agent is manipulated into paying a fraudster. The instruction came through the agreed channel, the authentication happened, and no human exercised judgment at the point of execution. As the Oxford Business Law Blog puts it, the transaction may remain formally authorised while the consumer has exercised no meaningful judgment, and concepts like deception, reasonable care and gross negligence are calibrated to human behaviour. Authorised push payment reimbursement was built for a person being tricked, not for software being injected.

Lawyers watching the UK regime expect that gap to be closed by extending the APP fraud regime to agentic transactions specifically, including prompt injection cases. For now, it is unclear whether liability sits with the user who deployed the agent, the developer of the AI system, the payment service provider or the merchant. No vendor claim closes that. Treat anyone who says otherwise as selling.

The UK put the question out for comment in July 2026

On 14 July 2026 HM Treasury opened Modernising Payment Services Regulation, which asks how the framework should adapt to tokenised payments, Open Banking and agentic payments. Question 15 goes directly at this article's subject, asking whether the consent, authentication and unauthorised-transaction liability provisions need updating, and the consultation closes on 6 October 2026.

The direction of travel is legible even though the rule is not written. Firms are advised to expect an eventual framework built on clear mandates, transaction parameters, audit trails, revocation mechanisms and an explicit allocation of responsibility between payment firms and third party technology providers. Underneath sits an older problem: in law a principal is responsible for an agent acting within its remit, and beyond that remit the agent becomes responsible, but an agent with no legal persona may leave the principal responsible at all times.

If that is where this lands, an unbounded delegation is not a convenience. It is an uncapped exposure with your name on it.

The controls that change the answer

None of this makes agent payments unusable. It makes the loose version unusable.

  • •Bound the mandate by payee and by transaction, not by month. A monthly budget authorises a category. A named payee with a ceiling authorises a payment.
  • •Record the consent trail, because the provider has to prove authentication after the event and you will have to show what you delegated.
  • •Keep a human checkpoint on high value and anomalous payments, which is the one control that survives machine speed.
  • •Make revocation instant and test it, on the assumption the coming rules will require it.
  • •Route anything above your threshold onto a rail that can be recalled, and accept the fee.
  • •Know which layer each control lives in. We broke that down in the three layers of AI agent payment infrastructure, and the mandate layer is the one most commonly overestimated: what an AP2 mandate actually proves is narrower than the marketing around it.

Where the money sits is part of the answer

One distinction is worth stating plainly, because it is the most commonly confused thing in this niche. Safeguarding and deposit protection answer the failure of your provider. They say nothing about an agent paying the wrong party. Both matter, and they are not substitutes.

For the record on our own side: EXFI is a trading name of EX Financial Solutions Ltd, which is not itself authorised or regulated by the FCA and acts as a distributor of payment services provided by Gemba Finance Ltd. EXFI accounts are payment accounts, not bank accounts; funds are not covered by the FSCS but are safeguarded in segregated accounts in accordance with the Payment Services Regulations 2017. That is the same distinction we set out in what a payment institution is and go through in more detail in safeguarding compared with FSCS cover.

Our multi-currency accounts run on SWIFT, SEPA, Faster Payments, BACS and CHAPS today, and regulated payment services are provided by Gemba Finance Limited, FCA FRN 804853, for UK customers. Agent-native banking primitives are on our roadmap and announced as such. They are not a live product, and we would rather say so than sell you a mandate layer that does not exist yet.

So, are AI agent payments safe

Safe enough to run for bounded, low value, reversible payments with a recorded mandate and a working kill switch. Not yet safe as an open-ended delegation of company money.

The reason is specific rather than atmospheric. The single failure most likely to cost you real money, a manipulated agent producing a payment that is formally authorised, currently has no settled answer in UK law on who bears the loss, and the consultation that might settle it closes in October 2026. Build for the version of the rules that is coming, keep the mandate narrow until it arrives, and treat the account and the rail underneath the agent as part of the security design rather than plumbing.

FAQ

Can I get the money back if an AI agent pays the wrong person?

It depends which failure happened. If the transaction was not authorised under regulation 67, the payer's provider must refund it under regulation 76. If the agent stayed inside the delegation you defined, the payment is usually authorised and recovery becomes a commercial matter between you and the recipient rather than a statutory one.

Does strong customer authentication apply to an agent-initiated payment?

The rules assume a human exercising judgment at the moment of authorisation, which is precisely the assumption an autonomous agent removes. Where authentication was required and not applied, a provider generally cannot show the payment was properly authenticated, which is why the Treasury consultation asks whether these provisions need updating at all.

Is a business payer protected the same way a consumer is?

No, and the gap runs the wrong way. Under regulation 63(5) a payer that is not a consumer, micro-enterprise or charity can agree to disapply regulations 75 and 77, giving up the evidential burden on the provider and the liability cap. The regulation 76 refund duty for an unauthorised transaction is not on that list and survives.

How long do I have to report a payment my agent should not have made?

Regulation 74 requires notification without undue delay and in any event within 13 months of the debit date, subject to a stated exception. Outside that window the statutory route closes regardless of the merits, which is an argument for monitoring agent activity daily rather than at month end.

Are stablecoin agent payments safer than card or bank rails?

Different risk, not less risk. Stablecoin settlement is fast and cheap, which is why most early agent volume went there, but on-chain transactions are generally not reversible, so an injected or mistaken instruction cannot be recalled after execution.