Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Change a Payee in Your Bank Portal?
Yes, when the agent holds a live banking session, and the payee screen is where the change is typed. Put every payee addition and edit behind a named approver, and check what the model receives on that screen before an agent opens it.
A treasury analyst who gives an agent a seat in the business bank portal hands it the one screen where money can be redirected. Adding a payee or editing one is the step that comes before every wire: the account and routing numbers the portal stores are the account the payment reaches, and a change of a few digits sends a quarter's supplier payments to a different bank. The agent can do it. With a live session it opens the payee page and types into the same fields the analyst uses, so the question that matters is what the page shows the model at the moment of the change and which named person releases it and answers for the payment.
A new payee held for approval is the record: a payee record built from a vendor's remittance email, carrying a name, a bank name, an account number and a routing number, sitting in a queue until someone with the right permission clears it. Everything the approver decides rests on what that screen renders, and everything the run leaves behind rests on what the model read. The screen, the approval and the log decide the outcome, and a control that covers one of the three leaves the digits exposed at the other two.
Key findings
- For a payee change to be safe for an agent, the values on the payee screen would have to be replaced with consistent tokens before any model reads it, so the real digits resolve only at the destination a person approved (What Happened to the Screenshots ChatGPT Agent Kept in Your Chat History?).
- It would also require a named person approving each payee addition and edit, with no auto-approve setting standing in for it, and a record of the screen the model received (What Is Supervised Delegation?).
- The bank and finance pages reviewed here settle who may act on an account and leave open what an approver's screen renders, and First Citizens' guide says an approver "is able to approve transactions that others created" without describing that screen (First Citizens Bank, 2024).
- Intuit's answer for QuickBooks Online sends the clerk to "Set up Bank Transfers" on the payee line and states the requirement: "You'll need the account number for the vendor" (Intuit, 2021).
- Chase's overview gives an administrator "varying levels of access" and the option to "Require a second approver on transactions with Dual Control", permissions on an account, not a limit on what a model reads (Chase, 2025).
What does the model receive when the agent opens the payee screen?
The record is a new payee held for approval. The agent starts from the vendor's remittance email, opens the portal's payee administration page, and types the name, the bank, the account number and the routing number into the form. The account number is the value a fraudulent change replaces.
The payee list is not a side screen. On NetSuite's Pay Single Vendor form the instruction is to "select the payee you want to pay", which makes the stored payee the source of the payment the form builds (Oracle, NetSuite, 2026). Change the payee record and the next payment follows the new account.
What the model holds is the rendered page, not a database row. The page prints the account number in full because the clerk who checks a payment reads it, and no marker on the form tells the model which values the task needs. A password manager can keep the password itself away from the model and still leave the session open: 1Password's post on browser agents states that "the AI agent and underlying LLM never need to see nor handle the credentials" (Can a Browser Agent See My Password When It Logs In?). An agent that can open the payee page can change the payee, and the bank's page cannot tell the agent from the analyst whose session it holds.
Who approves a payee change, and what does the approval cover?
Arcade's question about agent authorization is the right one, "Can this agent, acting for this user, perform this action on this resource?", though the answer it asks for is a permission, not a description of what the model read before it acted (Arcade, 2025). First Citizens' Commercial Advantage guide defines the model: "Dual approval, also referred to as dual authorization, is one of several security protocols in place", and names the settings that undo it, since "A user can approve their own transaction" is the Approve Own permission and Auto Approve moves a new transaction straight through (First Citizens Bank, 2024). Only 1 of the 15 AI agents reviewed documents asking a person by default before every consequential action, and 5 document a per-action record an administrator can export, the bar a payee change has to clear (Do AI Agents Ask Before Making a Payment?).
The approval settles who released the transaction in front of them, not who built the payee record behind it. Where a payee addition is maintenance rather than a payment, the wire approval rule may not cover it, and the pages reviewed do not describe a bank that requires a second approver for a payee addition. Agents act unprompted: in a SailPoint survey of 353 IT professionals, 16% of organizations said an agent had ordered something inappropriately (Does an AI Agent Need Approval Before Submitting a Transaction?).
Chase's overview shows what the record will say afterwards: an administrator can "Search for activity by user, accounts and transaction types", which files the change against the user whose session made it (Chase, 2025). The agent inside that session is not a user in the search.
What do the vendors themselves say?
Chase documents the permission side of the record: "Assign your employees varying levels of access", "Set daily transaction limits and approval thresholds" and "Require a second approver on transactions with Dual Control" (Chase, 2025). First Citizens documents the approval role: to "create and approve a transaction, two parties are needed", and its Approve permission lets a user approve what others created (First Citizens Bank, 2024).
| Dimension | What the vendor page documents | What a buyer should verify |
|---|---|---|
| Who may act | Chase: "Assign your employees varying levels of access" (Chase, 2025) | Whether the agent has its own identity or borrows the analyst's session |
| Second approval | First Citizens Bank: "create and approve a transaction, two parties are needed" (First Citizens Bank, 2024) | Whether a payee addition falls under the rule |
| Payee setup | Intuit: "You'll need the account number for the vendor" (Intuit, 2021) | Whether the page draws a token instead of the digits |
Whether the account number on the rendered payee screen is replaced before a model reads it is not described in the pages reviewed. Each vendor governs an actor, an account or a payment, and the screen the actor works sits outside the description. That is the boundary to test, because the payee screen is where actor and value meet.
What does a new payee held for approval leave in the record?
Oracle's insurance help records the payment in statuses a supervisor can act on: "On-Hold Limit" is the status when the authority limit check fails, and "Approved Limit" is the status after a supervisor approves (Oracle, Siebel, 2026). The status says where the payment stands, not what the approver read before clearing it.
The approver's side has its own failure mode. Automation bias, "the tendency to over-rely on automation", has been measured across fields, and a queue of payee changes is the setting where a reviewer trusts the summary line (Goddard et al., 2012). The summary line is written by the model, so the reviewer's trust lands on the agent's own account of what it did.
A record that answers the question carries three things: the payee screen as it reached the model, the approval with a person's name on it, and the change the agent made (What Is an AI Control Record?). Most portals carry the third and a user identifier. Verifying the request is the other half: a payee change usually arrives as an email or a call, and the regulator's guidance asks for "authentication factors that can withstand AI-manipulated deepfakes" (New York State Department of Financial Services, 2024). That factor is a person on a known channel, not a reply to the message that requested the change.
What can a hijacked agent do on a payee screen?
Payee work starts with content the agent did not write and cannot verify. The account details arrive in a vendor email, a supplier portal message or a PDF, and the model that reads them is the same model that fills the form. Design work on this problem states the goal plainly: "the untrusted data retrieved by the LLM can never impact the program flow" (Debenedetti et al., 2025).
The model's own refusal is not that boundary. As MIT Technology Review puts it, "the mechanisms of refusal are probabilistic, they're never likely to be all that reliable", and determined attackers have already broken through (MIT Technology Review, 2026). Confirmation prompts and site settings narrow what the agent may do; they do not change what it read on the way there.
Once the digits are in the model's context, the page is an exit as well as an entrance. EchoLeak showed a client fetching an external image URL an attacker supplied, which is why a rendered page can carry data out through a field or a link (Can an AI Agent Exfiltrate Data Through a Markdown Image or URL?). An agent that read the account number can repeat it, and an agent that can add a payee can point the next payment at any account, including one the vendor never named.
What does a governed environment change?
A governed environment changes the object the agent works on. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers.The payee screen is rendered with consistent tokens in place of the values a person would see: the payee name becomes VENDOR_014 and the account number becomes ACCT_014. The real digits resolve only at the approved destination, at the moment of an approved action, so the payment file is built with the account the bank actually holds.
The approval moves with the action. Adding a payee and editing a payee are each an action that a named person releases, and the release is recorded against that person rather than against the session. A setting that auto-approves a class of transaction does not satisfy this, because the agent's change and the approver's decision have to be two events with a name between them.
The record closes the loop. What the model received, the action it took and the person who approved it are exported to the organization's own monitoring, so the reviewer who clears the next payee change reads the screen the model saw. Layered security is the established model for high risk electronic transactions, with different controls at different points so a weakness in one is compensated for by another (How to secure AI agents against financial fraud?).
What the record shows
The control that decides this question sits between the payee screen and the model, and again at the release: whether the account and routing numbers are replaced before the model reads them, and which named person approves the addition or edit. The bank pages reviewed here document the second half: dual approval, approval thresholds and activity searches on the account and the transaction. The agent's reading is the half they leave open, and the payee record is where it turns into a payment. A treasury team can check this on one record: create a new payee in a test company, name every field the payee page renders, list who can approve the change and under which rule, then compare that list with what the payment file needs.
Methodology and limitations
This page rests on bank and finance documentation from Chase, First Citizens Bank, Intuit and Oracle, New York State regulator guidance, a peer-reviewed review of automation bias, a preprint on prompt injection defense and an MIT Technology Review analysis, with existing RedactSure pages. Public documentation read in full gives a sound view of where each product applies its control. Pages were read between October 20, 2026 and October 22, 2026, and each Sources line carries its date.
The products are described from their public documentation and none was tested for this page; "not described" means the pages reviewed, and features change, so the page carries its date. The example describes a record type, a new payee in an approval queue, 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
Can an AI agent change a payee in a bank portal?
Yes, when it holds a live session in the portal. The agent opens the payee page and types the fields the analyst types, and the bank's page treats it as the signed-in user. The controls that decide the outcome sit on the payee record: who may create or modify it and who approves the change by name. Check what the page renders to the model before you grant the session, because the account number is on that screen.
Does dual approval stop an agent from approving a new payee?
Only where the payee change is a transaction the rule covers. First Citizens' guide requires two parties to create and approve a transaction, and Chase offers a second approver under dual control. A payee addition is often maintenance rather than a payment, and the pages reviewed do not state which category it falls into. Ask for the rule in writing, naming payee creation and payee edits.
What does the approver see when a payee change is waiting?
The portal's summary of the change, which is usually the fields the agent filled and the status of the request. Oracle's insurance help shows the pattern: a limit shortfall becomes an Inbox item with a status such as On-Hold Limit, and the supervisor sees the item, not the adjuster's screen. Whether the approver's view renders the full account number is a question for the bank, since the pages reviewed do not answer it.
What record shows who approved a payee change?
The portal's activity and audit views, filtered by user, account and transaction type. Chase's overview offers that search, and Oracle's payment record carries a status and the supervisor's approval. Neither view shows what the model read or which screen the approver saw. A record that answers both has to be assembled from the render layer and the approval, not the portal alone.
Does a confirmation or a callback show what the approver read?
A confirmation narrows what the agent may do and leaves the account number in its context, so it does not answer the question. A callback to the vendor verifies the requester, which is the control the regulator points at when it warns about AI-manipulated deepfakes. Neither replaces the two structural controls: values replaced before the model reads them, and a named approver releasing the change. Treat the confirmation as one layer among several.
What should a treasury team ask in writing about the payee screen?
Which page the agent opens, which fields that page renders, and whether the account and routing numbers are substituted before the model reads them. Then who approves each payee addition and edit by name, what rule covers it, what record of the run is exported and how a change request is verified. The answers should come from the bank's documentation and the contract, not a security page that describes access levels.
How RedactSure Keeps an Agent Out of the Payee Record
A payee change looks like maintenance work and ends with money leaving the account, and every control here stops at who may act. First Citizens' guide requires two parties to "create and approve a transaction" and leaves the account digits on the screen the requester works.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the payee administration page and types the vendor's account and routing numbers into the form, so the digits sit in the transcript. Inside: the page draws VENDOR_014 and ACCT_014 before any model reads it, the approval names a treasury manager, and the real account resolves only at the payment that person releases.
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 payee change that moves money should never be a single agent action. Bring one payee your team would add and see, with test values, what the model reads, who approves the change and what record remains. Book a demo