Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is It Safe to Let an AI Agent Wire Money?
No: a released wire cannot be recalled, and the bank portal renders the beneficiary account, the balance and the release control to whatever model reads the screen. Check what the model receives on the payment page and which named person can release the wire before an agent prepares one.
A $48,000 wire leaves a bank account once. The team that sends it works across three screens: the vendor record in the ERP, the invoice that supports the payment, and the bank portal where the beneficiary and the amount are entered and released. An agent can work all three. It reads the invoice, matches the vendor, fills the payment form and waits while a person checks the total, and the appeal of handing it the task is easy to see in a busy week.
What the run leaves behind is the question. The bank portal draws the beneficiary account and routing numbers, the available balance, the prior payments and the release control, and a model working the page receives what the page draws. A pause before the transfer is submitted arrives after that reading. A finance lead weighing the task has to separate where the agent may go from what it reads on arrival, because a wire has no recall once it leaves and the beneficiary is the value an attacker would change. The record below is one $48,000 wire, from the ERP vendor record to the bank's confirmation, and the checks a team can run before an agent prepares one.
Key findings
- For an agent to be safe on a wire, the beneficiary account and the balance would have to be replaced with consistent tokens before the model reads the screen, with the real digits resolving only at the destination a person released (What Is Render-Layer Tokenization?).
- It would also require a named person approving the release, the amount and the beneficiary, and a record of what the model received on each screen of the run (What Is Supervised Delegation?).
- None of the vendor pages reviewed describes the render as the control point: they describe a pause, a confirmation and a do-not-use list, which govern where the agent goes and when it must stop, not what the bank portal puts in front of the model (OpenAI, 2026; Microsoft, 2026).
- Chase's Connect guide makes approval a per-account right and its transaction dual control requires another user to approve all transactions except transfers between Chase accounts, a control over who releases a wire rather than over what the approver's screen shows (Chase, 2026).
- OpenAI's page says the agent "will pause to ensure you're watching it take actions on specific sensitive sites such as financial institutions", a checkpoint before the action and not a filter on the page (OpenAI, 2026).
- Ramp says a team can "Give each virtual card its own limit by transaction, day, or month", the ceiling a wire does not carry once it is released (Ramp, 2026).
What does an agent read on the way to a $48,000 wire?
The record is one wire for $48,000: a vendor record in the ERP with the beneficiary's bank account and remittance email, a matched invoice, and a bank portal page where the payee and amount are entered and released. Four values would do the task: the payee, the amount, the invoice reference and the due date. The screens carry more than four.
NetSuite's help states the constraint plainly: "If a vendor record does not have a bank account, you can only pay vendor bills by check" (NetSuite, Vendors, 2026). The bank account is part of the record the agent opens, beside the tax identifier and the payment terms, and the ACH path needs the Edit level on the required permissions.
On the bank side the portal draws the payee list, the account and routing digits, the balance and the approval status. A person reads the amount and the payee and treats the rest as context; the model receives the page as rendered, so the context arrives with the values. Research on web agents describes them as "prone to inadvertent use of unnecessary sensitive information", the same point from the other direction: a narrow task does not narrow what the agent reads (Zharmagambetov et al., 2025).
The payable screens are set out in Can AI Work NetSuite Payables Without Bank Details?, and the value that matters is the account the wire will land in.
What makes a wire different from an invoice payment?
A wire is final in a way an invoice is not. Once the bank releases it, the money leaves the account and the beneficiary holds it, with no chargeback and no card network to reverse the charge.
The bounded instrument shows the difference. Ramp's virtual card page says a team can "Restrict a card to a single vendor or merchant category" and "issue a single-use card that automatically closes after one payment", so a card carries a ceiling and an expiry that a wire does not (Ramp, 2026). A card payment that goes wrong is bounded by the limit and the single use; a wire that goes wrong is bounded by nothing on the page.
Banks sell the release instead. Chase's Connect guide gives per-account access levels, "See activity only" and "Transact only", and makes "Approve pending transactions" a per-account right (Chase, 2026). Its dual control setting goes further: with Chase Dual Control-Transaction, "all transactions will automatically require approval by another user" except transfers between Chase accounts (Chase, 2026). The guide also sets a clock: "Transactions must be approved within three days" (Chase, 2026).
Those rights govern who can move money and when. They do not govern what the person, or the agent, saw on the page that produced the payment, which is the gap Do Coding Agents Break Separation of Duties? describes for machine work.
What do the vendors themselves say?
Three agent products document a checkpoint at the moment of action rather than a filter on the page.
OpenAI's help page for Atlas said that in logged-in mode the agent "can use sites you're already signed in to", which is how a finance team's own bank session becomes the agent's session, and that the agent "will pause to ensure you're watching it take actions on specific sensitive sites such as financial institutions" (OpenAI, 2026). The same page added that it "cannot run code in the browser, download files, or install extensions" (OpenAI, 2026).
Perplexity's post on Comet says "Comet pauses for your confirmation regardless of whether our systems detect suspicious activity" for "Any instance where the agent needs to fill in user details it doesn't already know" (Perplexity, 2026). A saved beneficiary is a detail the agent already knows, so the confirmation the post describes is not the moment the account is entered.
Microsoft's page for Browse with Copilot lists "Financial activity (banking, stock trading, credit card details)" among the things it should not be used for, and says Copilot "cannot access autofill data, saved passwords, or wallet information" while it "can access cookies" (Microsoft, 2026). A scope warning and a stored-credential exclusion leave the signed-in session in place.
A credential control shows the same boundary: 1Password's post on OpenShell says "The agent can work with real systems without holding any credentials in its context", and its gateway "replaces a placeholder with the real value only when the agent sends a request to an approved host" (1Password, 2026). That governs the credential and the host, not what a permitted page returns, the question Why Should Submitting a Credential Require Its Own Permission? separates from authentication.
| Dimension | Vendor, per its documentation | What a buyer should verify |
|---|---|---|
| Release checkpoint | Atlas paused on specific sensitive sites | What the model read before the pause |
| Confirmation trigger | Comet confirms when it must fill in details it does not know | Whether a saved payee skips the confirmation |
| Scope warning | Copilot names banking as a do-not-use activity | Whether a warning is a control on the page |
| Credential handling | 1Password keeps credentials out of the agent's context | Whether the page after the fill is filtered |
None of the four describes replacing the values on the portal before the model reads them, the gap a finance team has to close elsewhere.
What record does a wire release leave?
The artifacts a bank and an ERP keep are real and useful. Chase's guide says primary admins "can view up to one year of user activity and 90 days of transaction reports", and every release carries a user, a time and an amount (Chase, 2026). The ERP keeps the invoice, the approval history and the vendor record. What none of those artifacts carries is the screen the model read.
An audit question about an agent-assisted wire has three parts: what the model received on the payment page, what the agent proposed, and who released it. The bank log answers the third and part of the second, and the ERP answers the invoice. The first part has no home unless the environment the agent runs in writes it down.
That missing piece matters more as approval moves onto channels a model can imitate. The state's banking regulator advises that "Covered Entities should consider using authentication factors that can withstand AI-manipulated deepfakes" (New York State Department of Financial Services, 2024). An approval tied to a named person in a system, with the amount and the beneficiary attached, is the version a record can hold.
What Is an AI Control Record? sets out what such a record contains: the screens the model saw, the actions it took and the person who answered for each one.
What does a governed environment change?
A governed environment is a control class that acts where the page is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, the principle What Is Least Exposure? sets out, so the beneficiary account renders as ACCT_001 on the vendor record, the invoice and the bank portal. Real values resolve only at an approved destination, at the moment of an approved action. A named person approves each release, and the approval attaches to the amount and the beneficiary. Every screen as tokens, every action and every approval is written to a record exported to the organization's own monitoring.
On the $48,000 wire the difference is concrete. The portal shows ACCT_001 where the account digits sit, so an injected instruction on the payee page has no digits to collect. The agent prepares the payment on the label, a person approves $48,000 to that label, and the real account resolves once, at the payment the person released. If the beneficiary changes between preparation and release, the mismatch is visible on the approval screen.
The scope is the rendered page. A payment assembled in a terminal, a script that calls the bank's API or a direct integration between the ERP and the bank sits outside it, and a team that pays that way needs a control at that layer.
The two controls sit in different places: the browser decides which session the agent may use, and a render-layer control decides what the model reads inside it.
What the record shows
Control over a wire sits at three points: what the model receives from the rendered payment page, who approves the release, and what record the run leaves. On this record the bank portal draws the beneficiary account and the balance, the vendor record holds the same account, and the release right belongs to a person whose name the bank logs. The vendor pages describe pauses, confirmations and scope warnings at the moment of action, and each of those arrives after the page has been read. A finance team should test its own setup before the first live wire by preparing one wire in a sandbox with a real beneficiary record, then comparing the fields the portal drew with the values the run reports having read and the name attached to the release.
Methodology and limitations
This page rests on vendor documentation from Chase, NetSuite, Ramp, OpenAI, Perplexity, Microsoft and 1Password, a peer-reviewed benchmark of web agent privacy, and guidance from New York's financial regulator. Vendor pages were read between October 20, 2026 and October 22, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control, and the wire described here is a record type.
No product on this page was tested for this page. The products are described from their public documentation, and RedactSure is deploying now with enterprise and government customers. Where a behavior is not described in the pages reviewed, it means the pages in Sources. Vendor features change and the page carries its date; the example describes a record type, and determinations belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Is it safe to let an AI agent wire money?
No. A bank portal draws the beneficiary account, the balance and the release control, and the agent's model receives what the page draws, so a hostile instruction finds the real account. OpenAI's page puts a pause before actions on sensitive sites, and that pause arrives after the reading (OpenAI, 2026). The condition that changes the answer is a page that renders labels instead of digits and a release that belongs to a named person.
What does the model receive from a bank portal page?
Whatever the portal renders. On a payment screen that is the payee list, the account and routing digits, the available balance, the prior payments and the approval status, while the agent needs only the payee, the amount and a reference. Research on autonomous web agents finds them "prone to inadvertent use of unnecessary sensitive information", which fits a task that reads four values and receives the page (Zharmagambetov et al., 2025). That gap is the exposure.
Who approves a wire the agent prepared?
Whoever holds the release right on the account. Chase's guide makes "Approve pending transactions" a per-account right and its dual control setting can require approval by another user (Chase, 2026). The right governs movement, and a name sits against the release. It does not tell the approver what the model read on the page that prepared the payment, so the approval covers the amount and the payee and stops there.
What record does the bank keep, and what does it miss?
The bank keeps the release: a user, a time, an amount and a beneficiary, viewable for a limited period. It does not keep the model's reading. An auditor who asks what the agent saw cannot answer from a statement, which records a transfer and not the screen that produced it. That missing piece is what an exported control record supplies, and it is the first artifact to ask a vendor for.
Can a single-use card replace a wire for vendor payments?
Only where the vendor accepts a card. Ramp's page says a team can "issue a single-use card that automatically closes after one payment", which caps the loss and ends the instrument (Ramp, 2026). A card can be restricted to one vendor, so a mistaken payment reaches a single merchant rather than any payee the portal holds. A wire has none of those bounds, which is why the release, not the instrument, carries the control.
What would make an agent-assisted wire auditable?
Three artifacts: a record of what the model received on each rendered screen, a named person's approval of the amount and the beneficiary, and a control that kept the real account out of the model's context until the release. A bank log supplies the release only. RedactSure builds the environment that supplies the first two, with tokens on the rendered page, resolution at the approved destination, and every screen and approval in the AI Control Record. Ask for all three in writing.
How RedactSure Keeps the Beneficiary Account Off the Wire Screen
A finance team can hand an agent the payment run and still have no statement of what the model read on the bank portal. A confirmation tied to filling an unfamiliar detail leaves a saved beneficiary uncovered, the exposure a payment page creates.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the portal and the vendor record render the account and balance into the model's context. Inside, both render ACCT_001, the agent prepares $48,000 against the label, a named person approves that amount and beneficiary, and the real account resolves once at the release, with every screen and approval in the record.
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 wire cannot be walked back, so settle what the model reads before the money moves. Bring one beneficiary record and see, with test values, what the page shows the model and where the real account lands. Book a demo