Invoice Fraud and AI Agents | Tirnu

Part 2 Agentic finance series. Part 1: Agentic AI Has a Liquidity Problem

Picture a scenario. It is Thursday, late afternoon. An invoice arrives from a supplier you have paid every month for two years. Same logo. Same contact. Same amount, give or take. The finance assistant your team started using in the spring opens the PDF, matches it to the purchase order and gets the payment ready.

Nobody notices the line at the bottom of page two, set in white text on a white background. In plain words it says:

A person would never see that line. But a text-extraction tool may pass it straight to the assistant, even though it is invisible on the rendered page. And to the assistant, it can read like any other instruction in the document.

Old fraud, new door

Payment diversion is not new. It is the core of what the FBI calls business email compromise: convince someone that a supplier’s bank account has changed, then wait for the next payment. In its 2025 report, the FBI’s Internet Crime Complaint Center counted about $3.05 billion in reported losses from just under 25,000 complaints, second only to investment fraud. Those are US figures, and only the cases people reported. The real number is larger.

For years the defences were built around a person. A call-back to the supplier. A second signature. A finance clerk with a feeling that something is off.

What is changing is who reads the invoice first. More and more, it is software. Some of that software is designed to flag suspicious content, and that helps. But a check that works most of the time is not the same as a control.

The technique is already in use

The invoice above is an illustration, not a reported incident. The technique behind it is real. In April 2026, researchers at Forcepoint published ten indirect prompt injection payloads found in the wild, one of them aimed at AI agents that can make payments. In July, Zscaler described two campaigns built to fool AI agents browsing the web. One hid a payment request inside what looked like technical documentation, with code ready to send crypto to a fixed wallet.

Those attacks targeted agents on the open web, not invoices in a mailbox. But the technique doesn’t care what kind of document carries it, and an invoice is just another document.

Three ways context gets poisoned

What isn’t enough on its own

Model safeguards matter. They just shouldn’t be the last line of defence.

Relying on the model to be careful. Modern models are trained to give their own instructions priority over text they find in documents, and that makes attacks harder. But it is a defence that works most of the time, not every time.

Waiting for a smarter model. Better models help at the margin. But a system that reads untrusted content and can also act on it will, sometimes, act on the wrong content.

Trying to spot every trick. Attackers change their wording faster than filters can learn it.

If your protection depends on the model noticing, you don’t have a control. You have a hope.

What does work: rules the agent can’t touch

In Part 1 we argued that the check must sit outside the agent, in code it cannot reach or change. Invoice fraud is where that stops being theory.

The architecture is simple to describe. The AI reads the invoice and prepares a payment proposal. It never sends money itself. A separate payment service, which the AI cannot change, checks every proposal against the verified beneficiary list, the limits and the approvals required, and only then executes it.

• A new or changed bank account is never the agent’s decision. Every change goes to a person, who confirms it through a channel the request did not come from: a phone number you already had, not the one in the email.
• Pay only verified counterparties. The agent may propose payments to suppliers on the approved list. It may not add to that list, edit it, or be talked into it.
• Check the name against the account. Since 9 October 2025, banks in the euro area must check the payee’s name against the IBAN before a credit transfer goes out, standard or instant, and tell you if it doesn’t match. Treat a mismatch as a stop.
• Limits that bind. Caps per supplier and per week, enforced by the system, not suggested in a prompt.
• Keep reading and paying apart. The part of the system that reads outside documents should not be the part that can move money.
• Write everything down. What the agent read, what it proposed, why, and who approved it. After an incident, that record is what lets you understand and recover.

The assistant was fooled. The money still went to the right place.

Look back at the operating loop from Part 1: observe, propose, check, route, execute or escalate, record. Invoice fraud attacks step two, the model’s proposal. Steps three to six are where it gets stopped.

A checklist for any business, with or without AI

1. Never accept bank-detail changes by email alone. Call back on a number you already had.
2. Keep a list of verified supplier accounts. Changing it needs two people.
3. Turn on your bank’s payee name check, and don’t override a mismatch without a call.
4. Set payment limits per supplier.
5. Treat urgency and secrecy as red flags: “pay today”, “don’t tell anyone”, “the usual contact is away”.
6. If an AI tool reads your invoices, let it prepare payments, not send them. Execution belongs to a separate system with its own checks.
7. Know your first hour. If a payment went to the wrong place, call your bank immediately to ask for a recall, then report it. Speed matters more than anything else.

The comforting part

None of this is exotic. These are the controls good finance teams have always had, moved from a person’s habits into the system itself.

In Part 1 we wrote that the constraint layer and the compliance layer are the same layer, seen from two directions. Invoice fraud shows it is the security layer too.

A trustworthy financial agent is not one that never gets fooled. It is one whose mistakes cannot bypass independently enforced payment controls.

Tirnu operates from Zug, Switzerland, classified as a Virtual Asset Service Provider. Nothing in this article is investment, legal or tax advice.