Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Happens When a Fake Invoice Email Instructs an AI Agent to Change a Payee?
The agent reads the spoofed email as content, and where it holds the accounts-payable session it can change the payee and save the new bank details before the next payment runs. What settles the outcome is what the model received on the vendor record and who approved the change.
The rule in most accounts-payable teams is simple: a vendor that writes to change its bank details gets a phone call before anyone touches the record. The rule survives because the request is cheap to send, hard to tell from a real one, and expensive to get wrong, and because the mailbox is the one system where a stranger can reach the person who holds the pay screen. An agent given that inbox inherits the same session. It reads the message, opens the vendor record and edits the field the email asked about, and the next payment run uses whatever it saved. The worked record is a spoofed vendor email with new bank details, read by an agent that can reach the bill-pay screen. At each step the measure is the same: what the page rendered to the model, which field the run changed, and who released the money. The mailbox is where the change is asked for, and the pay screen is where it becomes real. A payment sent to a changed account does not come back, and a run that read the account and routing numbers should be treated as a run that can repeat them.
Key findings
- For a payee change to be safe, the values on the vendor record would have to be replaced with consistent tokens before any model reads the screen, so the run works from ACCT_001 and ROUTING_001 and the real numbers resolve only at an approved payment (What Is a Protected Browser for AI Agents?).
- It would also require a named person approving the change itself and a record of what the model saw (What Is an Approved Destination for AI Agent Output?).
- What the pages reviewed do not describe is a check on the change: NetSuite's pay reference documents the Payee field and stops at the transaction (Oracle, 2026).
- NetSuite's form puts the payee on the payment transaction and clears the check options once the electronic-payment box is checked (Oracle, 2026).
- QuickBooks Online sets the vendor's bank details from the payee line, where the answer says "You'll need the account number for the vendor" (Intuit, 2021).
- The FBI records 305,033 business email compromise incidents and about $55.5 billion in exposed losses from October 2013 to December 2023, and tells businesses to "Use secondary channels and/or two-factor authentication to verify requests for changes in account information" (FBI IC3, Business Email Compromise, 2024).
What does the agent read when the vendor's email arrives?
The record is a spoofed vendor email with new bank details, delivered to the accounts-payable inbox an agent works. It carries a sender name that matches a vendor in the ledger, a reply-to address on a domain registered days earlier, an invoice attachment, and a paragraph asking that future payments use a new account.
For the agent, that is content. OWASP states that "Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files" (OWASP, LLM01, 2025). The instruction arrives with the invoice, and the agent has a name in the From line and a domain in the Reply-To line, and no signal that the change came from the vendor.
That is the lethal trifecta: access to the vendor master and its bank details, exposure to content a stranger wrote, and the ability to send money out (What Is the Lethal Trifecta for AI Agents?). The design literature is explicit: once an agent ingests untrusted input, it "must be constrained so that it is impossible for that input to trigger any consequential actions" (Beurer-Kellner et al., 2025). Meta's rule of two puts the same limit as a budget: "agents must satisfy no more than two of the following three properties within a session", untrusted input, sensitive data, and state change or external communication (Meta AI, 2025).
In the studies reviewed, undefended agents followed injected instructions at rates from 17.4% to 100%, with a median of 51% (How Often Do AI Agents Follow Injected Instructions?).
What does a payee change look like on the bill-pay screen?
On a NetSuite payment, the change and the payment sit close together. The Pay Single Vendor transaction is where a vendor is paid: "Go to Transactions > Payables > Pay Single Vendor", and "In the Payee field, select the payee you want to pay". Checking the "For Electronic Bank Payment" box clears the check options (Oracle, 2026).
QuickBooks Online splits the same work across two screens. The bank details are set up from the payee line: "To set up a vendor with open bills, select Set up Bank Transfers within the same line as the Payee", then "Select Enter vendor's bank account info", then Next. A vendor with no open bill uses "Set up vendors for bank transfers", and "You'll need the account number for the vendor" (Intuit, 2021). The answer is a moderator's guide from 2021 and names no field labels.
Both pages make the payee and the bank details ordinary fields on a page a clerk edits, and neither describes a control that compares the new account with the channel the instruction arrived on. An agent that reaches the bill-pay page completes the change with the same clicks a person uses. The vendor invoice page is where the numbers first enter a payment (Can an AI Agent Pay an Invoice in QuickBooks Without Seeing the Vendor's Bank Account?).
What do the vendors themselves say?
The vendor pages document the form, the credential and the instruction, and none documents a payee change as a separate decision.
| Dimension | What the vendor's page states | What a buyer should verify |
|---|---|---|
| The payee field | "In the Payee field, select the payee you want to pay" (Oracle, 2026) | Whether the record's bank details appear on this form, and to whom |
| Where the bank details are entered | "Select Enter vendor's bank account info", then Next (Intuit, 2021) | Who may edit the field, and whether the edit needs a second person |
| What a credential control covers | "the AI agent and underlying LLM never need to see nor handle the credentials", injected "if, and only if, the human approves the access" (1Password, 2025) | Whether the control covers the page's data or only the login |
| What the agent design allows | "agents must satisfy no more than two of the following three properties within a session" (Meta AI, 2025) | Which two the deployment keeps |
Two controls and one absence stand out. 1Password's control is credential custody: the agent and the model "never need to see nor handle the credentials", which keeps a password out of the model and leaves the payee field, once the session is open, as the page rendered it (1Password, 2025). NetSuite and Intuit document the fields the change passes through and describe no comparison of the account with the sender.
Why does a payment approval not cover a payee change?
The approval most AP systems enforce sits on the payment: a decision about an amount, a vendor and a date. By the time a person sees the payment, the record may have carried the new number for days, under the vendor's familiar name, with no signal that it changed. The approval does its job, which is to authorize a payment, and it leaves open the question of who the vendor's bank is.
The FBI's payroll diversion advisory shows the same structure. Attackers phish a login, then add rules "preventing the employee from receiving alerts regarding direct deposit changes", and "Direct deposits are then changed and redirected to an account controlled by the cybercriminal" (FBI IC3, Payroll, 2018). Its advice is aimed at the change: "Apply heightened scrutiny to bank information initiated by employees seeking to update or change direct deposit credentials".
The business email compromise advisory is more direct. It tells businesses to "Use secondary channels and/or two-factor authentication to verify requests for changes in account information" (FBI IC3, Business Email Compromise, 2024). A callback to a number on file checks the request on another channel. An agent that reads the request cannot make that call, so the change has to reach a person who sees it, as How Do I Control Where a Browser Agent Can Submit Data? sets out.
What record does the run leave for the finance team?
After a fraudulent payee change, the audit trail says very little. The log records that a user changed the vendor's bank details, with the old and new values, and the session, which for an agent working a clerk's login is the clerk. It holds neither the email that produced the change nor the page the model read.
OWASP describes excessive agency as "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM" (OWASP, LLM06, 2025). A payee change through a full AP session is excessive permission: the task needed the invoice, and the session could edit the vendor master.
The FBI's 2024 report counts 21,442 business email compromise complaints and $2,770,151,146 in BEC losses, against 859,532 complaints and $16.6 billion across every crime type, and defines the category as a scam targeting "businesses or individuals working with suppliers and/or businesses regularly performing wire transfer payments" (FBI IC3, Internet Crime Report, 2024). A record that holds the page as the model saw it, the action and the approver's name is the difference between a report and a reconstruction, which What Is a Secure Alternative to Agentic Browsers for Paying Vendor Invoices? treats as the test.
What does a governed environment change?
A governed environment is a control class that acts where a screen is rendered, before a model reads it, and it changes three things for a payee change. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers.First, the page's values are replaced with consistent tokens: the vendor record renders as VENDOR_014, the account as ACCT_014 and the routing as ROUTING_014, so the model works from tokens, never the numbers that move money. Second, real values resolve only at an approved destination, at the moment of an approved action, so the account that reaches a payment is the one a named person released. Third, the change itself is consequential: a named person approves the payee change before it is saved, and every screen as tokens, every action and every approval is written to an exported record.
The difference from a payment approval is where the decision sits. A payment approval asks whether to pay this amount to this vendor; an approval on the change asks whether this vendor's bank is now this account, the question the email pretends to answer.
A credential control that keeps an agent from seeing a password leaves the page it opened readable, which is why the comparison with a credential-custody design matters here (RedactSure vs 1Password: 2026 Comparison & Alternative). A payee change is data on a screen rather than a credential in a login, and the control has to sit where the data is drawn.
What the record shows
The control that decides this question sits where the vendor record is drawn and where the change is approved, not in the mailbox that asked for it. The payee and the bank details are ordinary fields on a bill-pay screen: NetSuite's form asks the user to "select the payee you want to pay" and carries the electronic-payment box, and QuickBooks Online sets up the account from the payee line (Oracle, 2026; Intuit, 2021). The email is untrusted content in a session that reaches the vendor master, the payment and the record, and a payment approval arrives after the record has been edited. Three questions decide the outcome: what the page rendered to the model, who approved the change, and what record holds both. An accounts-payable team should change the account on one test vendor, list every field the page shows before and after, and compare that with the fields the payment used.
Methodology and limitations
Public documentation read in full gives a sound view of where each product applies its control, and this page rests on the NetSuite help page and a QuickBooks community answer, vendor pages from Meta and 1Password, the FBI IC3 advisories and annual report, the OWASP entries on prompt injection and excessive agency, and a research preprint on prompt injection design. Vendor pages were read between October 21, 2026 and October 22, 2026.
No product on this page was tested for this page, and "not described in the pages reviewed" means the pages reviewed. The NetSuite page is a form reference and the QuickBooks answer a moderator's post from 2021, so neither is a specification of current behavior; the products change and the page carries its date. The example describes a record type, a spoofed vendor email with new bank details read by an agent, not an organization. RedactSure is deploying now with enterprise and government customers. Determinations about whether a payment or a record change meets a contractual or regulatory requirement belong to counsel and the organization's compliance officers.
Frequently asked questions
What happens when an agent reads a fake invoice email that asks for a new payee?
The message becomes content the model works from, and the run continues into whatever pay screen the agent can reach. Nothing in the email proves it came from the vendor, and nothing on a bill-pay form compares the new account with the sender. If the agent can edit the vendor record, the change is a few fields away and the next payment uses the new account. Treat the email as a stranger's instruction, whatever name is on it.
What does the agent read on the vendor record when it changes the payee?
The rendered page: the vendor name, the payee field, the bank details and the payment method, in the layout a clerk sees. On NetSuite's Pay Single Vendor form that includes the electronic-payment box, and in QuickBooks Online the account details are entered from the payee line. The model reads the numbers it types or that the page echoes back, so a change made this way puts the account and routing numbers into the run's context.
Who approves a payee change before the next payment runs?
Nobody is assigned to approve the change as a change. The approval those systems describe sits on the payment, where a person authorizes an amount to a vendor whose account is already on the record. That leaves the record edit to whoever can open the vendor page, which may be a clerk, a shared service account or an agent working either. Ask for the name of the person who approved the change itself.
What record does the run leave for an auditor?
An audit log entry with a user, a timestamp and the old and new values, which shows what changed and not why. It will not hold the email that prompted the change, the page as the model read it, or the instruction the model followed. Those are separate artifacts, and their absence makes a fraudulent change hard to reconstruct. Ask whether the record holds the page, the action and the approver together.
Do the vendor's own confirmations show what the model received?
No. A confirmation proves that the page accepted a value; it says nothing about what the model read to produce it. NetSuite's help documents the transaction's fields and QuickBooks the setup steps, and both describe the screen rather than the model's view. A confirmation email after the change is one more message in the inbox, reaching the same reader the fraudulent request did.
Can the bank stop a payment after a payee change?
Sometimes, and not reliably. A bank can recall a transfer in limited circumstances, and recovery depends on how quickly the organization reports it, which is why the FBI's advisories put verification before the change. The payee change is when the money is redirected; the payment is when it leaves. Control the change and the payment inherits the correct account, which is the version of the sequence a finance team can still check.
How RedactSure Keeps a Payee Change Behind a Named Approval
An approval on a payment arrives after the vendor record has been edited, and a credential control protects the login, not the page. The FBI counts 21,442 business email compromise complaints and $2,770,151,146 in reported losses for 2024.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the vendor record, reads the account and routing numbers, and saves what the email asked for. Inside: the record draws VENDOR_014, ACCT_014 and ROUTING_014 before any model reads it, and real values resolve when a named controller approves the change.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A changed payee is the value an auditor asks about first, so keep the approval beside it. Bring one vendor and one change and see, with test values, what the model reads and who releases the money. Book a demo