Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is It Safe to Let an AI Agent Pay Your Taxes on IRS Direct Pay?
No, Direct Pay collects the taxpayer's name, Social Security number or EIN, and bank routing and account numbers on the form an agent reads, so the model holds them unless they are replaced with tokens such as SSN_001 before it reads. Check what your agent's view of the page contains, then put a named person on the submission.
An owner who lets a browser agent make a quarterly estimated payment on Direct Pay hands it the taxpayer's identity and bank details. There is no sign-in step, so the agent starts from an empty form and types those details in. The form asks for the name and address on a prior return, the Social Security number or the employer identification number, the bank routing number, the account number and an amount.
Those values are not a login. The name, address and SSN are the identity check the service runs against an earlier return, and the routing and account numbers are where the money leaves. A model that reads the rendered page holds all of them for the rest of the run, and a value it holds can appear in a transcript, a summary or a retry. The record here is one quarterly estimated payment, with the filer's identifiers in the fields.
The difference that decides the answer is between a credential a tool can withhold and a value a page has to render. A password manager or a token vault can keep a stored credential out of the model's hands; it cannot blank out a field the agent must fill. What matters is what the model receives from the page itself.
Key findings
- For an agent to pay a quarterly estimate on Direct Pay without holding the filer's identifiers, the SSN or EIN and the bank account numbers would have to be replaced with tokens such as SSN_001 before any model reads the screen (What Is Render-Layer Tokenization?).
- It would also require a named person approving the submission and a record of what the model received on each screen, because a confirmation records the payment and not the reading (What Is Least Exposure?).
- The Direct Pay pages list the identity fields a payer enters, and no page reviewed describes a layer between the rendered form and the model that reads it (What Is a Protected Browser for AI Agents?).
- Direct Pay asks for the taxpayer's name, address and Social Security number, or a business name and EIN, for every payment (IRS, Help, 2026).
- The route the IRS names for larger payments, EFTPS, needs enrollment and a PIN mailed in five to seven business days, and its payments must be scheduled the day before the due date (EFTPS, 2026).
- Injections that ask an agent to leak personal data seen during a task reached "average attack success rates (ASR) around 20 percent", which is the risk a rendered SSN and account pair carries (Alizadeh et al., 2025).
What does the Direct Pay form put on the screen?
The flow starts with the payment type. The business path covers "Pay balance due, federal tax deposits and other federal income tax", one payment "can't exceed $10 million", and anything larger goes to "the Electronic Federal Tax Payment System (EFTPS) or same-day wire" (IRS, Bank account, 2026).
The identity block is where the sensitive values sit. For each payment the payer enters "name, address and social security number (or, for businesses, business name and EIN)", and the service checks those details against a prior return the payer chooses (IRS, Help, 2026). The bank block follows, and "IRS Direct Pay requires a U.S. bank routing number (ABA)" (IRS, Help, 2026). The form is refilled for every payment, so a second estimate means the same identifiers again.
The combination is ordinary on business forms. A supplier registration guide asks for a tax ID under an entity type, with Individual reserved for suppliers using "a government issued identification number" such as a US social security number, and it makes "Bank account information must be included" a condition of electronic payment (Suntory Global Spirits, 2025). The record for this page is one quarterly estimated payment: a name, an address, an SSN, a routing number, an account number and an amount, all on a page the agent reads before it submits.
What does the model receive when it reads that page?
The model receives the rendered page, not the markup behind it. Every layer that inspects a request finishes its work before the page is drawn, and until agents arrived "nothing but a person ever read a rendered page" (What Is Render-Layer Tokenization?). An agent reads the rendered page, so the identity and bank values enter its context as it fills them.
Least privilege does not reach this. It "does not govern the content of the screen an agent reads", so an agent can pass a least-privilege review while holding every field on the form (What Is Least Exposure?). A policy that limits which screens the agent may open leaves the values on them untouched.
A fill tool can keep a value out of the model's hands for the typing step. Browser Use's documentation says "the LLM only sees placeholders (x_user, x_pass)" and that "real values are injected directly into form fields after the LLM call", which settles the fill and says nothing about the page after it (Can a Browser Agent Fill In a Form Without Seeing the Values?). Direct Pay adds a second reading: the identity data is re-entered for each payment, and the confirmation is a payment record rather than a record of what the model saw.
What do the vendors themselves say?
1Password's browser-agent page describes custody for credentials: "the AI agent and underlying LLM never need to see nor handle the credentials", which are injected "if, and only if, the human approves the access" (1Password, 2025). That covers a password or a key the product holds. It does not cover an SSN the page requires as form data, because there is no stored credential for the product to withhold and the agent types the value itself.
AWS's AgentCore Identity vault is built to "Securely store OAuth 2.0 Access and Refresh tokens, API keys", and the agent retrieves them with its own workload token (AWS, 2025). The indirection is the point: the model asks for the credential and never handles it. A tax form has no such indirection, because the value in the field is the value the model typed.
| Dimension | 1Password, per its documentation | What a buyer should verify |
|---|---|---|
| What it protects | Credentials the agent never handles | Whether an SSN typed into a form is a credential at all |
| When a person acts | Injection happens only when the human approves the access | Whether that approval covers a form the agent fills |
| Scope | Credential injection for a browser agent | Whether the page after the fill is governed |
| Record | No record of form values described | What the model read on the Direct Pay screen |
Read together, the pages cover what an agent presents to a service, not what a page presents to an agent.
Do caps, confirmations or the two-day window make it safe?
None of them changes what the agent reads. The $10 million cap and the five-payment daily limit govern the size and count of payments (IRS, Bank account, 2026; IRS, Help, 2026). A confirmation is produced after the submit, and "Change or cancel within 2 days of scheduled payment" is a chance to reverse the payment rather than a way to unread the form (IRS, Bank account, 2026).
EFTPS is the other route the IRS names, and it does have gates: enrollment is required, a PIN arrives by mail in five to seven business days, sign-in runs through Login.gov or ID.me, and payments must be scheduled the day before the due date, though since October 17, 2025 individuals cannot create new enrollments there (EFTPS, 2026).
A gate decides whether a run reaches the screen. It does not decide what the screen shows once the run is on it, and an agent handed the PIN and password reads the same fields a person would. Direct Pay has no such gate: "No sign-in required" (IRS, Bank account, 2026), which is why the identifying data is typed fresh on every payment.
A saved payee is not the answer either. There is no sign-in to inherit, and the identity fields are entered for each payment rather than drawn from a profile. A limit applies to the payment, not to the fields the model receives while it builds one. The only setting that changes the answer is the one that changes what the page shows the model.
What can a hijacked agent do with a tax form it can read?
An agent that reads a page can be steered by what is on it. Prompt injection attacks "enable adversaries to remotely (without a direct interface) exploit LLM-integrated applications", so the attacker never needs the agent's password or the filer's consent (How Do Attackers Steal Credentials Through Prompt Injection?).
Published defenses have not closed that exposure: adaptive attacks got past most of the 12 tested, more than 90% of the time (How Often Do AI Agents Follow Injected Instructions?).
The measured risk to personal data is direct: injections that ask an agent to leak personal data observed during a task reached "average attack success rates (ASR) around 20 percent" (Alizadeh et al., 2025). A tax form concentrates that target, because the SSN identifies the filer and the bank pair can move money.
A payment task can also move without a visible hijack: "We define this deviation as task drift." (Abdelnabi et al., 2025). An agent told to pay the third-quarter estimate can end up paying a different amount without any single step looking wrong.
The leak is bounded by what the model holds: an agent working from placeholders has nothing real to send (What Can a Hijacked Agent Leak If It Only Has Placeholders?). A browsing-agent study reports that untrusted web content can "hijack agent behavior", and its findings "include prompt injection, domain validation bypass, and credential exfiltration" (How Do I Control Where a Browser Agent Can Submit Data?).
The losses differ in how long they last. A bank account can be closed and a routing number replaced, while the SSN remains the identifier the service checks against a prior return and the key to the next filing (IRS, Help, 2026). A run that reads the form hands over both.
What does a governed environment change?
The control that changes the answer sits before the model, on the rendered page. Values a policy names are replaced with consistent tokens as the page is drawn, so the agent works from SSN_001, ACCT_001 and ROUTE_001 for the whole run (What Is a Protected Browser for AI Agents?). The real values resolve only at the approved destination, the IRS form a person released.
A named person approves the submission, and the approval is written beside the action, so the record shows what the model received, what it proposed and who released it (What Is Least Exposure?). That record is what a filer can produce when a payment is questioned; a confirmation number shows only the payment.
The scope is the rendered page. A payment posted by API with the SSN in the payload is outside this control, where credentials and scopes govern the call. An agent that reads a PDF of the return is outside it for the same reason.
What a governed environment changes is the content of the model's view: the identifiers become tokens, the destination is approved by a person, and the run leaves a record. The form still asks for the values, and the IRS still receives them. What the model does not hold is the real SSN and the real account.
What the record shows
The value the model receives on the Direct Pay screen decides the answer, and the pages reviewed describe no step that would keep the identity and bank values out of it. A filer who delegates gets a scheduled payment and, if the agent read the form, a model that holds the name, the SSN or EIN and the bank pair. The cap, the five-payment limit, the confirmation and the two-day window all act on the payment; none acts on the reading. The condition that changes the answer is substitution on the rendered page, a named person releasing the submission and an exported record of what the model saw. Run one quarterly estimate with test values, ask what the model received on each screen, and compare that list with the fields on the payment record the IRS returns.
Methodology and limitations
This page rests on the two IRS Direct Pay pages, the EFTPS enrollment page, 1Password's and AWS's browser-agent documentation, two research papers on prompt injection and task drift, and a supplier registration guide. The regulator and vendor pages were read as of October 22, 2026, and each Sources line carries the date for its page. Public documentation read in full gives a sound view of where each product applies its control.
No product was tested for this page. The products are described from their public documentation, and "not described in the pages reviewed" means the recorded pages for that product do not cover the point. 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 quarterly estimated payment, not an organization. Determinations about whether a flow meets a control, audit or tax requirement belong to counsel, assessors and the organization's own security and compliance officers.
Frequently asked questions
Is it safe to let an AI agent pay your taxes on IRS Direct Pay?
No. The form carries the taxpayer's name, address, Social Security number or EIN, and the bank routing and account numbers, and a model reading the rendered page holds all of them. The service takes no sign-in, so there is no credential step that could keep the values out of the agent's context. The answer changes only when those values are replaced with tokens before the model reads the page and a named person releases the submission.
What does the model receive on the Direct Pay screen?
The rendered page: the identity fields, the bank routing and account numbers, the amount and the payment type the agent selected. The model does not need to read the page source; the values appear as it fills them. Least privilege does not help, because reading is not an action a permission rule counts. Anything the model receives can be repeated in a transcript or a later step of the same run.
Who should approve an agent's tax payment?
A named person outside the model, after seeing the amount, the payment type and the account the money leaves. An approval the agent performs on its own is part of the run, not a check on it. The person should release the submission rather than watch it happen, and the approval should be recorded beside the payment. That gives the filer an approver to name if the payment is questioned.
What record should a Direct Pay run leave?
One that answers what the model received, what it proposed, who approved the payment and where the real values resolved. A confirmation number and a cancellation window are records of the payment, not of the reading. Without the screen record, a team can say what it paid and not what the model held when it paid it, which is the gap an auditor will ask about. Export the record to the organization's own monitoring so it survives the agent session and the next review.
Does the cancellation window undo what the model read?
No. Direct Pay lets a filer "Change or cancel within 2 days of scheduled payment", which can undo a payment. It cannot undo the reading. By the time the window opens, the SSN or EIN and the bank pair have been on the model's screen and in its context, and a value in a transcript or a summary stays there. Cancel the payment if it is wrong; do not count the window as a control on exposure.
What should a finance team ask a vendor in writing?
Ask what the model receives from a rendered screen, not which sites the agent may visit. A vendor should state whether values are replaced on the page before the model reads it, which destinations receive real values, who approves a submission and what record is exported. Answers about profiles, allowlists or confirmations describe where the agent goes. They do not say what the screen shows when it arrives.
How RedactSure Keeps a Taxpayer's SSN Off the Agent's Screen
An agent that types an SSN and an account number into a public payment form carries both values for the rest of the run. Injections that ask an agent to leak personal data seen during a task reached "average attack success rates (ASR) around 20 percent" in one study.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens Direct Pay, types the name, address, SSN or EIN, routing number and account number, and submits. Inside the governed environment: the form renders SSN_001, ACCT_001 and ROUTE_001, a named person approves the submission, and the real values resolve only on the form that person released.
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 quarterly estimate is enough to show what the model reads before the submit and what the IRS receives after it. Bring that payment from your workflow and watch the screen, the approval and the record. Book a demo