Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Work in a Core Banking System Without Seeing Account Numbers?
No, not on the core screen as it renders today, where the record is keyed by the account number the page displays. Ask what the model receives from that screen, and whether the number is replaced with a consistent token before it reads it.
The core platform is where a bank keeps the account, and every screen it serves is keyed by the account number: the header of the customer record, each transaction row, the statement, the hold, and the standing order built from the same account. An agent asked to post a fee reversal, answer a balance question or trace a failed payment opens those screens and reads them the way a clerk does, so the number enters the model's context beside the amount, the date and the counterparty. A bank's existing controls settle who may open the screen and who may release the money. They do not settle what the page shows once the agent is on it, and that gap is where the answer sits. The record used here is one core banking screen for a customer account, with the account number in the header and in every row that points at the same account, and the measure at each step is what the model received, who approved the posting, and what the record states afterward. The stakes are the ones a bank's operations and fraud teams already carry: a payment sent to a changed account does not come back, and a run that read the number can repeat it. The control that closes the gap sits before the model reads the page, where values chosen by policy become consistent tokens and the real value resolves only at an approved destination (What Is Render-Layer Tokenization?).
Key findings
- For an agent to work a core banking screen without the account number, the values on the page would have to be replaced with a consistent token such as ACCT_001 before any model reads it, and the same token would have to hold across every screen of the run (What Is Render-Layer Tokenization?).
- It would also require a named person approving each posting, payment and account change, and a record of what the model received on each screen, because an approval that arrives after the reading cannot undo it (What Is an AI Control Record?).
- What the pages reviewed do not describe is a core banking platform that replaces the account number before a model reads it; the role boundary is documented and the reading boundary is not (BILL, Roles, 2026).
- BILL's help page for a permitted user shows a masked field that still prints "the last four digits of the bank account, and the full routing number" (BILL, ePayment, 2026).
- The same product's API reference is more explicit: "Read results only display the last 4 digits of the account and routing details," illustrated as "4567" and "**0358" (BILL, VendorBankAccount, 2026).
- Adaptive attacks bypassed 12 published defenses with an "attack success rate above 90% for most," so a filter on the tool call is not a substitute for keeping the value out of the model (Nasr et al., 2025).
What does an agent receive on a core banking screen?
One core banking platform, one customer account, one screen. The header carries the account number, each transaction row carries the same number beside the posting it belongs to, and the agent's task is to post a fee reversal against the balance the page shows. The model receives the rendered page, field by field, in the order the page draws it. Nothing on that screen separates the account number from the fields the posting needs, because the number is the key the screen is built from: the balance, the hold and the transaction list are retrieved by it.
The nearest documented case of a payment screen reducing what it shows is BILL's ePayment view. A user with Manage Vendor permissions opens the vendor's ePayment page, 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). Where the user entered the details, the page returns "the last four digits of the bank account, and the full routing number" (BILL, ePayment, 2026). That is a masked partial view rather than a token, and the model holds the last four digits and the routing number for the rest of the run.
The API reference shows where the mask is applied. The create payload carries vendorId, accountNumber and routingNumber, while "Read results only display the last 4 digits of the account and routing details" (BILL, VendorBankAccount, 2026). An agent that creates or corrects a bank account works through the payload, which carries the full value, so the read-path mask says nothing about the write path.
Whether a core platform masks the number on the customer account screen is not described in the pages reviewed, and a bank that has not tested its screen cannot assume it does.
What breaks when each screen renders a different placeholder?
A core platform shows one account in more places than any other record type: the customer header, the transaction list, the statement, the hold, the standing order, and the payment instruction built from the account. An agent working a posting moves between those screens inside one run, and the work succeeds only if the model can tell that two rows belong to the same account. That is the property a placeholder policy has to preserve.
If each screen renders a fresh placeholder, the same account becomes ACCT_001 on the header and ACCT_002 on the transaction list, and the model cannot make the join. A measured study of masking reports the size of the loss: replacing identifiers with consistent pseudonyms and restoring them after the model has done its work reduces semantic utility errors by a factor of five compared with baseline techniques (Does Masking Data on Screen Break Browser Agents?). Consistency carries the result: one token per value for the whole run, the same token on every screen, and the restore after the work.
Removal is a different policy with a different cost. The Minimizer in a benchmarked agent-tool defense "aggressively redacts input arguments" and "can also remove information that is important for task success" (Bhagwatkar et al., 2026). A redacted account field can leave the agent unable to say which account a row belongs to. A consistent token keeps the key usable and the value hidden.
Placeholders entered at typing time cover less than they appear to. A browser tool that fills a form from a store can show the model a placeholder and inject the real value after the call (Can an AI Agent Work With a Placeholder Instead of a Real Credential?). That covers the fill. The account screen the agent reads next still renders whatever the core draws, and that is where the number returns.
What do the vendors themselves say?
The vendor pages divide between the screen and the permission around it. BILL's role page assigns the money to a person: "Administrators typically have signing authority on your bank account" (BILL, Roles, 2026). It also 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" (BILL, Roles, 2026). That is a permission boundary on the account, enforced before the page renders: the accountant's session does not show the banking fields, and a model given the administrator's session reads them.
NetSuite's Pay Single Vendor form is the other side. The clerk picks the vendor, reads the balance and the currency, and checks "For Electronic Bank Payment" to process the payment through electronic payments; the Check # field "shows the next check number or shows To Bill Pay" (NetSuite, 2026). The form is keyed by the payee and the account, and the page is a form reference: it never mentions purchase orders, receipts or matching, so it does not say what the screen shows about the account behind the payee.
Each page states its own limit. BILL's help article covers looking up ePayment information and stops there: editing bank data, paying an invoice and matching a purchase order sit outside its scope (BILL, ePayment, 2026). Neither vendor page describes an approval step for the payment or a record of what a model read.
| Dimension | What the vendor pages document | What a buyer should verify |
|---|---|---|
| Where the account appears | A masked view returns the last four digits and the full routing number | Whether the core screen returns a partial value or a token |
| The write path | The create payload carries accountNumber and routingNumber | Whether the agent's task writes the number |
| Who may see it | The Accountant cannot "view/manage banking information" | Whether the agent's session carries that boundary |
| The payment form | Pay Single Vendor is keyed by payee and account | What the page renders about the account behind the payee |
| The record | Neither page describes an approval or a log of what a model read | Who approves, and what the record states |
Who approves a payment the agent prepared, and what record does it leave?
An approval is a decision about the action, and the pages in this record treat it that way. BILL assigns signing authority to the administrator role and withholds payment from the accountant (BILL, Roles, 2026). Harvard's guidance states the rule a bank program is written against: "Require human approval for high-impact, sensitive, irreversible, or externally visible actions whenever feasible" (Harvard University, 2026). None of those reaches the reading step: the approver sees the payment the agent prepared, and the number the model read is already in context.
The record has the same timing. AWS's guidance for agent identity states that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026). That answers who acted after an incident, not what the model saw. An agent running inside a clerk's session makes the log attribute the reading to the clerk.
The fraud record explains why the account field matters. The FBI's complaint data records 305,033 reported business email compromise incidents and $55,499,915,582 in exposed loss from October 2013 to December 2023, figures derived from complaints and filings rather than confirmed payments (FBI, 2024). Its prevention advice includes "Use secondary channels and/or two-factor authentication to verify requests for changes in account information" (FBI, 2024). A change of account details is the request an injected page or a compromised mailbox will make, and an approval on the same screen does not verify it on a second channel.
An approval and a record are necessary and not sufficient: they govern the action and describe it afterward, and the number was read before either. A study of browsing agents reports failures that "include prompt injection, domain validation bypass, and credential exfiltration" (What Is the Difference Between a Headless Browser and a Protected Browser for AI Agents?).
What should a bank ask a vendor for in writing?
The written questions sort the answers. Harvard's guidance lists seven risk categories for AI-enabled systems, among them Sensitive Data Exposure, Privilege and Identity Misuse, and Governance and Visibility (Harvard University, 2026), and its footnote names the combination to design against: "The riskiest agent setup combines three things: access to private data, exposure to untrusted content, and the ability to send data outward." A core screen with an account number is the first of the three, a page the agent reads is the second, and an outbound payment is the third.
The first question is about the screen: what does the model receive from the rendered screen? A vendor that answers with a role model or a log has answered a different question. The follow-up is whether the account number is replaced before the model reads the page, whether one token holds its value across every screen, where the real value resolves, and whether the token store can resolve outside the approved destination.
A bank comparing browser options can put the question to each. The test for an enterprise browser on an account screen is the same one: the routing and account numbers would have to become tokens such as ACCT_001 before any model reads the rendered page, with real values released only where the bank approved (Is Chrome Enterprise Premium Enough for AI Agents in Financial Services?). QuickBooks bill pay has a written version: for the page to keep the vendor's account number out of the model, it would carry a consistent token instead (Can an AI Agent Pay an Invoice in QuickBooks Without Seeing the Vendor's Bank Account?).
The last questions are the ones a security review can evidence: who approves each posting and account change, and what record states what the model received. Ask for that record as it would be exported, not a screenshot of a dashboard.
What does a governed environment change?
A governed environment changes the answer by changing what the page puts in front of the model. Values chosen by policy are replaced with consistent tokens at the moment the screen renders, before any model reads it, so the agent works the account as ACCT_001 on the header, on the transaction rows and on every later screen of the run. The real number resolves only at an approved destination, at the moment of an approved action, so the posting travels to the core and not into a transcript. A named person approves each posting, payment and account change, and every screen as tokens, every action and every approval is written to a record that exports to the bank's own monitoring (What Is an Approved Destination for AI Agent Output?).
That changes the failure mode. A model that holds the account number and is then injected can be made to repeat it: the information-flow record shows that "poisoned data retrieved from one component can change the model's behavior and compromise the entire system" (Siddiqui et al., 2025). A model that holds ACCT_001 carries a token that resolves only inside the environment that issued it.
The scope is the rendered page. A governed environment does not govern the core's batch jobs, a direct API integration or the database, and a number that enters a run through one of those routes sits outside this control. For the agent that works the screens, the control that decides the answer is the one that acts before the model reads.
What the record shows
An account number is the key a core screen is built from, and the answer follows the fields. The model that reads the screen holds the number with the balance and the rows; the documented reductions elsewhere return a partial value, the last four digits and the full routing number on a read and the full value on the write payload. A role boundary, an approval step and an audit log govern who may act and what is recorded after the fact, and none of them changes what the page rendered before the model acted. That is why the answer is conditional: no page in this record states that a core platform replaces the number before a model reads it, and the pages that do reduce the value reduce it to a partial view. A bank should check its own screen by naming one agent and one posting, running the task on test values, and writing down three things: what the model received from the page, what the page showed a clerk at the same step, and who approved the posting.
Methodology and limitations
This page rests on four vendor help pages, a regulator's fraud notice, a university guidance page, three research preprints, and existing RedactSure research pages. Public documentation read in full gives a sound view of where each product applies its control, and the vendor pages were read between October 16, 2026 and October 22, 2026, with each Sources line carrying the date for its page.
The products on this page are described from documentation and none was tested for this page, so a statement that a behavior is not described in the pages reviewed means the recorded pages do not state it, not that the product cannot do it. No core banking platform's own help page was among the pages read, so the core screen here is a record type built from the account-keyed screens the vendor pages do describe, and the example is a record type, not an organization. Vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. Determinations about whether a workflow meets a regulatory requirement belong to the bank's counsel, assessors and security officers, and nothing here replaces a pilot of one workflow on the bank's screens.
Frequently asked questions
Can an AI agent work in a core banking system without seeing account numbers?
No, not on the core screen as it renders today, because the record is keyed by the number the page displays. The documented reductions stop at a partial value: BILL returns "the last four digits of the bank account, and the full routing number" in its masked view, and its API returns "the last 4 digits of the account and routing details". A bank that wants the number out of the model has to replace it on the rendered page first, and keep the same token across the run.
What does the model receive when a core screen renders an account number?
Every field the page draws, in the order it draws them, because the model reads the rendered screen rather than a selected column. The number sits in the header and in each row that points at the account, and the model holds it with the amount, the date and the counterparty for the rest of the run. No page reviewed separates the number from the fields a posting needs, and a screen that masked it would still hand the model a partial value or a token.
Who approves a payment the agent prepared?
A person with signing authority, in the pattern the vendor pages describe. BILL gives the administrator signing authority on the bank account and withholds payment from the accountant, and Harvard's guidance asks for human approval on high-impact and irreversible actions. An approval settles whether the payment runs; it does not change what the model read to prepare it, and a change of account details should be verified on a second channel, which the FBI's notice recommends.
What record shows what the model read on the screen?
Not the audit log on its own. AWS's guidance asks that audit logs attribute every action to an agent or a human actor, which answers who acted and when. A record that answers the reading question lists the screens as the model saw them, the token that stood in for each value, and the approval with the name of the person who gave it. A role log shows the actor; a screen-level record shows the exposure.
Does masking the account number to the last four digits keep it out of the model?
No. A partial mask returns part of the value, and the model holds it: BILL's masked view returns the last four digits and the full routing number, and the API reference returns the last four digits of the account and routing details. The mask also depends on the path, because the same API's create payload carries the full account and routing numbers. A partial view narrows what the model holds and leaves an identifier it can tie to the record.
What should a bank ask a vendor in writing?
Which values the model receives from a rendered screen, whether the account number is replaced before the model reads the page, whether one token holds the same value across the run, where the real value resolves, who approves each posting and account change, and what record is exported. A vendor that answers the last two has described its approval and its log and left the reading question open. Ask for the exported record, not a dashboard view of it.
How RedactSure Keeps the Account Number Off the Core Screen
A core screen is keyed by the account number, and the controls reviewed here govern who reaches the page, not what it shows the model.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the customer account screen, the model reads the number in the header and in every transaction row, and the approval prompt arrives after that reading. Inside the governed environment: the same screen renders ACCT_001 and ROUTING_001, the posting is drafted against ACCT_001, and the real account resolves at the core's save when a named person approves.
RedactSure is deploying now with enterprise and government customers. BILL's masked view still returns the last four digits and the full routing number.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A posting that reads an account number leaves the key to the customer's record in the model's context. Bring one core screen and see, with test values, what the model receives and who approves the posting. Book a demo