Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Who Approves an AI Agent's Wire Transfer?
Whoever approves a colleague's wire approves the agent's: a named approver at the release, never the agent, and where dual control applies, not the party that prepared the instruction. Ask for that person's name from the bank's approval rights and for the record of what the model read before the release.
A wire leaves a business account once, to one account number, and a controller signs for it. When an agent prepares that wire, the signature stays with a person while the reading behind it moves to a model, so the question is which person signs and what is in front of them when they do. The controller who approves wires by hand is being asked to let an agent draft them.
An approval that lands on the agent's plan confirms an intention to pay. An approval that lands on the release confirms the account the money reaches, and the account number sits on the screen the agent read while it built the instruction. Banks already run the control that fits: dual approval, an approver's limit, a second signature on a transaction another user created, and those pages describe a control between people. Whether an agent counts as one of the people, and what its model was shown before the first signature, is what a buyer has to check.
The record is a wire with dual approval: an instruction prepared in a business bank portal, an approver with a transaction limit, and the second approver the bank's own settings require.
Key findings
- For the wire to be releasable, the account and routing numbers on the screen would have to be replaced with consistent tokens before the model reads them, so the real destination first appears at the release a person approves (What Is Supervised Delegation?).
- It would also require a named approver drawn from the bank's approval rights, acting on the release, and an AI Control Record of what the model read before that approval (What Is an AI Control Record?).
- None of the bank pages reviewed states who approves when an agent prepared the instruction, or what the model read on the form (Chase, Overview, 2025).
- Chase's overview documents "Require a second approver on transactions with Dual Control" and "Set daily transaction limits and approval thresholds", controls on people and amounts that say nothing about the model (Chase, Overview, 2025).
- First Citizens' quick reference separates the right to approve from the right to create: a user with Approve "is able to approve transactions that others created", and the Approve Own permission records that "A user can approve their own transaction." (First Citizens, 2024).
- Plaid's documentation confines tokenized account numbers to one field, "Only the numbers.ach[].account field can be set as a TAN" and "TANs are only valid for the ACH and RTP payment rails", so a wire instruction carries the account the model read (Plaid, 2026).
Who approves the wire once an agent has prepared it?
A wire starts as an instruction in a business bank portal. An agent reads the invoice and the vendor record, fills the payee, the amount and the account, and leaves the instruction in the approval queue. From there the bank's rules take over. Only 6 of the 15 AI agents reviewed document asking a person before completing a payment or purchase, which is the check a wire release needs from a named approver (Do AI Agents Ask Before Making a Payment?).
First Citizens' guide describes the release in permissions rather than job titles: to "create and approve a transaction, two parties are needed", and a user with Approve "is able to approve transactions that others created" (First Citizens, 2024). Approve Own lets a user approve a transaction they created, and Auto Approve moves a new transaction straight from Entered to Approved.
An agent can be the preparer and never the approver. It fills the instruction, the approval belongs to a person whose right the bank grants, and where dual control applies that person is not the account the agent prepared under. The prompt injection design research recommends the same shape: 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), and a wire is one of those actions.
What the bank's pages settle is the signature. What they leave open is the reading behind it, and the separation of duties the guide enforces between preparer and approver has no place for a model that drafted it (Do Coding Agents Break Separation of Duties?).
What does the agent read on the wire screen before anyone signs?
The screen is the bank's payment form: payee, amount, memo, account number and routing number. Chase's Connect guide lists wires among the outgoing services a company grants and makes approval a per-account entitlement, "Approve pending transactions within an account for that user" (Chase, Connect, 2025). The entitlement decides who may release, not what the form shows the agent that fills it.
Tokenization exists on narrow terms. Plaid's Auth documentation states that "Only the numbers.ach[].account field can be set as a TAN" and that "TANs are only valid for the ACH and RTP payment rails" (Plaid, 2026). A wire runs on neither rail, so an agent preparing one reads the account number itself before any approver sees it.
That is the asymmetry the approval chain hides: the bank's control governs the release of a value the model has already seen, and the real value belongs at the approved destination (What Is an Approved Destination for AI Agent Output?). Masking the value on the screens the agent reads is a separate job, and the invoice case has the same shape (Is It Safe to Let Dia Pay a Vendor Invoice?).
A payables estate holds one payment across three screens, a capture tool, an ERP and a bank portal, and an approval that watches one has watched a third of the work (Can AI Work SAP Payables Without Vendor Bank Details?).
What do the vendors themselves say?
The pages reviewed answer the approval question in the vocabulary of user rights, and each stops where a model drafted the instruction.
Chase's overview puts the controls in a short list: a company can "Control which accounts employees can see, set limits and require dual approvals for enhanced security" and "Require a second approver on transactions with Dual Control" (Chase, Overview, 2025).
The Connect guide is specific about who holds the right: approval comes from "Approve pending transactions within an account for that user", and the guide's transaction dual control excepts transfers between Chase accounts, loan advances and loan payments (Chase, Connect, 2025). They are entitlements on a user, not a description of the approval screen.
First Citizens states the pair plainly: the guide gives each permission's meaning, and it never shows the screens' field layout, so it says who may approve and not what an approver or an agent sees (First Citizens, 2024).
1Password is the one page here that addresses an agent directly. In its design for browser agents, "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). That approval is of access, and the page does not describe who approves the payment.
If the bank's dual control is in place, who answers for what the model read?
The approval does not name the person who answers for the agent's work. The bank's record is built around users: the activity search returns transactions by user, account and type, and an agent working through a user's entitlement appears under that user. Visibility research proposes "agent identifiers, real-time monitoring, and activity logging", and the first is what a user-based search cannot supply (Chan et al., 2024).
The fraud that approval defends against is usually a changed account. The FBI's public service announcement on business email compromise reports "Domestic and international incidents: 305,033" and "Domestic and international exposed dollar loss: $55,499,915,582" for October 2013 to December 2023, figures the page derives from complaints and filings rather than confirmed losses (FBI IC3, 2024). Its prevention advice asks for a second channel rather than a second reader: "Use secondary channels and/or two-factor authentication to verify requests" for changes in account information (FBI IC3, 2024).
Dual control puts another person on the release, and that person did not read the screen the agent read. A second reader in the same portal reviews the same render, while a second channel reaches the payee and asks whether the account is theirs. The bank documents the second reader, and the fraud guidance recommends the second channel.
What should a treasury team ask for in writing?
The answers are not on the pages. The 2025 AI Agent Index, which documents 30 deployed agents, found that "most developers share little information about safety, evaluations, and societal impacts." (Staufer et al., 2026). A team that waits for documentation to volunteer an approval design will wait past the pilot, so the questions belong in the contract.
Four questions carry the argument: - Which named person holds the approval right on the account the agent draws on, and does the agent's account hold Approve, Approve Own or Auto Approve? - What does the model receive from the rendered payment screen, field by field, and are the account and routing numbers replaced with consistent tokens before it reads them? - What does the record hold: the approvers' names, the amount, the account the money reached, and the agent's context on that run? - Which of these answers is enforced by the bank, which by the agent's environment, and which by a written procedure?
The last question keeps the others honest. The Columbia DAPLab's page states that "trustworthy agent automation cannot be solved at a single layer of the stack" (DAPLab, 2026). A bank can document the signature and cannot document the reading, and a tool can document the reading without holding the account. A treasury team needs both answers in one file before it lets an agent near a wire.
What does a governed environment change?
A governed environment changes which values reach the model, not who approves. The page renders as it always does, and the values chosen by policy are replaced at the render layer with consistent tokens before any model reads the screen. The account becomes ACCT_001 and the routing number ROUTING_001 for the whole run, so the agent fills the payment form with the values it read on the invoice. Real values resolve only at the approved destination, at the moment of an approved action, so the digits reach the release and never the transcript.
The approval chain the bank describes stays where it is. The approver still signs, the limit and the dual control still apply, and what changes is what the approver is looking at: the same tokens the agent saw, with the real account appearing only on the release. Every screen as tokens, every action and every approval with a name lands in a record that exports to the organization's own monitoring.
The scope is the rendered page, so an agent that reaches the bank through an API call, a terminal or an MCP tool is outside it, and an estate with three screens needs the control on each one. The comparison with 1Password sets out where credential custody stops relative to the page an agent reads (RedactSure vs 1Password).
What the record shows
The control that answers the title is an approval attached to a released value: a named approver with a limit who is not the party that prepared the instruction, and a record of what the model read before the approval. The bank pages describe that chain for instructions people create, and for an agent's instruction they leave the reading open. The approval reviews a destination the model already held. A tokenized account number exists for one field on two rails, so the wire's real account travels through the agent's context into the approval queue. One payment is enough for the test: prepare a wire with an agent, put the bank's activity record beside the tool's context for that run, and if the account appears in both, keeping it out belongs on the screen where it rendered.
Methodology and limitations
This page rests on bank documentation read in full, a payment-rail API reference, an FBI public service announcement, three research preprints and a laboratory page. Chase's overview sends a reader to footnotes and videos for the mechanics of dual control, and First Citizens' guide gives each permission's meaning without showing the form. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 16, 2026 and October 22, 2026, and each Sources line carries the date for its page.
No product on this page was tested, and no bank or vendor was interviewed. "Not described in the pages reviewed" means the recorded facts for that page do not contain it, not that a product fails to do it. Vendor features change, and the page carries its date. The example describes a record type, a wire with dual approval, not an organization. Every product named here is described from its own documentation. RedactSure is deploying now with enterprise and government customers. Determinations belong to counsel, assessors and the organization's own security and compliance officers.
Frequently asked questions
Who approves an AI agent's wire transfer?
A person does, inside the bank's own chain: an approver with a transaction limit who, where dual control applies, is not the account the agent prepared under. The agent prepares the instruction and holds no approval right. First Citizens' guide puts the pair on two parties: to "create and approve a transaction, two parties are needed" (First Citizens, 2024). Check that the account the agent uses carries no Approve, Approve Own or Auto Approve permission.
Can an agent be the second approver on a wire?
Not in the model the bank pages describe. Approval is a right attached to a user and exercised by a person, and credential custody makes the same split: 1Password keeps the agent and the language model from seeing the credential and injects it only when a person approves the access. That approval covers access, not the payment. A tool that gives an agent an approval right has removed the control rather than automated it.
What does the model see while it prepares the wire?
The model sees the payment form as the bank renders it: payee, amount, memo, account number and routing number. The bank's Connect guide puts wires among the outgoing services a company grants and makes approval a per-account entitlement, which decides who releases and not what the form shows. Plaid's documentation confines tokenized account numbers to one field on two rails, so a wire carries the real digits (Plaid, 2026).
Does dual control at the bank cover the agent's wire?
It covers the release and not the reading. The approver signs, and reviews an instruction the agent drafted from a screen that carried the account. The FBI's advice for changes in account information is a second channel and a second factor, not a second reader of the same screen. A second approver in the same portal checks the same render; a call to the payee checks the account itself.
What should the record show after the wire goes?
The record should show the approvers' names, the amount, the account the money reached, and the model's context for that run. The bank's activity search ties the payment to a user, an account and a transaction type. The agent's identity and what it read are the part a team adds to the record. Without them, the file shows a payment a person released and nothing about the reading.
Which permission should a treasury team check first?
Approve Own first, then Auto Approve. First Citizens' guide defines Approve Own as the permission under which a user can approve a transaction they created, and Auto Approve as the setting that moves a new transaction straight from Entered to Approved. Either one leaves a route where a single party completes both halves of the pair. Read the settings for the account the agent draws on, then for the approvers above it.
How RedactSure Keeps the Wire's Account Number Out of the Model
Dual control reviews a wire after the agent has drafted it, so the approver signs a destination the model already read.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent fills the payment form and the model receives the account and routing number. Inside the governed environment the form renders as ACCT_001 and ROUTING_001, the approver reads those tokens, and the real account resolves only at the release.
RedactSure is deploying now with enterprise and government customers. Chase's overview requires a second approver on transactions with Dual Control, the signature the token resolves at.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A second signature on a wire means little if the model read the account first. Bring one payment your team prepares and see, with test values, what the agent reads and where the real account lands. Book a demo