Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Work in Workday Financials Without Seeing Supplier Bank Accounts?
No, not while Workday puts supplier bank account setup and payment editing on screens its payment roles can open, because an agent working them reads what the page renders unless the values are replaced before the model sees them. Ask which fields the agent receives and who approves the release.
A supplier record in Workday Financials is where a vendor's banking details join the payment chain, and the settlement run is where they leave it. A payables team that wants an agent to raise the supplier request, clear an exception and prepare the run hands over the screens the work happens on, and those screens carry the values the payment depends on. Workday's role model decides who can open the task, and its approval step decides when a run is processed, and neither decides what the page draws. The answer turns on what the model receives: the supplier's name and account number as the screen shows them, or SUP_014 and ACCT_014 while the real values wait for a destination a person releases. The record here is one supplier in Workday Financials, from the request that creates its bank account to the run that pays its invoices. A wrong account is money that does not come back, and the agent's reading of a payables system is where that starts (What Can an AI Agent See When It Logs Into Your Accounts Payable System?).
Key findings
- For an agent to work a Workday supplier record without seeing the bank account, the account and routing numbers would have to be replaced with consistent tokens before the model reads the screen, so the run works from ACCT_014 and the real value resolves only at the approved payment (What Is Render-Layer Tokenization?).
- It would also require a named person approving each supplier bank change and each settlement run, and a record of what the model received on every screen (What Is an Approved Destination for AI Agent Output?).
- Workday's settlement and supplier topics describe the domains that open the task and the details a user edits; they do not state that those values are replaced before a reader receives the page (Workday, Settlement, 2026).
- The settlement topic requires the "Process: Settlement domain in the Banking and Settlement functional area", and Create Settlement Run opens "Manage Payments to edit payment details" (Workday, Settlement, 2026).
- The supplier topic configures "Create Settlement Bank Account" as an action step on the Supplier Event business process, under the "Set Up: Supplier Administration domain in the Suppliers functional area" (Workday, Suppliers, 2026).
- BILL's role page states that "The Accountant role can manage the payables processes, but cannot pay bills" and is "not able to manage users or view/manage banking information", a limit on who opens the bank details, not on what the screen shows the agent (BILL, Roles, 2026).
What does a Workday supplier record put in front of an agent?
The record is one supplier in Workday Financials: a request form, the Supplier Event business process behind it, and the settlement run its invoices feed. Workday's supplier topic lists what the request collects, including the DUNS number, the tax authority form type, the TIN type and a justification, and it puts "Create Settlement Bank Account" on the business process as an action step under the "Set Up: Supplier Administration domain in the Suppliers functional area" (Workday, Suppliers, 2026). The topic carries a 2023 date.
The payment side is a separate task. Create Settlement Run takes the currency, the display currency and the filters, and a user selects "the unpaid open items and pending payments", then opens Manage Payments to edit payment details before the run is processed (Workday, Settlement, 2026). The run is where a wrong account becomes a payment that has left.
An agent asked to prepare either screen receives the page the browser draws. OpenAI's help page says that with connected apps its agent "can access sensitive data like emails, files, or account settings", which describes reach (OpenAI, 2026). The screen that carries the invoice carries the payment details too, the wall What Is the PII Wall? describes, and the account number is needed only when the payment is built on the same page.
What does Workday's role model decide, and what does it leave open?
Workday governs the task by domain. A user reaches the settlement run through the Process: Settlement domain or a narrower one such as supplier invoice payment, and a supplier request sits under Set Up: Supplier Administration (Workday, Settlement, 2026). That is an access decision, and the right one: fewer people who can pay, fewer accounts a payment can leave from.
The pattern is general to business software. BILL draws the line for money: "Administrators typically have signing authority on your bank account because they can authorize bill payments", while "The Accountant role can manage the payables processes, but cannot pay bills" and is "not able to manage users or view/manage banking information" (BILL, Roles, 2026). The same page separates entry from payment: "A Payer cannot enter or approve bills", and the Clerk role is "permission to only enter bills" (BILL, Roles, 2026).
An agent signs in as a user or through a connector, so the same role applies to it. What a role cannot do is separate a field from the page. When the task is the settlement run, the agent holds a role that can pay, and the screen it opens is the screen that role is allowed to see. A role answers the who question and leaves the what question where it was; the rendered page answers that one, which is why the reading is the part a role review cannot settle. None of the 15 AI agents reviewed in October 2026 describes replacing a supplier's bank values on a working page before the model reads them, and no Workday product was among the 15 (Do AI Agents Ask Before Making a Payment?).
What do the vendors themselves say?
Workday's pages describe a task built around supplier and payment data. The supplier topic names the action step that creates the settlement bank account (Workday, Suppliers, 2026), and the settlement topic names the domains that open the run and the payment details a user edits (Workday, Settlement, 2026). Neither page describes a substitution between the page and the reader.
BILL documents the closest thing to a display control here. Its ePayment page shows "the last four digits of the bank account, and the full routing number" to a user with Manage Vendor permissions, and for a 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). A masked record still carries the routing number whole.
Intuit's answer puts the requirement plainly: "You'll need the account number for the vendor" (Intuit, 2021). The number is part of the setup, and Workday's action step is the same kind of step (Can an AI Agent Pay an Invoice in QuickBooks Without Seeing the Vendor's Bank Account?).
| Dimension | Workday, per its documentation | What a buyer should verify |
|---|---|---|
| The bank account step | "Create Settlement Bank Account" on the Supplier Event business process | What the model receives on that screen |
| Payment editing | "Click Manage Payments to edit payment details" | Whether the account is shown or tokenized |
What should a buyer ask for in writing before an agent opens a Workday screen?
Lead with the screen. The written answer should say what the model receives from the rendered supplier request and the rendered settlement run, field by field, and whether the account and routing numbers are replaced before the model reads them. A vendor that will not put that sentence in a contract has not described a control over what the agent reads (Can AI Work NetSuite Payables Without Bank Details?).
Then the role, the approval and the record. Which domain does the agent's role hold, and can that role pay? Who approves a supplier bank change, and who approves the settlement run? What does the run record carry: the page as tokens, the action and the approver's name, or only that a payment was submitted?
The reading is the part a written answer skips. Indirect injection is documented: the 2023 study revealed "new attack vectors, using Indirect Prompt Injection" that "enable adversaries to remotely (without a direct interface) exploit LLM-integrated applications" (Greshake et al., 2023). The OWASP disclosure entry names the outcome: personal information "may be disclosed during interactions with the LLM" (OWASP, 2025). A supplier's account and routing numbers are the values that make that disclosure expensive.
What record does a settlement run leave, and what does it not?
Workday's pages describe a record of the transaction. Approval routing follows a supplier request submission, and reviewers can populate more supplier details in fields that are not on the Create Supplier Request task (Workday, Suppliers, 2026). On a draft settlement run the Settlement Run Name and the Payment Date can be changed, and the payment date is what prints on checks and advices (Workday, Settlement, 2026).
It is not a record of what the model read. The pages reviewed document the fields a user edits and the approvals that follow; what the agent received on the screen is not described in the pages reviewed. An auditor asking what the agent held when it selected a payment gets the transaction and not the context (Is It Safe to Let an AI Agent Pay Vendor Invoices?).
The gap matters because the loss does not need a wrong approval. An injected instruction on a page an agent reads can "act as arbitrary code execution, manipulate the application's functionality" (Greshake et al., 2023), and the transaction record of such a run looks ordinary. A team that wants an answer at audit time needs the screen as the model saw it, held beside the approval it produced. AWS states the test: "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026).
What does a governed environment change?
A governed environment acts where the screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the supplier request and the settlement run draw SUP_014 and ACCT_014 instead of the vendor's name and account. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. Real values resolve only at an approved destination, at the moment of an approved action, and a supplier bank change or a payment run is one. A named person approves each consequential action, and every screen as tokens, every action and every approval land in a record that exports to the organization's own monitoring.
The role in Workday still decides who can open the settlement task, and the run still needs a payment date and a set of open items. What changes is the page the model works on: the supplier renders as SUP_014, the payment details as ACCT_014 and ROUTING_014, so an agent can select the open items, clear an exception and prepare the run without holding the numbers that move the money. The person who approves releases the real values, and the record shows the page as tokens beside that approval.
Its scope is the rendered page. A payment file produced by a direct integration, or by a batch job that never draws a screen, sits outside it, and the team that owns that integration supplies the control for that route.
What the record shows
A render-layer control changes the answer, because it decides what the model receives rather than who may open the page. Workday's settlement and supplier topics show a task that runs on supplier and payment data: a domain that opens it, an action step that creates a settlement bank account, and a Manage Payments screen where details are edited. The role model narrows who can reach those screens, and it does not narrow what they render. The work still finishes when the page draws SUP_014, ACCT_014 and ROUTING_014, the agent selects the open items on tokens, and the person with signing authority releases the real values. A payables team should check one supplier in a test tenant: open the request and the run as the agent does, name every field the model received, and compare that with what the payment needed.
Methodology and limitations
This page rests on Workday's settlement and supplier topics, BILL's role and ePayment pages, Intuit's QuickBooks answer, OpenAI's help page, OWASP's disclosure entry, AWS's Well-Architected guidance, and a 2023 prompt injection study. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page.
The products on this page are described from their public documentation and none was tested for this page; "not described in the pages reviewed" means the pages named above. 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 and compliance officers; nothing replaces a pilot of one supplier change and one payment run.
Frequently asked questions
Can an AI agent work in Workday Financials without seeing supplier bank accounts?
No. Workday's supplier topic puts "Create Settlement Bank Account" on the Supplier Event business process, and its settlement topic has a user open Manage Payments to edit payment details. An agent that performs either task reads the screen it opens, and the bank numbers sit on that screen. A domain limits who can reach the task. Test one supplier before the first live run.
What does the model receive on a Workday supplier record?
The page as the browser draws it. The request collects tax identifiers and a justification, and the settlement run collects the open items and the payment details a user edits. An agent reading either screen receives those values as text, including any account numbers the screen shows. OpenAI's page says an agent with connected apps reaches "sensitive data like emails, files, or account settings" (OpenAI, 2026). Start from the screen, not the role list.
Does a Workday payment domain keep the bank account off the screen an agent reads?
No. A domain decides which tasks a role may open, and the screen behind the task shows what the task requires. Workday requires the Process: Settlement domain for the settlement run and Set Up: Supplier Administration for a supplier request. It says nothing about the fields the page renders once it opens. BILL's Accountant role cannot view banking information, and the Administrator who can pay holds the authority (BILL, Roles, 2026).
Who approves a supplier bank change or a settlement run?
Whoever holds the approval step. Workday routes a supplier request for approval after submission, and the settlement run is processed by a user with the settlement domain, so the approval lands on a person with a name. That is the right place for accountability, and it is not a control over what the agent read. Name the approver per run, and keep the page that person saw.
What record of an agent's settlement work can an auditor read?
The transaction record: the request, its approval route, the settlement run, its name and payment date, and the date that prints on checks and advices. What the agent received on the screen is not described in the pages reviewed, so an auditor asking what the model held gets the transaction and not the context. Ask for the screen as tokens beside the approval.
What should a finance team ask for in writing about what the model reads?
Four sentences. Which fields the supplier request and the settlement run render to the agent, and whether the numbers are replaced before the model reads them. Which person approves a bank change and each run, by name. What record of the page as tokens is exported, and where. What happens when an injected instruction arrives on a page the agent reads. A vendor that answers all four has described a control worth testing.
How RedactSure Keeps Supplier Bank Accounts Off the Settlement Screen
An agent preparing a settlement run reads the payment details on the same page as the invoice, and a role limit does not separate the two. Workday's settlement topic has the user open Manage Payments to edit payment details before processing.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the supplier request and the settlement run and reads the account and routing numbers beside the amount and the date. Inside the governed environment: the supplier renders as SUP_014 and the payment details as ACCT_014 and ROUTING_014, the agent selects the open items on tokens, and the controller approves the run, when the real values resolve into the payment.
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 run prepared from tokens leaves the model with a supplier code and an approval, not an account number. Bring one supplier change from your own queue and see, with test values, what the model reads and where the real account lands. Book a demo