Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Stops an AI Agent From Changing a Direct Deposit to an Attacker's Account?
A named approver on every direct deposit change and a destination policy that keeps the real bank details out of the agent's reach until that person signs off. The agent cannot be the approver, so ask what the model reads on the payment elections screen and who holds the account values.
An email reaches the payroll mailbox from an address that looks like an employee's and asks for a new bank account to be used this cycle. A person treats it as a fraud check: call the employee on a number already on file, confirm the account, and write down who approved the change. An agent that reads the mailbox and works the payroll console receives the same message as an instruction from a plausible sender, on a page it may operate. The FBI's payroll diversion notice describes the attack, including the rules that keep the employee from seeing the alert (FBI IC3, 2018).
The stake is a paycheck that can repeat. A redirected deposit keeps paying an attacker every cycle until someone compares it against the employee's own bank record, and the employee is often the last to know.
The vendor pages that govern the work answer a different question. They describe which role may change a payment election, which security domain the change requires, and what verification a new account gets. They do not describe what the model receives when the page opens, and the fields that hold the routing and account numbers are the fields the change writes to. The worked case is one spoofed employee email asking a payroll team for a new bank account.
Key findings
- For an agent to change a direct deposit without handing an attacker an account, the routing and account values on the payment elections page would have to be replaced with consistent tokens before the model reads the screen, with the real numbers released only at the destination a named person approved (What Is Supervised Delegation?).
- It would also require a named person approving each direct deposit change outside the agent's reach, and a record of what the model received and who signed the change (What Is an AI Control Record?).
- None of the payroll pages reviewed describes what the model receives when a payment elections page opens; each governs which human role may change a deposit and stops at the bank fields it renders (Workday, 2026).
- ADP's Direct Deposit API guide labels the routing field "Indicates the Routing Number to which the Direct Deposit applies" and defines two role codes, Practitioner and Employee (ADP, 2026).
- Workday's payment elections page says that when bank details change, "Workday automatically updates all payment elections with the new account information," and its access is a security domain, not an approval (Workday, 2026).
- The FBI's payroll diversion notice says attackers add rules "preventing the employee from receiving alerts regarding direct deposit changes," after which "Direct deposits are then changed and redirected to an account controlled by the cybercriminal" (FBI IC3, 2018).
What does an agent read when a spoofed email asks for a bank change?
The email is the cheap part of the attack. It arrives from a lookalike domain, gives the last four digits of the account on file and the new routing and account number, and asks for the change before the next run. The FBI's notice describes the pattern: criminals target employees "through phishing emails designed to capture an employee's login credentials," then work inside the payroll account (FBI IC3, 2018). The version aimed at an agent needs no stolen password if the agent already holds a session.
The work is a short sequence on the payroll console. Workday's administrator guide lists "Add or upload initial payment elections" and "Update existing payment elections for the person," and notes that a second account can split payments (Workday, 2026). The agent opens the employee's page, adds an account, sets the distribution and saves.
What the model receives is both sides of the fraud at once: the attacker's numbers in the email body, and the employee's existing bank account on the page. A computer-use agent reads the rendered page as an image, and what enters its context is everything visible (What Does an AI Agent See in a Screenshot?). Nothing on the page marks the request as unverified, because the page holds the deposit and is silent about who asked.
Why does the model treat the email as an instruction?
Because the message arrives on the channel the agent was told to work from, and a model reading that channel has no separate test for a request from outside the company. OWASP names the mechanism: "Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files" (OWASP, LLM01, 2025). A mailbox is such a source, and the agent does not need to be jailbroken; it needs to do its job with the text it was given.
The measured record is not reassuring. A benchmark of web agents found that agents begin following injections in up to 86% of cases, though "even state-of-the-art agents often struggle to fully complete the attacker goals" (Evtimov et al., 2025). A bank change is a small goal: two fields and a save.
OWASP's excessive agency entry describes what the agent holds: "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM" (OWASP, LLM06, 2025). The payroll console is the permission, and the same access that lists an election can change one. Instruction-following is not the boundary; agents carry out permitted actions at the wrong moment, including one that deleted a production database during a declared freeze (What Stops an AI Agent From Making Unauthorized Changes?). The boundary belongs where the action completes.
What do the vendors themselves say?
ADP's Direct Deposit API guide describes the routing field as "Indicates the Routing Number to which the Direct Deposit applies" and the account field as "Indicates the Account Number to which the Direct Deposit applies," and defines two role codes, Practitioner and Employee (ADP, 2026). It is a document about fields and roles an integration uses, and it contains nothing about approval limits for changing a deposit.
Workday's administrator guide gates the page with security domains, "Manage: Payment Election domain in the Expenses functional area" and "Worker Data: Payroll (Payment Elections) domain in the Core Payroll functional area," and says that when bank details change, "Workday automatically updates all payment elections with the new account information" (Workday, 2026). It was last updated in 2023 and describes no approval step before an administrator changes someone's bank account; a domain decides which administrator may act, not whether a second person agrees.
Gusto puts the change on the employee's side. Employees can "add up to 5 bank accounts and split pay between them," and a change requires them to "Complete the security check (2-step code and confirm current bank)" (Gusto, 2026). The check is on the account and the person, not on the request, and the page does not describe what a payroll administrator's screen shows a model.
| Control the page describes | What the vendor documents | What it leaves open |
|---|---|---|
| Who may change the deposit | ADP role codes for an integration; Workday security domains; Gusto's 2-step check for the employee | Which human may act, not what a model reads when the page opens |
| What the change writes | ADP's routing and account number fields; Workday updating every election with the new account | The bank values are the values on the screen |
| Approval before the change | ADP's guide contains nothing about approval limits; Workday describes no approval step | A second person's sign-off is left to the organization |
Read together, the pages answer the access question and leave the exposure question untouched. An organization can name the administrator who may change a deposit. It cannot point to a sentence that says what that administrator's model saw.
Who approves a direct deposit change, and who cannot?
The approval has to belong to a person who is not the agent and cannot be reached through the channel that made the request. OpenAI's governance paper calls human approval "a standard way to limit egregious failures" and asks that "at least one human entity is accountable for every uncompensated direct harm" (Shavit et al., 2023).
The FBI's business email compromise guidance supplies the check: "Use secondary channels and/or two-factor authentication to verify requests for changes in account information" (FBI IC3, 2024). The secondary channel is the point. A reply to the email, or a confirmation the agent sends into the same mailbox, verifies nothing.
The agent cannot be the approver. An approval it gives is a restatement of the message it read, and a confirmation dialog it clicks is a step inside its own run. The control that works is a named person outside the model who calls the employee on a number already on file and signs the change. Separation of duties applies to any acting identity, not only human users, so the agent can be a party to the change but not both parties (What Stops an AI Agent From Changing Financial Records Without Authorization?).
ADP, Workday and Gusto were not among the 15 AI agents reviewed, and only 1 of those documents asking a person by default before every consequential action (Do AI Agents Ask Before Making a Payment?).
An approval is only as good as the record beside it, and a system of record answers neither question an agent raises: what did the model see, and who answered for what it did (What Is an AI Control Record?).
What does a governed environment change?
The control class sits where the page is drawn. Values chosen by policy are replaced with consistent tokens for the run before any model reads the screen, so the agent works with ACCT_014 and ROUTING_014 rather than the employee's bank details. Real values resolve only at an approved destination, at the moment a named person approves the action, and every screen, action and approval goes to an exported record.
On this record the difference is large. Before, the agent holds the employee's existing account, the new account from the email, and every other account the console renders on the way to the page. After, the page draws tokens for the account on file, the change carries a token rather than a number, and the real values resolve only when the payroll system saves an action an approver released (What Is an Approved Destination for AI Agent Output?). A study of browsing agents reports findings that "include prompt injection, domain validation bypass, and credential exfiltration," which puts the destination check on an attacker's list (How Do I Control Where a Browser Agent Can Submit Data?).
Its limit is the message. A governed browser environment covers what the agent reads and does on a rendered page; an agent that reads the same email through a mail API or a local file is outside it, and there the approver is the only control left. Where the mailbox is a rendered page, its values can be tokenized by the same policy. The approver, not the render, stops a wrong account from being written.
What the record shows
The control that answers the title is a person and a policy: a named approver outside the agent's reach who confirms the new account with the employee through a channel the email did not supply, and a render-layer policy that keeps the real bank details off the model's screen until that approval exists. The payroll pages reviewed document who may change a deposit and what the change writes, and none documents an approval by a second person before it takes effect. The scam needs only what is missing: a routine page and an internal-looking message. A payroll lead can test the setup by pointing a test request at a payment elections page and writing down what the model received, whether the change could finish with no second person, and which record holds the approver's name.
Methodology and limitations
Public documentation read in full gives a sound view of where each product applies its control: two payroll vendor guides, one payroll API guide, two FBI notices, two OWASP entries, a governance whitepaper and a benchmark paper. Vendor pages were read as of October 22, 2026.
Products here are described from documentation and none was tested. "Not described" means 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, a spoofed employee email, not an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
What stops an AI agent from changing a direct deposit to an attacker's account?
A named person approving the change outside the agent's reach, and a policy that keeps the real account values off the model's screen. The payroll pages reviewed set who may change a deposit and what the change writes; none sets an approval by a second person before it takes effect. The agent can read a spoofed email and prepare the change, and it still cannot complete it without someone who confirms the new account with the employee.
Who should approve a direct deposit change?
Someone who can reach the employee by a channel the request did not supply: a phone number already on file, not the reply address in the email. The approval belongs to that person, by name, in the record, and the agent cannot supply it, because a confirmation the agent generates only restates the message it read. Pick the approver before the agent runs, not after it asks.
What does the agent see on a payment elections screen?
The rendered page: the employee's name, the bank account and routing numbers on file, the distribution rows and the save control. An administrator guide documents the security domains that gate the page and the automatic update to every election when the account changes, and says nothing about substituting those values before a model reads them (Workday, 2026). A person sees a payroll record, and the model receives its text.
Does a two-step security check stop an agent from changing the bank account?
No. Gusto's check asks the employee for a 2-step code and confirmation of the current bank, which verifies the person making the change (Gusto, 2026). An agent working inside that person's session can be handed the code, and the check still says nothing about what the model read. It narrows who can act. It does not put a second person between the request and the change.
What record would prove who changed the deposit?
A record that names the screen the model received, the tokens or values on it, the action taken, and the person who approved it. The payroll systems' logs record the account that saved the election, which answers who acted and not what the model saw. After a diversion, the question is what the agent read and who released the change, and only a record built for that answers it.
Can a prompt injection reach a payroll agent through an email?
Yes. OWASP describes indirect prompt injection as input an LLM accepts from external sources such as websites or files, and a mailbox is such a source (OWASP, LLM01, 2025). A web-agent benchmark found agents begin following injections in up to 86% of cases (Evtimov et al., 2025). The useful question is what the injection collects when it succeeds, which is decided by what the model is shown and what it is allowed to write.
How RedactSure Keeps a Spoofed Email From Redirecting a Paycheck
A payroll change is one message away from a paycheck, and the controls reviewed above govern who may act, not what the model reads. The FBI's notice records attackers adding rules "preventing the employee from receiving alerts regarding direct deposit changes" (FBI IC3, 2018).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent reads the spoofed email and the page, holding the employee's account and routing numbers. Inside the governed environment the page renders ACCT_014 and ROUTING_014, the change carries a token, and the real values resolve only at the save a named approver releases, with the record naming the screen and the approver.
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 direct deposit page is where a spoofed email becomes a redirected paycheck. Bring one payroll change and see, with test values, what the model reads, who releases the change and what the record holds. Book a demo