Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Can an AI Agent See When It Logs Into Your Accounts Payable System?
The agent receives the whole view the AP role renders: vendor bank accounts and tax identifiers, open bills with amounts, payment history, and the payment fields where a check or an electronic payment is set up. Ask which of those values the model receives and who approves the release.
An accounts payable clerk signs in with a role, and the role was built to show one person the whole job: the vendor's bank account so a check can be printed, the tax identifier so a form can be filed, the open bills so nothing is paid twice. An agent that signs in with that role receives the same view, because the screen does not know who is reading it. The answer to the title is a list of fields a finance team recognizes, rendered in full to a model that keeps a transcript.
Finance leaders keep returning to this question because the stakes are concrete. Most organizations are experimenting with agents and far fewer are scaling them, and the distance between those two numbers is where programs stall (What Is the PII Wall?). Accounts payable is the hard case in that gap, because the sensitive values are not incidental: the bank account is what a payment needs, and the tax identifier is what the vendor record exists to hold.
The worked case is a vendor master record: one supplier with its bank account, remittance address, tax classification and the bills attached to it. The evidence comes from the vendors' own help pages, a supplier registration guide, and research on what a model does with what it reads.
Key findings
- For an agent to work a bill without holding the vendor's bank account, the values on the vendor record and the payment screen would have to be replaced with consistent tokens before the model reads them, with the real account released only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each payment and each change to a vendor's bank details, and a record of what the model received (Do Coding Agents Break Separation of Duties?).
- The vendor pages reviewed put the boundary at the role or the approval step, and none of them states that values are replaced before a model reads them, so the account a permitted role can see is the account the model receives (BILL, 2026).
- NetSuite's help states that if a vendor record has no bank account, "you can only pay vendor bills by check", which leaves the account on the record the agent opens (Oracle NetSuite, Creating, 2026).
- The Pay Single Vendor form asks the user to "select the payee you want to pay" and carries the check number and the electronic payment box on the same screen (Oracle NetSuite, Paying, 2026).
- BILL lists "six (6) pre-defined roles" and says Administrators "typically have signing authority on your bank account because they can authorize bill payments" (BILL, 2026).
What does an accounts payable login render to an agent on its first screen?
An accounts payable login opens on a work queue, and the record behind the queue is the vendor master. A clerk moves through three screens to pay one bill: the vendor record, the open bill and the payment form, and each one renders fields the others do not. A supplier registration guide states that "Bank account information must be included", and its tax section takes a VAT number, an EIN or an individual's Social Security number (Suntory Global Spirits, 2025). The same guide says an Individual entity type "will only be selected for suppliers using a government issued identification number" (Suntory Global Spirits, 2025).
The record also holds a "Vendor Remittance Email Address", one address that a remittance notice goes to (Oracle NetSuite, Creating, 2026). "To Be Printed" on NetSuite's payment form "adds a check to the print queue", so the read and the action share one page (Oracle NetSuite, Paying, 2026).
| Field on the record | What it carries | Where it is read |
|---|---|---|
| Bank account and routing number | The destination of a payment | The vendor record and the payment form |
| Tax identifier | An EIN, a VAT number or a Social Security number | The tax section of the supplier record |
| Remittance email | One address per vendor | The vendor record |
| Open bills | Amount, date and approval status | The bill list and the payment form |
| Payment fields | Payee, check number, electronic payment box | The Pay Single Vendor form |
None of those fields is a separate permission, which is why the role decides the exposure. NetSuite's ACH setup requires a user to "assign the Edit level for the following required permissions for ACH payments", a permission on the role rather than on the field (Oracle NetSuite, Creating, 2026). A clerk who can open the record sees the whole row, and an agent signed in as that clerk receives the rendered page, including the bank account the payment needs and the tax identifier it does not (Can AI Work NetSuite Payables Without Bank Details?).
What do the vendors themselves say?
Two controls appear in the vendor material, and neither is about what the screen shows. NetSuite's approval routing depends on limits, and its example is that "the employee's supervisor must approve all purchase orders over $500" (Oracle NetSuite, Approval, 2026). That is a control on who releases money, applied to a person with a named supervisor and a limit the administrator sets.
NetSuite, BILL and SAP sit outside a 15-agent review in which 6 document asking a person before completing a payment or purchase (Do AI Agents Ask Before Making a Payment?).
SAP's invoice verification states that "The invoice block applies to all items in an invoice", so one variance puts the whole invoice in front of the model (SAP, 2026). Releasing it is a separate step: "You must release a blocked invoice in a separate step before it can be cleared for payment" (SAP, 2026). The design keeps the decision with a person and keeps the invoice whole, and the whole invoice is what an agent reads to prepare the release.
BILL's role page states the boundary in the negative: the Accountant "can manage the payables processes, but cannot pay bills" and "is not able to manage users or view/manage banking information" (BILL, 2026). The field set follows the role, and the role is assigned to a person, so the answer to a field-level question is a role-level one. A buyer should ask which role the agent will hold and what that role's screen renders, because the pages answer the first question and leave the second open.
What happens to the values after the agent has read them?
Reading is not the end of the exposure, because the read becomes a record. A study of contextual privacy in language models recorded that GPT-4 and ChatGPT "reveal private information in contexts that humans would not", at 39% and 57% of cases (Mireshghallah et al., 2024). The measured failures are about what a model says, and the AP case adds what it keeps: the values it read travel into the run's transcript, into any summary it writes and into whatever the tool stores.
The read also opens the door to a second instruction. A page the agent opens can carry text that tells it to send data elsewhere, and a study of browsing agents reports "prompt injection, domain validation bypass, and credential exfiltration" (How Do I Design an Agent Workflow That Assumes the Agent Gets Hijacked?). An agent that has read the bank account and can reach the payment form holds both halves of that attack on one screen.
Approval after the fact does not undo the read. OpenAI's governance paper calls human approval "a standard way to limit egregious failures" (Shavit et al., 2023), and holds that "Actions that can only be reviewed after the fact should be more easily reversible" (Shavit et al., 2023). A payment can be reversed, and a bank account copied into a model's context and then into a stored summary cannot.
What should a controller ask for in writing before an agent signs in?
Ask for four answers in writing, and treat a vendor that cannot give them as not ready.
First, which values does the model receive from the rendered screen? The answer should name fields, not a product. A supplier's tax identifier is on the record because a form needs it, and a payment run does not. The registration guide says an Individual entity type "will only be selected for suppliers using a government issued identification number", which for a US supplier is a Social Security number (Suntory Global Spirits, 2025).
Second, who approves, by name? AWS's guidance says "audit logs attribute every action unambiguously to either an agent or a human actor", which is a standard a controller can hold a vendor to (AWS, 2026). The AI Agent Index entry for Breeze Agents records that "The default is that approval is required", and that users can switch it off (AI Agent Index, 2025). A default is a setting.
Third, what record of what the model read exists, and where does it go? An action log answers whether a payment went out. It does not answer what the agent saw on the vendor record, and that is the question a breach review asks.
Fourth, does the control cover the screen the agent uses? A control on the API or on the network does not change what the rendered page shows (Does a Coding Agent Need Approval Before Spending Money?).
What does a governed environment change?
A governed environment changes what the model receives, not what the vendor's screen shows. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers.The page renders as usual, and the values chosen by policy are replaced at the render layer with consistent tokens before any model reads the screen: the vendor's bank account becomes ACCT_014 and stays ACCT_014 for the whole run, so the agent sets up a payment against the token it read on the invoice. Real values resolve only at the approved destination, at the moment of an approved action, so the account number reaches the payment instruction a person approved and does not reach the transcript.
Three properties follow. Exposure is decided per field and per task rather than per role, so a clerk's role can read the bill without the model receiving the tax identifier. A named person approves each payment and each change to a vendor's bank details, which is the approval the vendor pages describe, applied to the agent's proposal. Each screen as the model saw it, each action and each approval with a name lands in a record the customer exports.
The limit is the rendered page. An agent that reads the vendor master through a direct API call is outside this control, and tokenization at the render layer does not govern the terminal or a shell. The identity question behind it is the subject of the comparison with privileged-access tooling (RedactSure vs CyberArk: 2026 Comparison & Alternative).
What the record shows
The control that matters here is what the model receives when the payment screen renders, and what record exists of it; access to the screen is the smaller question. Across the pages reviewed, an accounts payable login is a role, the role renders the vendor record in full, and the approval sits after the agent has read the bank account, the tax identifier and the remittance address. None of those pages states that a value is replaced before a model reads the screen, so a finance team connecting an agent to AP should assume the role's whole view enters the context. One test settles it on the reader's own system. Open the vendor record an agent will use, write down every field that renders, and compare that list with the fields the task needs; then ask the vendor, in writing, which values the model receives and who approves the release. If the lists differ and nothing sits between the screen and the model, the difference is the exposure.
Methodology and limitations
Every statement about an accounts payable screen comes from the vendor's own help page or supplier guide, read in full: three NetSuite help pages, a BILL role page read from a Wayback snapshot because the live host answers automated requests with a challenge page, SAP's invoice verification lesson, a Suntory Global Spirits supplier registration guide, and an AWS Well-Architected page. The research comes from a preprint on privacy in language models and a governance whitepaper. Vendor pages were read as of October 22, 2026.
No product on this page was tested for this page, and no 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 in every configuration. Vendor features change, and the page carries its date. The example describes a record type, a vendor master record, and not an organization. RedactSure is deploying now with enterprise and government customers. Compliance determinations belong to the organization's counsel and its security and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
What can an AI agent read when it signs in to an accounts payable system?
Everything the role can open: the vendor master with its bank account, tax identifier and remittance address; the open bills with amounts and approval status; the payments already made; and the payment form itself. The screen does not distinguish a clerk from a model, so an agent signed in with the clerk's role receives the rendered page. The only limit the vendor pages describe is the role, and the role is set for a person with the whole job.
Does an approval step keep the bank account out of the model?
No. The approval decides whether the payment happens, and it happens after the model has read the record to prepare it. NetSuite routes approvals by expense and purchase limits, with limits set per employee, and that governs who releases money. It does not change what the agent read on the way to proposing the payment. A control on the release is not a control on the exposure.
Who approves a payment an agent has prepared?
A person with an approval limit, if the system is configured the way the vendor pages describe. BILL gives the Administrator signing authority and says the Accountant cannot pay bills. NetSuite routes a purchase order above a limit to a supervisor. In both cases the approval is a person's action on a screen, and the agent's proposal is not an approval. Ask who the named approver is, and whether an agent can complete the step itself.
What record shows what the agent read?
Usually none. AP systems log the action: who paid what, when and under which approval. That log answers the auditor's question about money and not the breach reviewer's question about data. A log that attributes each action to an agent or a human is the standard for the first part. A record of what the model received on each screen is a separate artifact, and it has to reach the customer's own monitoring to be checkable.
Is the bank account masked on the vendor screen?
Not on the pages reviewed. Where a role can view banking information, the vendor record renders it, and BILL's Accountant role is defined by not being able to view or manage banking information, which shows the boundary the help describes is the role. A mask on a lookup screen would be a display choice that leaves the stored value in place for the next screen.
What should a controller ask for before an agent signs in?
A written answer to four questions: which values the model receives from the rendered vendor record and payment form; who approves each payment and each change to a bank account, by name; what record of what the model read is exported and where; and whether the agent holds its own identity or signs in as a person. A vendor that answers all four in control terms, rather than in settings, is the one to pilot.
How RedactSure Replaces the Vendor Record Before the Agent Reads It
The pages reviewed govern who may pay and stop short of what the model receives on the way to proposing the payment. Vendor help for the invoice block states that a block "applies to all items", so the whole invoice is what an agent reads.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the model received the vendor record as the clerk's role renders it: bank account, tax identifier, remittance address, open bill. Inside the environment, the same record renders as VENDOR_014, ACCT_014 and TAX_014. The controller approves the release against ACCT_014, and the real account resolves only at the payment instruction the controller approved.
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
One vendor record and one bill show what the agent reads, who releases the payment and what the run keeps. Bring a record you would not paste into a chat and watch it run with test values. Book a demo