Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Pay State Sales Tax Without Your Bank Account Number?
No, not on the payment step itself: an agent that fills a screen collecting the account and routing numbers reads the digits it types, and keeps them for the rest of the run. Check whether the rendered page substitutes tokens before the model reads it, who approves the submit, and what record shows what the model received.
A sales tax return for one state ends at a payment, and the payment step is a screen that asks for the account and routing numbers the money will move from. An agent working that step reads the fields as a person at the desk does, so the digits enter the model's context before the confirmation page appears. A confirmation and the settings that make an agent ask first govern what happens after the page is read; neither changes what the page put in front of the model. A team filing in several states meets that shape on a different page each time, and the variation is where the work sits. What the model receives on each of those screens decides whether the account number has to be in the run at all, and a payment sent from an account no one approved is not something a controller can unwind after the state has processed it. The record used here is one state sales tax payment, a balance due on a filed return, and the measure at each step is what the page rendered, who released the money and what record survives the run. A controller should know what the model read on each payment page before the agent files.
Key findings
- For a state tax payment to keep the account number out of the model, the payment page would have to render a consistent token in the field, so the run works from ACCT_014 and ROUTING_014 and the real digits resolve only at the submit a person approved (What Is Render-Layer Tokenization?).
- It would also require a named person releasing each payment, so the real account resolves only at the destination that person approved, and a record of what the model received (What Is an Approved Destination for AI Agent Output?).
- None of the vendor pages reviewed says that a payment screen replaces the account number before a model reads it; they document fields, roles and steps (Intuit, 2026).
- Intuit's answer for vendor bank setup is plain about the requirement: "You'll need the account number for the vendor", and it names no field labels (Intuit, 2026).
- Oracle NetSuite states that where a vendor record carries no bank account "you can only pay vendor bills by check", which ties the electronic route to a number on the record (Oracle NetSuite, Creating Vendors, 2026).
- Suntory's supplier questionnaire states that "Bank account information must be included" when electronic payment is selected, while a Check selection skips the bank prompt on that form (Suntory Global Spirits, 2026).
What does an agent read on a state sales tax payment screen?
The record is one state's sales tax payment: a return already filed, a balance due for the period, and a payment step waiting for a method. Portals often split that work across two screens. A university self-service portal shows the handoff: the account page lists "The total amount you owe" and a "Payment portal", and "Pay Now" will "be redirected to the Touchnet Payment Portal for payment" (North Carolina Central University, 2026). The second screen is where the banking fields sit.
On that second screen the fields are few: an amount, a period, a jurisdiction, a bank account number, a routing number, an account type and a confirm button. An agent filling the form reads each field it types, and a field it does not type is usually still on the screen.
| Step | What the screen shows | What the agent has to hold |
|---|---|---|
| Choose the route | Electronic payment, or a check | Which route the state accepts |
| Enter the account | Account number, routing number, account type | The digits, unless the page renders a token |
No state portal's payment screen is among the pages reviewed, so the field list for a particular state comes from that state's own page. The match needs the amount, the period and the jurisdiction, and the bank details render on that screen anyway (What Is Least Exposure?). The payables record makes the same point: the vendor's bank account and routing numbers travel with everything else a model reads to match an invoice (Can AI Work NetSuite Payables Without Bank Details?).
Where does the bank account number enter a state tax payment?
The number enters before the money moves, and the recorded systems show two doors. The first is the payee or vendor record. Oracle NetSuite states that where a vendor record carries no bank account, "you can only pay vendor bills by check", so an electronic payment begins from an account on the record (Oracle NetSuite, Creating Vendors, 2026). The second is the payment screen itself, where a method is chosen and the details are typed.
Intuit's answer for QuickBooks Online bill pay breaks the setup into steps, "Select Enter vendor's bank account info", Next, and "Enter the vendor's bank account information", and it states the requirement in the same answer, "You'll need the account number for the vendor" (Intuit, 2026). It also names the dashboard route, "Selecting the Bill Pay Online dashboard widget", so the task an agent runs starts from a dashboard and ends on a form.
Oracle NetSuite puts the electronic route behind a person's permission as well: "assign the Edit level for the following required permissions for ACH payments" (Oracle NetSuite, Creating Vendors, 2026). Suntory's supplier questionnaire states that "Bank account information must be included" when electronic payment is selected, and that with Check selected "you will not be prompted to add your bank account" (Suntory Global Spirits, 2026). That is the only recorded route that skips the field, and a check is not something a browser agent can print and mail. The page is also exposed to text that arrives with the task: a study of injections that ask an agent to leak personal data seen during a task reported success "around 20 percent" (Alizadeh et al., 2025).
What do the vendors themselves say?
Four vendor pages describe the work, and each documents fields, roles and steps rather than what a screen shows a model.
Oracle NetSuite's payment form offers "For Electronic Bank Payment" as a checkbox, and choosing it clears "the Check # field and other payment options", which selects the rail the payment takes without saying what the screen renders to a model that fills it (Oracle NetSuite, Single Vendor, 2026). BILL's vendor view shows "the last four digits of the bank account, and the full routing number" where a user entered the details, a partial view that still prints the routing number in full (BILL, ePayment, 2026).
| Dimension | What the vendor documents | What a buyer should verify |
|---|---|---|
| Where the details enter | A vendor record, then the payment form | Which screen the agent opens first |
| What the page prints | The routing number in full, the account in last four | Whether the model reads the edit page |
| Who may pay | An Administrator with signing authority | Whether the approval attaches to the run |
| What a record shows | Roles, and a test deposit after a change | Whether the run itself is recorded |
BILL's role page assigns payment authority to a person: "Administrators typically have signing authority on your bank account because they can authorize bill payments" (BILL, Roles, 2026). The same page keeps "The Accountant role can manage the payables processes, but cannot pay bills" and "is not able to manage users or view/manage banking information", which limits who reaches the page rather than what the page shows (BILL, Roles, 2026). Intuit's thread names no field labels, so it cannot say which field takes the routing number (Intuit, 2026).
Before the digits are read, a state payment page would have to render a token in their place, and 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 (Do AI Agents Ask Before Making a Payment?; How Many AI Security Products Control What an AI Agent Sees?).
Does a confirmation or a role change what the model read?
OpenAI's help page for its dots lists four behaviours, including "Ask before taking action" and "Take action without asking", and it warns that "Your dot can make mistakes, including when following your rules" (OpenAI, 2026). Those settings decide whether an action waits for a person, not what the page showed the model before it proposed the action; a dot that asks first has still read the screen.
BILL keeps the money with a role, "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, 2026). A role narrows who can reach the page and who can release money, and says nothing about the fields it renders once that person, or that agent, is on it; a confirmation gates an action after the number has been read.
The ask that follows is about the page, not the product. Which screen does the agent open for each state, which fields does it render, and are the account and routing numbers among them? What record exists, and where does it go? AWS's agentic guidance states that "audit logs attribute every action unambiguously to either an agent or a human actor", which is the standard a tax payment record should meet (AWS, 2026). A form-filling product documents half of the design the ask points to: "the LLM only sees placeholders (x_user, x_pass)" and "real values are injected directly into form fields after the LLM call" (Can a Browser Agent Fill In a Form Without Seeing the Values?), which covers the fill and says nothing about the page that follows.
What does a governed environment change?
A governed environment is a control class that acts where the screen is drawn, before a model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so an agent filing a state payment works from ACCT_014 and ROUTING_014 on every screen it opens.
Real values resolve only at an approved destination, at the moment of an approved action. Each state portal is named as its own destination, which is how a multi-state filer keeps one policy per portal. A named person approves each submit and each bank change, and every screen, action and approval lands in a record that exports to the organization's own monitoring (What Is an AI Control Record?).
The class changes what the page carries, not what a role allows. Its scope is the rendered page and what the agent does on it, not the terminal, the IDE, the local filesystem, direct API calls or MCP. A payment file an agent builds through a direct API call is outside it. For a portal payment the class is the difference between an agent that reads an account number and one that reads a token (What Is a Secure Alternative to Agentic Browsers for Paying Vendor Invoices?).
What the record shows
The control that decides this question sits where the page is drawn: whether the account and routing numbers are replaced with tokens before any model reads the screen, who releases the real digits, and what record shows both. The payment systems recorded here put the number on a screen in front of the work, at the vendor record, at the bank setup or at the payment step itself, and none of them says the page substitutes the value before a model reads it. A finance team can narrow who reaches the page and verify a bank change with a test deposit, and neither changes what the agent read. One state's payment page in a test company is enough of a test: list every field it renders, mark the ones the payment needs, and compare that list with what the model received.
Methodology and limitations
This page rests on vendor documentation for four payment systems, a university knowledge base, OpenAI's help page for its dots, AWS's agentic guidance, one preprint on injection against agents, and the RedactSure pages linked above. 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.
The products are described from their public documentation and none was tested for this page; "not described in the pages reviewed" means those pages. No state portal's payment screen is among them, so a field list for a particular state comes from that state's own page. Features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a sales tax balance due, not an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Can an AI agent pay state sales tax without your bank account number?
No, not while it works the payment screen. The systems recorded here ask for the account and routing numbers where the payment is prepared, and an agent filling that page reads what it types. The number stays out of the model when the rendered page substitutes a token, a person enters the bank step outside the agent's view, or the field is filled from a store the model cannot read. Which of those a portal supports is a question for that state.
What does the model receive when an agent opens a payment page?
Whatever the page renders, including the fields the payment does not need. A balance, a period and a jurisdiction are the match, and the account and routing numbers are the instruction to the bank. They sit on the same screen, so a model reading the page receives both and keeps them for the rest of the run. The fields that matter are on the payment step, not the login page.
Who approves a tax payment an agent prepares?
Whoever holds the payment role, unless the run itself carries an approval. BILL's page puts payment authority with an Administrator and keeps the Accountant from paying bills or viewing banking information. That decides which person can reach the page, and it does not name an approver on the run. The design to ask for attaches one named person to each submit.
What record shows what the agent read on a state portal?
None of the pages reviewed describes one for a tax portal. The roles, the confirmation and the test deposit are records of a person and an account, not of a run. A run record is a different artifact: the page as the model read it, the action it took and the name of the person who approved. AWS's guidance is the standard to hold a vendor to, since it asks that logs attribute each action to an agent or a human.
Does a confirmation screen or a two-step verification make the payment safe?
No. A confirmation gates the action after the page has been read, and the account number is on the page before the gate. OpenAI's dot settings, including "Ask before taking action", change when an agent waits and not what it received. The gate is worth having for the release, and the exposure has already happened by then. Ask what the page rendered instead.
Do all state portals ask for the same fields?
Not from the pages reviewed. No state portal's payment screen is recorded here, and the payment systems that are recorded differ: one asks for the vendor's account number at setup, another prints the routing number in full, a third lets a check skip the bank prompt. Treat each portal as its own page with its own fields, and check the payment step rather than the login page. The field list differs by state as well as by portal. A pilot on one state settles what that state renders.
How RedactSure Keeps the Bank Account Off a State Tax Payment Screen
A filing agent that opens a state payment page types the account and routing numbers it asks for, and those digits stay in context. Alizadeh and colleagues measured injections that ask an agent to leak personal data seen during a task and reported "average attack success rates (ASR) around 20 percent" (Alizadeh et al., 2025).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent read the account and routing numbers the page rendered, and both stayed with it. Inside the governed environment the same page renders ACCT_014 and ROUTING_014, the agent submits the tokens, the real digits resolve only at the payment a named person approved, and the approval goes to the record.
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 state's payment page shows which fields an agent reads and what the record keeps. Bring one tax payment and see, with test values, the page as the model receives it, who approves the submit and the record it leaves. Book a demo