Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Stops an AI Agent From Approving a Fraudulent Vendor?
Nothing in the agent stops this, because a plausible vendor form is content and the agent processes it. What stops it is a person verifying the supplier through a channel the request did not supply, a bank account check, and a first payment held behind that person's approval.
Accounts payable has a new first step: an agent reads the inbox, opens a supplier's paperwork and prepares the vendor record before anyone at the company has spoken to the supplier. The work is repetitive, and the first payment to a new payee is where the repetition pays off for an attacker. A package that arrives with a letterhead, a tax form and a bank letter is content, and an agent working a browser reads it the way it reads any other page. The record used here is one new-vendor request that proves fraudulent, caught when an accounts clerk calls the number already on file for the company the request names. It is a record type, not an organization, and the same shape appears in a procurement portal, an invoicing inbox and a vendor master screen. The FBI's 2024 report counts 21,442 business email compromise complaints and $2,770,151,146 in losses for the year (FBI IC3, Report, 2024). What separates a verified supplier from a fraudulent one is a check the agent does not own, and where that check sits decides whether the delegation is safe.
Key findings
- For an agent's approval of a new vendor to be safe, the account and tax identifier would have to be replaced with consistent tokens before the model reads the screen, with the real digits resolved only at the payment a named person approved (What Is an Approved Destination for AI Agent Output?).
- It would also require a named person verifying the supplier through a channel the request did not supply, and a record of what the model read and who released the payment (What Is Supervised Delegation?).
- The pages reviewed do not describe a check on whether the supplier exists outside the form; Workday's request lists the fields a requester fills and the steps that follow, including "Create Settlement Bank Account" (Workday, 2026).
- The FBI's business email compromise guidance records 305,033 incidents and about $55.5 billion in exposed loss from October 2013 to December 2023, and directs businesses to "Use secondary channels and/or two-factor authentication to verify requests for changes in account information" (FBI IC3, Scam, 2024).
- Nacha's rule requires that "a fraudulent transaction detection system must, at a minimum, validate the account to be debited," and its supplemental requirement applies to the first use of an account number or a change to it (Nacha, 2021).
- Meta says Muse "checks with the person before sensitive actions like sending an email or making a purchase," a confirmation inside the run that leaves open whether the counterparty is real (Meta, 2026).
What does an agent read on a vendor request screen?
The request arrives as a package: a letterhead, a tax form and a bank letter, with an invoice attached and a request to be set up so the invoice can be paid. Every value the agent reads on the supplier request comes from the requester. Only 6 of the 15 AI agents reviewed document asking a person before completing a payment or purchase, so a first payment to a new vendor is not held by default (Do AI Agents Ask Before Making a Payment?).
Workday's Create Supplier Request asks for "DUNS Number If known, enter the supplier DUNS number," a tax authority form type with values that include "1042-S for a nonresident alien subject to U.S. income withholding," a TIN type, and a Justification field (Workday, 2026). Workday's Supplier Event business process configures the steps that follow, including "Create Settlement Bank Account" and "Create Workday Account for Supplier Contact," gated by the "Set Up: Supplier Administration domain in the Suppliers functional area" (Workday, 2026).
Suntory's questionnaire shows the same shape: the address splits into a Street field and a House number field for "the number portion of the address," and a VAT registration number is left blank by a supplier that has none (Suntory Global Spirits, 2025). Every field is filled by the party under suspicion, which makes the screen a record of a claim.
The model receives the company name, the address, the tax identifier and the account number as values on a page that looks like every other request, and nothing compares them with a registry, a contract or a previous payment (Can AI Work NetSuite Payables Without Bank Details?).
Why does a plausible vendor form not make the vendor real?
Because the form is content, and the agent's job is to process content. A model reading a supplier request has no independent knowledge of whether the company exists; it has the text in front of it and the permission to act. The FBI's glossary defines the pattern as a scam "targeting businesses or individuals working with suppliers and/or businesses regularly performing wire transfer payments" (FBI IC3, Report, 2024).
The research record explains why text can steer the work. OWASP describes the mechanism: "Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files" (OWASP, LLM01, 2025). The permission is the second half of the problem: OWASP's excessive agency entry describes "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM" (OWASP, LLM06, 2025).
A fraudulent request that asks for the ordinary steps is followed because it matches the task the agent was given. The approval the agent gives restates the request, and separation of duties applies to any acting identity, not only to people (What Stops an AI Agent From Changing Financial Records Without Authorization?).
What do the vendors themselves say?
Workday's documentation covers the record and who may create it. Approval routing follows submission, and reviewers "can populate more supplier details in additional fields that aren't available on the Create Supplier Request task" (Workday, 2026), a control on the workflow rather than on the counterparty.
Meta's Muse "checks with the person before sensitive actions like sending an email or making a purchase" (Meta, 2026). The same page says the agent cannot see stored passwords or payment methods but "can use credentials stored for it" (Meta, 2026). The check narrows what the agent does, and the person confirms the agent's account of the action.
Anthropic states the principle without a mechanism: "humans should retain control over how their goals are pursued, particularly before high-stakes decisions are made" (Anthropic, 2025).
Suntory's guide is the closest to a verification step: the company "uses a 3rd-party provider (Trust Pair) to validate supplier bank information" (Suntory Global Spirits, 2025). The check covers the account, not the company.
| Dimension | Workday, per its documentation | What a buyer should verify |
|---|---|---|
| Who may create the record | "Set Up: Supplier Administration" security domain | Which named people hold it, and whether the agent acts as one |
| What the request carries | DUNS number, tax form type, TIN type, justification | Whether any field is checked outside the request |
None of the pages reviewed describes a person confirming with the supplier.
What verification catches a fraudulent vendor before the first payment is approved?
The check that catches this one is a phone call to a number the request did not supply. The IC3 guidance directs businesses to "Use secondary channels and/or two-factor authentication to verify requests for changes in account information" (FBI IC3, Scam, 2024). A reply to the email, a portal message or a confirmation the agent sends inside its own run returns to the channel the fraud came through.
Account validation is the second check. Nacha's rule requires that "a fraudulent transaction detection system must, at a minimum, validate the account to be debited" (Nacha, 2021), and its supplemental requirement "applies to the first use of an account number, or changes to the account number" (Nacha, 2021). The rule governs WEB debits and prescribes no method, so for a vendor credit the equivalent step is a validation call on the new number plus the call to the vendor.
The approval has to sit outside the agent's own dialog. OWASP's community page describes an attack that "manipulates the content and presentation of approval dialogs, deceiving users into authorizing malicious operations" (OWASP, Lies in the Loop, 2025). A dialog the agent renders is content like any other. A named approver who made the call and saw the account is a different control.
On this record, the clerk calls the number on the existing contract, reaches the real vendor's controller, and learns that no such request was sent.
What should a finance team ask for in writing?
The questions that matter are about the screen and the approval, because those are the two places a fraudulent vendor gets through.
| Question | What a good answer looks like |
|---|---|
| What does the model receive from the vendor screen? | That the account and tax identifier are replaced with consistent tokens before any model reads the rendered screen, and that the mapping is held outside the model |
| Who approves the first payment to a new vendor? | A named person, not the agent, with the amount and the account in front of them |
| What record shows what the model read? | A per-run record of the screen as tokens, the action and the approver, exported to the customer's monitoring |
Each answer should name the person and the record that holds the approval. A permission slip is the reviewable form of the grant: service, resource, operation, destination, lifetime and approver on one page (What Is a Permission Slip for an AI Agent?).
The last question is what the agent may do without a person. If the answer includes creating a supplier record or preparing a payment, those controls have to exist before the agent is switched on, and the grant should say so, with the record kept where the organization can read it (What Is an AI Control Record?).
What does a governed environment change?
A governed environment is a control class that acts where the screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders such as ACCT_014 and TAX_014. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action, and a first payment to a new vendor is one. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.
The change is narrower than the fraud. The model still reads the vendor's name, address and justification, and a token does not tell it whether the company is real. The account and tax identifier are not in the model's context, so a stolen approval or an injected instruction collects placeholders. The callback remains a human check and the approval a human decision.
The limit is the rendered page. An agent that reads the vendor email through a mail API, loads a bank file with a script or works a payment system through a direct interface is outside this control class, and the gap between the invoice and the payment is where a SAP estate has to place its checks (Can AI Work SAP Payables Without Vendor Bank Details?).
What the record shows
A named person who makes a call the request did not route, a validation result on the new account, and a first payment that waits for both are the controls that answer the title. The agent can read the request, fill the form and prepare the payment; it cannot supply any of them, and its approval restates what it was given. On this record the callback separated a real supplier from a request that named one, and the paperwork would have looked the same to the model. Run one new-vendor request through the agent with test values, and compare the fields the model received with the fields the payment used; if the account was in the model's context before the callback, the exposure exists whether or not the vendor is real.
Methodology and limitations
This page rests on two FBI IC3 documents, a Nacha rule, three OWASP entries, vendor documentation from Workday, Suntory Global Spirits, Meta and Anthropic, and existing RedactSure research pages. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page. The FBI figures are reported exposed losses, and the Nacha rule governs WEB debits rather than vendor credits.
No product on this page was tested for it. The pages reviewed describe fields, approval routing, a bank validation service and a confirmation step; a control that replaces values on a vendor screen before a model reads it is not described in the pages reviewed. Vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, not an organization. Determinations about payment, tax and records requirements belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot on the organization's own screens.
Frequently asked questions
What stops an AI agent from approving a fraudulent vendor?
The controls are a person verifying the supplier through a channel the request did not supply, a validation of the new bank account, and a first payment that waits for that person's approval. The agent can read the request and prepare the record; it cannot confirm that the company exists, because the only evidence it has is the package someone sent. The callback belongs to someone who can compare the request with the contract already on file.
What does an agent read on a vendor request screen?
Every field the page renders. A supplier request asks for a legal name, an address split into a street and a house number, a tax identifier, a justification and, with electronic payment, the bank account. The requester wrote all of it. The model receives a description the requester supplied, not a verification of it, and no field compares the company with a registry or a prior payment.
Who should approve the first payment to a new vendor?
A named person outside the agent's run, with the account and the validation result in front of them. A first payment to a supplier nobody at the company has spoken to is a high-stakes decision, and the approval should be recorded with the account, the amount and the person's name. It should not be delegable to the agent that prepared the record, because that approval would restate the request and add no second check.
Does a confirmation prompt stop an agent from approving a fake vendor?
No. A confirmation is content the agent renders and reads like any other page, and approval dialogs can be manipulated so the person authorizes an operation they would refuse. The person is confirming the agent's summary of the request, not a fact the person checked. A prompt narrows what the agent may do; it does not establish that the supplier exists or that the account belongs to the company named.
Is bank account validation enough?
Not on its own. Validation establishes that the account is open and accepts entries, and it is applied to the first use of a number or a change to it. It does not establish that the account belongs to the company that sent the request. The validation service Suntory names checks the account and sits beside the callback, and a payment needs both because a fraudulent request can pass one and fail the other.
What record should a vendor approval leave?
One record per run that shows the screen the model received, the tokens or values on it, the action taken and the person who approved the payment. A vendor master audit trail shows which user account created the record, and it does not show what the model read before it acted. The two belong together, so an auditor can compare the account the model held with the account the payment used, and see the callback's date.
How RedactSure Keeps a Fake Vendor Out of the Payment Run
An agent that approves a new vendor has read only what the requester supplied, and the check that catches a fake sits outside its run. The FBI's business email compromise guidance records $55.5 billion in exposed loss and tells businesses to verify account changes by a secondary channel (FBI IC3, Scam, 2024).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the page renders the account number and tax identifier, and the model holds both. Inside the governed environment, the page renders ACCT_014 and TAX_014, and the real values resolve only at the payment a named approver releases after the callback.
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 fake vendor is caught by a person making a call the request did not route. Bring one new-vendor request and see, with test values, what the model reads on the form and who releases the first payment. Book a demo