Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does an AI Agent Need the Vendor's Routing Number to Schedule a Payment?
No; the scheduling step needs the vendor, the amount and the date, and the payment system attaches the stored routing number to the instruction. Check what the model receives when the payment screen renders, and who approves the release.
A finance team that lets an agent prepare payments has one practical question to settle: can the run finish without the vendor's bank numbers entering the model's context. The form suggests it cannot. A vendor record in an accounts payable system carries the payee's bank panel, and that panel prints the routing number beside the shortened account digits.
The task is smaller than the screen. Scheduling a payment selects a payee, an amount and a date, and the system attaches the bank record it already holds when the payment executes. The routing number sits on the page because the record is rendered whole, not because the scheduling step consumes it. That gap between what the instruction needs and what the display carries is where exposure lives. Every payment repeats that arrangement.
The stakes are ordinary. A prompt injection does not need the task to use a value; it needs the value to be in the context when the agent reads a page it did not choose. The question that follows is what the model receives on the payment screen, who approves the release, and what record survives the run.
Key findings
- For the run to schedule a payment without holding the routing number, the values on the payment screen would have to be replaced with consistent tokens before any model reads it, with the real numbers resolving only at the approved payment (What Is Render-Layer Tokenization?).
- It would also require a named person approving each release and a record of what the model received, because a release is consequential (What Is Least Exposure?).
- The pages reviewed describe a vendor record that prints the routing number and a payment election that updates bank details, and none of them describes replacing those values before the model reads the screen (BILL, ePayment, 2026; Workday, 2026).
- BILL's help page shows a user with Manage Vendor permissions "the last four digits of the bank account, and the full routing number" on the vendor's ePayment info (BILL, ePayment, 2026).
- BILL's role page gives the Administrator "Approve bills" and "Schedule payments, including pay unapproved and unassigned bills", while the Accountant "can manage the payables processes, but cannot pay bills" (BILL, Roles, 2025).
- Workday's payment elections page shows "Account Number" and "Routing Number" and updates payment elections when bank details change, so the number is a record field (Workday, 2026).
What Does an Agent Read on a Payment Screen?
A scheduled payment carries a payee, an amount, a date and the bank panel the system keeps for that payee. The vendor panel carries ROUTING_001. The instruction uses the first three fields; the panel appears because the record is rendered whole.
BILL's help page shows that panel. A user with Manage Vendor permissions selects ePayment info, which for details that user entered shows "the last four digits of the bank account, and the full routing number" (BILL, ePayment, 2026), a panel the schedule never needs. For a Network vendor that maintains its own details, "the numbers will be masked, but you'll see if there's an existing verified bank account" (BILL, ePayment, 2026), so masking the account leaves the routing number readable.
Workday's payment elections page treats the bank account as a record field: an administrator can "Add or upload initial payment elections", and when bank details change "Workday automatically updates all payment elections with the new account information" (Workday, 2026), which leaves the number on a page the schedule does not read.
The City of Minot's EFT guide asks the customer to type the routing number into the Bank name field and then choose the bank from the list displayed (City of Minot, 2026), which puts the number on the page during enrollment. An agent that opens these screens receives the value whether or not the instruction calls for it (Can an AI Agent Pay an Invoice in QuickBooks Without Seeing the Vendor's Bank Account?).
Is the Routing Number Part of the Task or the Record?
A scheduled payment names a payee, an amount and a date, and an approval releases it. Bank data belongs to the payee record, so the number can sit on the screen without being a field the agent fills (Can a Browser Agent Fill In a Form Without Seeing the Values?).
Functional access is what the instruction needs: the vendor selector, the amount, the date. Informational access is what the page displays: the bank panel, the account nickname, the routing number. The number does not have to be in the context for the schedule to be correct.
IRS Direct Pay "requires a U.S. bank routing number (ABA)", and the payer supplies it at the moment of payment (Internal Revenue Service, 2026), so there the bank data is part of the instruction.
1Password's OpenShell integration states that "The agent can work with real systems without holding any credentials in its context" (1Password, 2026), though the page covers developer credentials. The CaMeL paper sets a design goal that "the untrusted data retrieved by the LLM can never impact the program flow" (Debenedetti et al., 2025), a design goal rather than a tested control. Both describe work that proceeds on a representation rather than the value (Can AI Work NetSuite Payables Without Bank Details?).
Of 15 AI agents and 86 AI security products reviewed, none describes replacing the customer data an agent reads on a screen with tokens it can work with, and the payables products described here were not among them (Do AI Agents Ask Before Making a Payment?, How Many AI Security Products Control What an AI Agent Sees?).
What do the vendors themselves say?
BILL prints the routing number on the vendor's ePayment info and shortens the account number. Workday treats the bank account as a payment election that updates automatically. Minot's portal asks the customer to type the routing number into a field labelled Bank name. Each page describes a screen where the value is present.
| Dimension | What the vendor documents | What a buyer should verify |
|---|---|---|
| Vendor bank panel | BILL shows "the last four digits of the bank account, and the full routing number" to the user who entered the details (BILL, ePayment, 2026) | Whether the model receives the panel or only the shortened account number |
| Payment elections | Workday updates all payment elections with new bank details and gates access by security domain | Whether a change of bank details needs a second approver |
| Approval role | BILL lists "Approve bills" and "Schedule payments, including pay unapproved and unassigned bills" for the Administrator | Who approves a release the agent prepared |
BILL's role page supplies the approval half. It lists "Approve bills" and "Schedule payments, including pay unapproved and unassigned bills" among the Administrator's permissions and says Administrators "typically have signing authority on your bank account because they can authorize bill payments" (BILL, Roles, 2025), which tells a buyer who may schedule, not what the screen prints. The Accountant role "can manage the payables processes, but cannot pay bills" (BILL, Roles, 2025).
Workday's page states that when bank details change "Workday automatically updates all payment elections with the new account information" and that access is governed by security domains (Workday, 2026), which describes access and not what the model receives.
Who Approves a Payment an Agent Schedules?
BILL's roles separate part of the work: the Clerk role is "permission to only enter bills", a Payer "cannot enter or approve bills", and anyone who pays "must complete identity verification to become authorized to use the bank account in BILL" (BILL, Roles, 2025). The Administrator can approve and schedule, which is a permission rather than a screen control. A role assignment tells a reviewer which screens the agent may open and which actions it may take, and it does not put a person between the model's proposal and the release, the distinction a payment page has to settle before scheduling is delegated (Is It Safe to Let an AI Agent Pay Vendor Invoices?).
The AI Agent Index entry for Breeze Agents records that "The default is that approval is required", adding that users can switch the setting off and that automatically triggered agents then run without approval (AI Agent Index, 2026). A default that an operator can change is not a standing approval.
The approval names a person outside the model and fixes the amount, the payee and the date. On the worked record the approver releases the payment while the screen shows ROUTING_001 as a token, and the real routing number resolves only at the payment the approver released.
What Does the Record Show About What the Model Received?
A permissions report does not say what the model read on the screen, and the difference matters after an incident. It records what was allowed, not what happened. For a scheduled payment the useful record has four parts: the screens the model received as tokens, the action it proposed, the person who approved the release, and where the real routing and account numbers resolved.
AWS's Well-Architected guidance asks for logs that "attribute every action unambiguously to either an agent or a human actor" (AWS, 2026), a record requirement that says nothing about which fields the model read. The log has to name the agent and the approver separately. A record that shows only the service account, or only the person whose login the agent used, cannot answer the first question an auditor asks.
The vendor pages reviewed describe roles, fields and security domains. They do not describe a record of what the model received on the payment screen. That gap sits outside the payables system, and it is why a run needs its own record rather than a permissions export. The record should be exportable to the organization's own monitoring, so the review does not depend on the payables vendor. A run that leaves no such record cannot be reviewed after the fact (What Is Least Exposure?).
What does a governed environment change?
The control that changes the answer sits before the model, not inside the role settings. Values chosen by policy are replaced with consistent tokens as it renders, so the payment screen shows ROUTING_001 and ACCT_001 for the whole run (What Is Render-Layer Tokenization?). The real routing and account numbers resolve only at the approved destination, at the moment a named person releases the payment. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. The token is what the model reasons with; the value stays out of the context.
Three properties follow. A named person approves each release, and the approval is written beside the action. The record lists what the model received on each screen, not only what the role permitted. The real values are restored at the destination rather than in the page, so an injected instruction collects tokens.
The scope is the rendered page. A payables API that carries accountNumber and routingNumber directly is a different path, governed by API credentials and scopes rather than by what a browser renders. Masking a field is not the same control, because it changes what the screen prints rather than what the model receives (Does Masking Data on Screen Break Browser Agents?).
What the record shows
The control class answers the title: the payment screen carries the routing number because the record is rendered whole. The task needs the payee, the amount and the date, and the system attaches the bank record when the payment executes. The number is informational access rather than a functional requirement. BILL prints it in full, Workday updates payment elections when bank details change, and neither page describes replacing those values before the model reads the screen. A buyer can test one scheduled payment with test values and note the fields the model received, the person who approved the release, and whether the record names both.
Methodology and limitations
This page rests on vendor help pages and official guidance from BILL, Workday, the City of Minot, the IRS, 1Password, the CaMeL paper, AWS and the AI Agent Index. 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.
No product on this page was tested for it. "Not described in the pages reviewed" means the recorded pages for that product do not cover the point; it is not a claim about what the product does. 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 belong to counsel, assessors and the organization's own security officers, and a pilot of one payment workflow is the only way to confirm what the model receives.
Frequently asked questions
Does an AI agent need the vendor's routing number to schedule a payment?
No. The schedule needs the payee, the amount and the date, and the payment system attaches the bank record it holds when the payment executes. The routing number appears because the vendor record is rendered whole, which makes it informational access rather than a field the task consumes. The distinction matters because the model still receives the value, and an injected instruction reads whatever the context holds.
What does the model receive when the payment screen renders?
Whatever the page displays, which on a vendor record includes the bank panel, the routing number and the shortened account number. BILL's help page prints the full routing number to a user who entered the details, and Workday's payment elections page lists the bank fields beside the account nickname. A model receives the page as rendered, so a field a person can see is a field the model can read.
Who approves a payment an agent schedules?
A named person outside the model, rather than the agent that proposed it. BILL's role page separates some of the work, since an Accountant cannot pay bills and a Payer cannot enter or approve them, but a role decides which actions an agent may take. It does not place a person between the proposal and the release. The approver should see the amount, the payee and the date, and the approval should be written beside the action.
What record should a scheduled payment leave?
One that names the screens the model received, the action it proposed, the person who approved the release, and where the real routing and account numbers resolved. AWS's audit guidance asks for logs that attribute each action to an agent or a human actor, and a payment record should meet that standard with both names present. A permissions export is not that record. It says what a role may do.
Does masking the account number change what the model reads?
No. Masking shortens what the page prints, and the model receives the page as rendered, so a shortened account number is still a value on the screen. The routing number is often printed in full beside it, as BILL's vendor ePayment page does. A control that changes what the model receives has to act before the page reaches it, and a display rule changes only the print.
Which vendor pages show the routing number, and what should a buyer verify?
BILL's ePayment info, Workday's payment elections page and the City of Minot's EFT setup all place the number on a screen, and the IRS asks for it on Direct Pay. A buyer should verify which of those screens the agent can open, whether the model receives the bank panel or a shortened view, and who approves the payment the agent prepares. Ask for the field list the model receives in writing, because it names what the model can see rather than what a person can edit.
How RedactSure Keeps the Routing Number Off the Payment Screen
A payment agent opens the vendor record and reads the routing number before it schedules a payment that never needed the number. BILL's own help page prints "the full routing number" on the vendor's ePayment info even when the account is shortened.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the vendor record, reads ROUTING_001 beside ACCT_001, and schedules a payment that never needed either value. Inside the governed environment: the page renders the routing number as a token, the agent selects the vendor, the amount and the date, and a named person approves the release; the real value resolves at the approved payment, and the record names the model 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
The number sits on the record, not in the task, so the screen is where exposure is decided. Bring one scheduled payment and see, with test values, what the model reads and who approves it. Book a demo