Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Who Approves an AI Agent's Tax Payment?
The approver is the controller who releases the real bank account to the tax authority, and that release is what a named person has to sign every time. Ask what the model received on the payment page before the release and which record carries the approval.
A quarterly estimate comes due on a Tuesday, and the payment is one form away. The EFTPS payment page asks for the employer identification number, the PIN and the password, and the payment it schedules moves funds out of a banking account on the date the payer selects. Whoever presses Schedule is authorizing a debit the Treasury will take. An agent can fill that page and press the button, and the page allowing it settles little; what matters to the finance team is what the model read while it worked and who was standing behind the release. The approver in a finance team is usually the controller who would have signed the check, and the approval that matters attaches to the release of the real bank account rather than to the return that produced the liability. A debit the Treasury has accepted cannot be recalled, and that asymmetry is why the approval needs a name on it every time rather than a review at quarter end. Payments are scheduled ahead of the due date, so the gap between the signature and the debit is a window in which a wrong payee or amount can still be caught, if the signature was recorded against the page the agent saw. The worked record is a controller approving the release on a payment authorization screen.
Key findings
- For a tax payment to be governed rather than merely scheduled, the values on the payment screen would have to be replaced with consistent tokens before any model reads it, so the agent works from ACCT_001 and the real account number resolves only at the approved destination (What Is Supervised Delegation?).
- It would also require a named person approving each release, with a record that shows what the model received on the page and who signed, because that pair is what an assessor asks for after a debit (What Is an AI Control Record?).
- None of the payment pages reviewed describes who approves an agent's release, and the tax system's own control assumes a person at a keyboard: EFTPS mails the PIN to the address of record and asks for it with the password (EFTPS, 2026).
- BILL's role documentation places payment authority with the bank account: 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" (BILL, 2025).
- NetSuite's vendor record decides whether a payment can leave at all, because "If a vendor record does not have a bank account, you can only pay vendor bills by check," and the ACH route needs Edit level on its payment permissions (Oracle NetSuite, 2026).
Who approves the release, and what exactly are they approving?
A controller who signs a check is approving a specific debit: this account, this amount, this settlement date, this tax period. When an agent prepares the payment, those same facts appear on the authorization screen, and the question is which of them the approver actually saw and which the model had already read.
An Administrator has "signing authority on your bank account because they can authorize bill payments," an Accountant "can manage the payables processes, but cannot pay bills," and a Payer "cannot enter or approve bills" (BILL, 2025). An agent has no role in that list unless someone gives it one, and the role it usually gets is the Administrator's login.
It documents who may release, and not what the model was shown when the release page opened. The research record treats the same line as a design constraint: once an agent ingests untrusted input, "it must be constrained so that it is impossible for that input to trigger any consequential actions" (Beurer-Kellner et al., 2025). A tax debit is a consequential action, and the constraint has to sit between the agent's proposal and the bank's record of the debit. Who Approves an AI Agent's Claim Payment? makes the same argument for insurance payments, where the NAIC Model Bulletin, adopted by 24 states, requires a governance accountability structure with defined responsibilities, and an agent payment with no named approver fails that requirement on its face.
The release is where a person has to be named, yet only 6 of the review's 15 AI agents document asking a person before completing a payment or purchase, and EFTPS, BILL and NetSuite were not among them (Do AI Agents Ask Before Making a Payment?).
What does the agent receive from the tax payment screen?
EFTPS is the route most businesses use, and its sign-in is built for one person at a time. Enrollment is the gateway: "You must be enrolled to use the EFTPS® tax payment service," and the PIN arrives by mail in five to seven business days at the IRS address of record (EFTPS, 2026). Sign-in runs through Login.gov or ID.me, after which the taxpayer enters the EIN or SSN, the PIN and the password (EFTPS, 2026). Every one of those values sits in a rendered field, and an agent that signs in reads the page as the browser draws it. The page cannot tell a model from a person, so it cannot withhold those values from one and show them to the other.
A supplier registration form shows the same collision in a different place. The tax section takes the entity type that decides whether the identifier is an EIN or a Social Security number, and the payment section states that "Bank account information must be included" when electronic payment is selected (Suntory Global Spirits, 2025). Tax identity and bank account are entered on one form, and both render to whoever fills it.
A payment must be scheduled "the day before the due date to be received timely by the IRS" (EFTPS, 2026). A model that reads the cutoff can work the schedule correctly, and a model that read the account number can put a different one in its place (Who Approves an AI Agent Before It Sends Sensitive Information?).
What do the vendors themselves say?
BILL documents which of its roles may pay, and the page says nothing about what a model reading the payment screen receives. It offers six pre-defined roles: an Administrator can authorize bill payments and therefore holds signing authority on the bank account, an Accountant manages the payables process without the right to pay, the Clerk role is permission to only enter bills, and a Payer cannot enter or approve bills (BILL, 2025). Anyone who pays must complete identity verification before using the bank account in BILL (BILL, 2025).
NetSuite documents the record a payment needs, and not what the model reads when the vendor record opens. The vendor record carries a United States address and subsidiary, a bank account on the vendor record because otherwise "you can only pay vendor bills by check," and Edit level on the ACH permissions before the automated route can run (Oracle NetSuite, 2026). It then hands the payment on: NetSuite "automatically submits it in the next scheduled syncing with BILL" (Oracle NetSuite, 2026). The procedure covers United States vendors only and belongs to the Intelligent Payment Automation SuiteApp.
Suntory's supplier guide is a form a supplier completes, written for a person at a keyboard: it requires a bank account with electronic payment, and a third party validates supplier bank information (Suntory Global Spirits, 2025).
| Question | BILL, per its documentation | Oracle NetSuite, per its documentation | What a buyer should verify |
|---|---|---|---|
| Who may release a payment | An Administrator, who holds signing authority on the bank account | A user with Edit level on the ACH permissions | Whether the agent runs under a named person's role or its own |
| Where the bank account enters | The account the Administrator is authorized on | The vendor record, which needs a bank account for anything but a check | Which values the model reads when the record opens |
| What the page says about the model | Nothing in the pages reviewed | Nothing in the pages reviewed | A statement of what the model receives, screen by screen |
A regulated buyer should read that silence as the regulator does. Is It Safe to Deploy AI Agents in Regulated Enterprise Environments? notes that FINRA intends its rules and guidance to be technologically neutral, so the obligations a payment already carries apply to an agent's payment as they would to a person's.
What has to be in the record after the payment goes out?
The record needs two attributes audit systems were built to carry and one they were not. AWS's guidance states the first: "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026). The visibility research names the second set, "agent identifiers, real-time monitoring, and activity logging" (Chan et al., Visibility, 2024), and the follow-on work adds "attributing actions, properties, and other information to specific agents" (Chan et al., Infrastructure, 2025).
None of them covers what the model read on the page before it acted. That is the third attribute, and it is the one a tax payment needs, because the difference between an approved debit and an injected one is not who pressed the button but what the model saw when it decided the button was the next step. A record that shows the approver, the amount and the timestamp answers the control question. A record that also shows PAYEE_004 and ACCT_001 where the account number sat answers the exposure question.
The practical form is a per-run export rather than a screenshot in a ticket: every screen the model read, each action, each approval with a name, and the token values that stood in for the account number (What Is an AI Control Record?). FINRA's 2026 Regulatory Oversight Report, as summarized by Debevoise & Plimpton, flags that agents may act without human validation and may exceed the user's intended scope (Is It Safe to Let AI Agents Access Financial Records?).
What does a governed environment change?
A governed environment acts at the render layer. Values a policy names are replaced with consistent tokens before any model reads the screen, so the agent works the payment page from ACCT_001 and ROUTE_001 for the whole run. Real values resolve only at the approved destination, at the moment a named person approves the release, which is the payment authorization step and not the confirmation page. Every screen the model read, every action and every approval goes to a record that exports to the organization's own monitoring.
None of that requires the agent to be trustworthy, which is the point: the design assumes a successful injection and limits what the injection can reach. The lab that studies agent infrastructure puts it plainly: "trustworthy agent automation cannot be solved at a single layer of the stack" (Columbia University DAPLab, 2026), and the payment case shows why. A role governs who may release. A log governs what can be reconstructed. Only a control at the rendered page governs what the model received before either of those applied (What Is an Approved Destination for AI Agent Output?). Governance also has to vary by workflow, which Who Approves High-Risk AI Agent Workflows? sets out.
What the record shows
An approval at the release is the only point where a tax payment, a bank account and a named person meet, and the pages reviewed document two of the three. BILL and NetSuite describe who may authorize a payment and what a vendor record needs before one can leave; EFTPS describes an enrollment that ends with a PIN in the mail to one person. What the model receives when the payment page renders is not described in the pages reviewed, which is why a vendor's documentation cannot settle who should approve. The answer the record supports is the controller, on the release, after the page has been reduced to tokens and before the real account number reaches the tax authority. A controller can check this on one workflow: run a test payment with a placeholder account, capture what the model read, then compare that capture with the approval record and the bank's debit.
Methodology and limitations
This page rests on the EFTPS guidance for the payment route, the BILL and NetSuite help pages for the payables roles and the vendor record, a supplier registration guide for the form where a tax identifier and a bank account meet, AWS guidance for the audit attribute, three research preprints and one lab page. Vendor pages were read between October 16, 2026 and October 22, 2026, and each Sources line carries the date for its page.
None of the products on this page was tested hands-on. The product statements come from the documentation as published on the dates cited, and a feature that ships after those dates is unreviewed until the check above is repeated. The example describes a record type, a controller approving the release on a payment authorization screen, not an organization. RedactSure is deploying now with enterprise and government customers. Determinations about whether a payment flow meets a tax, banking or records requirement belong to counsel, assessors and the organization's own compliance officers.
Frequently asked questions
Who approves an AI agent's tax payment?
A named person at the release, not the person who connected the agent. The pages reviewed put payment authority in a role, such as the BILL Administrator with signing authority on the bank account or a NetSuite user with Edit level on the ACH permissions (BILL, 2025; Oracle NetSuite, 2026). Neither page describes what the model is shown when the payment screen opens, so the buyer defines the approval: the controller who releases the debit, on the page the model read.
What does the model read on an EFTPS payment page?
The fields EFTPS renders: the EIN or SSN, the PIN and the password at sign-in. Enrollment comes first, and the PIN arrives by mail at the IRS address of record. Sign-in runs through Login.gov or ID.me before the taxpayer types the identifier and the credentials. Nothing on the page distinguishes a person from an agent, so the browser draws the same values for either.
Can an agent schedule a payment without the PIN, and who approves it?
Not through EFTPS as documented. Enrollment is the gateway, the PIN arrives by mail in five to seven business days at the address of record, and sign-in collects it with the password. An agent can hold the PIN as a credential and fill the field, which is a custody question. What the PIN does not do is record who approved the release, because the tax system never asks.
What record should the approval leave?
One that names the approver, the amount, the settlement date and what the model read on the payment page. AWS's guidance states that "audit logs attribute every action unambiguously to either an agent or a human actor" (AWS, 2026), which covers attribution and not exposure. The visibility research adds identifiers, monitoring and activity logging (Chan et al., Visibility, 2024). The check is whether the record shows the tokenized account value beside the approver's name.
Do BILL and NetSuite approve the payment for you?
No. They document who inside the product may authorize a payment and what a record needs before one can leave; the decision to release belongs to a person in the customer's process. NetSuite can submit a payment to BILL on its next sync, and a BILL Administrator can authorize it, which is a chain of permissions rather than an approval attached to the page the model read.
What should a controller ask for in writing before an agent pays tax?
Which values on the rendered screen the model receives, where the real account number resolves, who approves the release, and what the record holds afterward. Ask per screen, because the payment page, a saved-payee page and the confirmation page show different values. Ask who the approver is when the agent runs unattended, and whether the approval is a role permission or a named signature on a debit. Ask for the answer in writing before the first run, not after the first debit.
How RedactSure Keeps the Account Number Off the Payment Page
An agent can schedule a tax payment the moment it reads the account number, and every control reviewed above governs the role rather than what the model saw.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the payment page, reads the EIN, routing number and account number, and schedules the debit. Inside: the page renders ACCT_014 and ROUTE_014, the agent schedules from those tokens, real values resolve only when the controller approves the release, and the record shows the tokenized page beside the approver's name.
RedactSure is deploying now with enterprise and government customers. EFTPS still mails the PIN to one address, so the person enrolled stays the person the system can name.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A tax debit cannot be pulled back once the Treasury accepts it. Bring one payment your team schedules and see, with test values, what the model reads and who approves the release. Book a demo