Who pays when an AI agent overspends? Australia has no answer yet

On 5 November the Sydney-based Humanware Institute published its analysis of the public record from the Australian Parliament's AI inquiry, and its sharpest finding is about money. Nine financial-system institutions gave evidence: three major banks, their peak body, four regulators and Treasury. None of the nine said who carries the loss when a person's AI agent spends within its permission but not as the person meant.

What the evidence showed

According to the Institute's release, the banks pointed to agent builders and the consumer regulator referred the question to Treasury. The markets regulator relied on the law as it stands, while the Productivity Commission cited a review that hasn't been done. Humanware's comparison of eight other governments found none with a settled allocation of loss for the same case. Australian Cyber Security Magazine's report records the same conclusion: existing law applies, but how it applies here is contested or untested.

Humanware's figures are its own coding of 564 public submissions, ten hearing days and 66 answers to questions on notice. The release discloses that AI tools were used in the analysis and that 62 submissions were hand-coded as a check, so the counts are best read as one organisation's analysis. We've worked from the release, the summary page and press coverage, and we haven't reviewed the full 106-page PDF. The committee's own final report is due by 30 November, so the official position could change within weeks.

Humanware wants payments dealt with early, since Mastercard reported Australia's first authenticated agent transactions in January and unauthorised-transaction rules already exist. The release says the Reserve Bank of Australia's payments review won't reach conclusions until 2028. The RBA's June summary raises AI-enabled payment tools as a possible merchant choice problem. It promises a list of priorities by the end of 2026 and further consultation by mid-2027.

Why permissions don't settle the question

Unauthorised-transaction rules deal with someone acting without permission. An agent working inside its limits has permission, so those rules don't obviously reach a purchase the owner never wanted.

Picture a hypothetical procurement agent allowed to spend $5,000 a month with approved suppliers, which renews a software plan at a higher tier nobody requested. The limit and the supplier list both held, and the business paid for something no manager wanted.

Stronger agent identity solves part of the problem. Westpac's account of the Mastercard trial says the issuer, acquirer and merchant could all see that an agent conducted the transaction, which should help with disputes and fraud detection. An identified agent shows who acted. Whether the agent did what the person wanted depends on the original instruction, and a payment network doesn't hold that record.

Where New Zealand stands

New Zealand is at the testing stage too. Westpac and Mastercard completed NZ's first authenticated agent transactions in February, buying cinema tickets and booking a Queenstown hotel with cardholder consent. Under Visa's programme, ANZ NZ, ASB, BNZ and Kiwibank are simulating agent-initiated payments in controlled environments, with no launch date given.

The local banking rules leave a similar hole. The Code of Banking Practice requires banks to reimburse unauthorised online transactions, with exceptions for dishonesty, negligence, breached terms and failure to protect banking details. Banked's guide gives the Banking Ombudsman Scheme's meaning of unauthorised as a payment made without your knowledge and consent.

Our reading, which we couldn't find tested in any NZ case, is that a customer who gave an agent a card and a mandate will struggle to call a bad purchase unauthorised. The scam commitments added to the Code on 30 November 2025 don't obviously help, because an agent's honest mistake isn't a scam.

Contract law points the same way. A Simpson Grierson update says AI agents aren't legal persons in NZ and click-to-accept deals are generally enforceable. A contract may appear to be formed even where the user's intent was misrepresented. The firm treats the question of whether users should bear the risk of their agent's actions as open, and notes that developers commonly exclude or limit liability for accuracy and performance.

We couldn't find agent-payment guidance from an NZ regulator, and Economic News reported that the Reserve Bank of New Zealand hadn't issued any.

British regulators have gone further on the responsibilities of businesses that deploy agents. On 30 October the UK's Digital Regulation Cooperation Forum published a joint statement on personal AI agents, and Freevacy's summary reports that an agent's autonomy doesn't reduce corporate accountability. The Competition and Markets Authority's guidance page was updated the same day to include the statement. Its guidance to businesses is blunt: "you are responsible for what an AI agent does in the same way you are responsible for what an employee does." UK rules don't bind NZ firms, but they're a fair signal of how a regulator here could reason.

What it means for NZ businesses

A business can sit on either side of this gap. When your own agent can commit money, you should plan to carry the loss yourself unless a contract moves it elsewhere. A first dispute would probably come down to your card terms, your vendor contract and whatever logs you kept.

When your agent deals with customers, the UK position suggests you'd answer for its conduct even if a supplier built it. Online sellers may also find customers' agents placing orders, followed by complaints that the agent got the order wrong.

Few NZ firms will have handed an agent a company card yet. The same exposure arises without one, though, wherever an agent can reorder stock, approve a credit note or accept a quote inside an ERP or procurement system. Those actions run on system permissions, and the question of what the business meant stays just as unanswered.

Next steps

• List every agent that can commit money or accept terms, including vendor features switched on inside finance, ERP and procurement software, and give each one a named owner.
• Write a plain-English mandate for each agent covering its purpose, per-transaction cap, approved counterparties and expiry date, then check that the system permissions match. DataForge's AI team can help scope this before go-live.
• Require a person to approve anything outside routine work. New suppliers, price tier changes and contract renewals are sensible triggers, because those were the decisions most likely to be wrong in our example.
• Keep the instruction, the agent's actions, any approval and the outcome in a log you control, for at least as long as your dispute windows run.
• Review vendor terms for exclusions on accuracy and performance, and negotiate warranties and indemnities where the agent can spend. Simpson Grierson recommends the same review.
• Ask your bank in writing how its card and account terms treat agent-initiated payments, and whether the Code covers your business accounts.
• If you sell online, decide how you'll handle disputed orders placed by a customer's agent, then reflect that decision in your terms of trade.
• Read the Australian committee's report when it lands by 30 November, and look for whether it assigns responsibility for agent losses or passes the question on to another review.