Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is It Safe to Let an AI Agent Onboard New Vendors?
No, not while the model reads the bank account, routing number and tax identifier that a vendor registration form collects, because the first payment follows the account number the record holds. Replace those values with consistent tokens before the model reads the screen, and have a named person approve the first payment.
A new supplier reaches accounts payable as a form. It asks for the legal name, the address split into a street and a house number, a tax identifier, a payment method, and, once electronic payment is selected, the bank account and routing number. The agent that fills it in reads each field as the page renders it, including the two fields that decide where money goes. The work is clerical, and the data is the target.
The same values then live on the vendor record, and the first payment to the new supplier follows the account number stored there. A person who reviews the setup afterward is reviewing what the agent already read. The question is whether the setup can be safe, and the answer turns on one point: what the model receives from the registration screen before it acts.
The record used here is a new supplier setup: one questionnaire, one vendor record and one first payment. It is a record type, not a company, and the same shape appears in a procurement portal, an ERP vendor form and a bill-pay page. The vendor pages reviewed show where each control sits, and the research record shows why one reading matters.
Key findings
- An agent that reads a rendered vendor form receives every value the page displays, so the bank account, the routing number and the tax identifier reach the model on the same screen that asks for the supplier's name (What Is an AI Control Record?).
- It would also require a named person approving the first payment to the new supplier and a record of what the model read on each screen, because an approval that follows the form cannot undo a value the model already holds (What Is Supervised Delegation?).
- None of the vendor pages reviewed describes a control that replaces the bank account or the tax identifier before an agent's model reads the registration screen; Suntory's guide lists the fields and states that "Bank account information must be included" (Suntory Global Spirits, 2025).
- Suntory Global Spirits' supplier questionnaire asks for a VAT registration number and, for an individual, a US Social Security number or a Canada SIN, and it states that "Electronic payment must be selected if bank account is included" (Suntory Global Spirits, 2025).
- NetSuite's vendor record for automated payments states that "If a vendor record does not have a bank account, you can only pay vendor bills by check", so the account sits on the vendor record an agent reads when it sets the supplier up (NetSuite, Creating Vendors, 2026).
- GPT-4 and ChatGPT "reveal private information in contexts that humans would not" in 39% and 57% of cases, which makes one reading of a supplier's account number one too many (Mireshghallah et al., 2024).
What does an agent read when it opens a new supplier's registration form?
Suntory Global Spirits' supplier guide splits the address into a Street field and a House number field, makes the DUNS number optional, asks for a VAT registration number that a supplier without one leaves blank, and states in its payment section that "Electronic payment must be selected if bank account is included", which makes the bank account a required field on the same form (Suntory Global Spirits, 2025).
Intuit's community answer for QuickBooks says "Set up Bank Transfers within the same line as the Payee" and that "You'll need the account number for the vendor", a support thread from 2021 that names no field labels and cannot say which field takes the routing number (Intuit, 2021). What it does show is the order of work: the bank details are entered during setup, before any bill exists to pay.
The form is the whole record of the reading. A field the questionnaire renders is a field the model receives, whether or not the person who reviews the setup ever opens that page, and a page can carry a field the person never sees. A study of generalist web agents found that hidden page elements let attackers steal user data, with "EIA achieves up to 70% ASR in stealing specific PII" (Liao et al., 2025).
For a browser agent, the registration page, the vendor record and the payment screen are three renderings of one data set. The model that prepares the vendor record reads the bank digits once and can carry them into every later step of the run.
Who should approve the first payment to a supplier the agent set up?
The approval that matters is the one before the first payment, and the vendor pages reviewed put approval on the invoice, the purchase order or the payment run, not on the vendor record the agent filled. NetSuite's approval routing sets steps from "the employee's expense limit or purchase limit" and "the approval limit of the supervisor or approver", and its example is that "the employee's supervisor must approve all purchase orders over $500" (NetSuite, Approval Routing, 2026).
Oracle's setup guide puts "Match Approval Level (2-way, 3-way, 4-way)" in the Purchasing Options window, the Suppliers window or the purchase order shipment, and "Hold Unmatched Invoices (enabled, disabled)" in Financials Options, Payables Options, Suppliers and Supplier Sites (Oracle, 2026). It is a setup page: it names the windows and does not say what happens once an invoice is held (Can AI Work Oracle Payables Without Bank Details?).
Those controls govern a bill, not the vendor record, and the first payment can pass all of them. Suntory Global Spirits' guide says the company "uses a 3rd-party provider (Trust Pair) to validate supplier bank information", a check that runs after the form is submitted and can catch a bad account before payment (Suntory Global Spirits, 2025). A validation result is evidence about the account; it is not a statement of what the model read.
Financial-sector guidance flags agents that "may act without human validation" (Is It Safe to Let AI Agents Access Financial Records?), and a named person approving the payment is the control the record points to (What Is Supervised Delegation?). That approval covers the vendor record and the first payment together, because the account number enters the process there.
Of the 15 AI agents reviewed, 6 document asking a person before completing a payment or purchase, 9 do not describe it, and none of the ERP vendors on this page was among them (Do AI Agents Ask Before Making a Payment?).
What do the vendors themselves say?
NetSuite's vendor record page for automated payments is the most detailed of the pages reviewed on the fields an onboarding agent fills. It adds an "Intelligent Payment Automation" subtab and, on it, "in the Vendor Remittance Email Address field, enter one email address", while ACH users must "assign the Edit level for the following required permissions for ACH payments" (NetSuite, Creating Vendors, 2026). The procedure is U.S.-only and belongs to that SuiteApp, so a buyer outside it should not read the page as a description of the general vendor record.
SAP's lesson puts the tolerance settings in Customizing for Materials Management and describes the block that follows a breach, not the page where a supplier's bank details are entered (SAP, 2026). The AP page covers the gap between the invoice and the payment in a SAP estate (Can AI Work SAP Payables Without Vendor Bank Details?).
Oracle's guide names the windows where matching is set, from the Purchasing Options window to the supplier site, and the page does not say what happens to an invoice once it is held (Oracle, 2026).
| Dimension | NetSuite, per its documentation | What a buyer should verify |
|---|---|---|
| Vendor record | Company Name, Type and Email, a Primary Subsidiary, a Financial subtab and a Vendor Remittance Email Address (NetSuite, Creating Vendors, 2026) | Whether the onboarding form and the vendor record are the same screen |
| Payment | "In the Payee field, select the payee you want to pay"; "The Check # field shows the next check number or shows To Bill Pay" (NetSuite, Paying Bills, 2026) | What the approver sees before releasing the first payment |
What record should the onboarding leave, and who can read it?
A record of an onboarding has to answer two questions: what the model read on the registration screen, and who approved the first payment. An ERP audit trail shows that a vendor record was created and by which user account; it does not show which values the model received (What Is an AI Control Record?).
The value a model holds is what an injection collects. If a page reaches an agent that already holds the bank account, the attacker does not need to find the bank field again; a successful injection takes whatever the context holds, and an agent that has only placeholders gives up placeholders (What Can a Hijacked Agent Leak If It Only Has Placeholders?).
Masking does not have to cost the work. 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, which places the loss on inconsistent redaction rather than on masking as such (Does Masking Data on Screen Break Browser Agents?).
A record that shows which tokens the model saw, which real values resolved on approval and who approved them is the artifact an auditor can read. A transcript of the model's reasoning is not: it is the model's account of itself.
What does a governed environment change?
A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders such as BANK_014 and TAX_014. 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. A named person confirms the tokenization policy and approves each consequential action, and the first payment to a new supplier is one. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.
For vendor onboarding, that changes three things. The registration form renders the bank account and tax identifier as tokens, so the model that fills the form never holds the digits. The vendor record page, the payment screen and the confirmation page render the same tokens for the rest of the run, which closes the later pages a form-only control leaves open. The first payment resolves the real account only when the named approver releases it, and the record shows both the tokens the model saw and the approval. Its scope is the rendered page: a bank file loaded through an API or a shell script is outside it.
The control is orthogonal to the ERP's matching and approval settings: those decide whether an invoice can be paid, and this decides what the model reads while it prepares the record. A team can hold both, and the vendor pages reviewed give the first half in detail.
What the record shows
A vendor onboarding is safe when the model receives placeholders for the bank account, the routing number and the tax identifier, a named person approves the first payment, and the run leaves a record of what the model read and who approved it. The pages reviewed put those values on the registration form and keep them on the vendor record for every later invoice, and none of them places a control between the rendered page and the model. What the agent reads decides the exposure; how carefully the form is filled does not. Name one new supplier, run the setup on a test record, and compare the fields the model received with the fields the payment used.
Methodology and limitations
This page rests on vendor documentation from NetSuite, Oracle, SAP, Intuit and Suntory Global Spirits, two research preprints on model privacy behavior and environmental injection, and existing RedactSure research pages. Vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page. Quoted facts are cited to the page that states them, and the Intuit answer is a community support thread rather than product documentation.
No product on this page was tested for it. The pages reviewed describe fields, matching controls and approval routing; none describes a control that replaces a value on the registration screen before a model reads it, so the condition in the Summary comes from the control class. Vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a new supplier setup, not an organization. Determinations about tax, payment and records requirements belong to counsel, assessors and the organization's own security and compliance officers.
Frequently asked questions
Is it safe to let an AI agent onboard new vendors?
No, not while the model reads the bank account, routing number and tax identifier the registration form collects. An agent that fills them reads them as the page renders them. The answer changes when the page renders placeholders for those fields before the model reads it, and a named person approves the first payment. Until those two controls are in place, the agent is doing the one part of onboarding that should not be delegated to a reader of the page.
What does an agent read on a vendor registration form?
Every field the page renders. A supplier questionnaire asks for the legal name, the address, an optional DUNS number and a VAT registration number or EIN, and it states that "Electronic payment must be selected if bank account is included" (Suntory Global Spirits, 2025). A form that hides a field from a person can still render it to the browser, so the review has to cover what the model received and not only what the person saw.
Who should approve the first payment to a new supplier?
A named person outside the agent's run, with a written limit. NetSuite's approval routing caps a supervisor at 25 transactions at a time and ties a step to an employee's purchase limit, a rule about transactions (NetSuite, Approval Routing, 2026). A first payment to a new supplier needs its own approval, because the account being paid is what the agent read on the form. The approver should see the account on file, the validation result and the agent's record before releasing it.
What record should the onboarding leave?
One record per run that shows the fields the model received, the actions it took and the name of the person who approved the first payment. An ERP audit trail shows that a vendor record was created and by which user account; it does not show what the model read. The record should join the two, so an auditor can compare the account digits the model held with those the payment used. Without that join, the review can confirm the payment but not the exposure.
Does a bank validation service change what the model reads on the onboarding?
No. Suntory Global Spirits' guide says a third-party provider, Trust Pair, validates supplier bank information after the form is submitted (Suntory Global Spirits, 2025), a check that can catch a bad account before payment. It does not change what the model read while completing the form, and a value in the model's context can be repeated later. The service narrows the payment risk and leaves the reading risk where it was.
Can a person fill the bank fields while the agent reads the rest?
For the bank step, and only while the person is in the session. The agent stops at the payment section, a person types the account and routing numbers, and the agent resumes. The limit is every page after the handover: a vendor record or confirmation page that displays the account on file renders like any other page. Check every page the agent reads after the handover, including the one it stepped away from.
How RedactSure Keeps Vendor Bank Details Out of the Agent's View
An agent that fills a supplier form reads the bank account it is about to submit, and a validation service checks it only afterward.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the registration page renders the account digits and the tax identifier, and the model keeps both for the rest of the run. Inside the governed environment, the form renders BANK_014 and TAX_014, the model works from those tokens, and the real values resolve only on the payment record a named person releases.
RedactSure is deploying now with enterprise and government customers. Suntory Global Spirits' own registration guide states that "Bank account information must be included" when electronic payment is selected.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A vendor's bank details decide where the next payment goes, and the agent that typed them can repeat them later in the run. Bring one supplier setup and see, with test values, what the model reads and who approves the first payment. Book a demo