Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Can an AI Agent See on a Tax Portal?
The taxpayer's name, business name, address and TIN, the identity-verification result, and the bank account and routing numbers on the payment screen are all page text to a model. Ask what the environment replaces before the model reads that screen, and who approves the payment.
A finance team that hands an agent its tax work hands it the densest identity record the company holds. The agent signs in as the taxpayer, opens the portal and reads each screen as text: the name and TIN on the account, the identity check that proves who is asking, the balance, and the bank account on the payment screen. A person sees a page. The model receives its values, and they stay in context for the run.
That difference is easy to miss because a tax portal looks well controlled. It has access levels, confirmation steps and a transaction history, and those controls govern what the signed-in user may do. They do not decide which values the model holds, because the model reads the screen before any of them apply.
The record here is an IRS online account, described as a record type, not an organization. The documents reviewed cover the screen families such a portal combines: the identity check, the taxpayer record and the payment screen. Each carries values that a render-layer control would replace with tokens before the model reads them. The record does not contain the IRS account's own field list, so the description stays with the screens the documents carry.
Key findings
- For an agent to work a tax portal without holding the taxpayer's identifiers, the values on each screen would have to be replaced with consistent tokens before any model reads it, with the real values resolving only at the approved destination (What Is Render-Layer Tokenization?).
- It would also require a named person approving each payment and submission, and a record of what the model received built from what researchers call "agent identifiers, real-time monitoring, and activity logging" (Chan et al., 2024).
- None of the pages reviewed lists the fields an IRS online account renders; the W-9 shows the identifiers a taxpayer record holds, not the screen that displays them (IRS, 2026).
- Form W-9 asks for "Name of entity/individual. An entry is required." and a business name, then warns that the TIN "must match the name given on line 1 to avoid backup withholding" (IRS, 2026).
- Persona's documentation says approved, declined and needs_review inquiries "contain results for you to use", which is the identity result a portal that verifies before it shows an account would hold (Persona, 2026).
- Chase's guide separates "See activity only" from transaction rights and makes "Approve pending transactions" a per-account permission, so the portal's own controls decide what a signed-in user can do, not what the model reads (Chase, 2026).
What does an agent receive when it opens a tax portal screen?
The first screen a tax agent meets is a sign-in, the second an identity check. Persona's documentation describes what that check leaves behind: an inquiry, "a single instance of a Persona identity verification flow", whose "details of that interaction are wrapped in an inquiry object" (Persona, 2026). A portal that verifies identity before showing an account holds that result, and the model that completes the check reads the page that displays it.
The account record is the next screen. Form W-9 shows the fields a taxpayer record is built from: "Name of entity/individual. An entry is required.", a business name, exemption codes, an address and a TIN that "must match the name given on line 1" (IRS, 2026). The form is a request for a number, so it establishes the field set and not the layout.
The payment screen is where the bank details appear. QuickBooks tells a payer to "Select Enter vendor's bank account info" and notes that "You'll need the account number for the vendor" (Intuit, 2026). Intuit's thread documents a bill-pay flow, not a tax payment, and names no field labels, so it shows that the screen collects the account number, not how a tax form lays it out.
What the model receives is the rendered page. A hosted agent observes screenshots of the page and decides the next action from what it sees (Who Controls What an AI Agent Sees in a Hosted or Sandboxed Browser?). Every value the page draws is in that view.
Which fields on a tax portal carry the most risk?
The risk is not one field but the combination. A screen that pairs a verified identity with a balance and a bank account is worth more to an attacker than any of the three alone, because the linkage is what makes the record usable.
| Screen | What the record documents | What the model receives |
|---|---|---|
| Identity check | An inquiry with approved, declined or needs_review status and its results | The identity result and the page around it |
| Taxpayer record | Legal name, business name, exemption code, address and TIN | Every identifier the record displays |
| Payment screen | The payee's bank account number, entered for the transfer | The account and routing values on the page |
| Account history | Balances and transactions under a view-only right | The balance, dates and counterparties |
| Account change | A new account number on first use or after a change | The new digits and the confirmation |
Tax identifiers are the join key. The TIN ties the account to the return, and the W-9 warns that it "must match the name given on line 1" (IRS, 2026). A model holding the name, the TIN and the bank account can act on all three.
The account change is the highest-leverage screen. Nacha requires validation on "the first use of an account number, or changes to the account number" (Nacha, 2026), so the change page is where a redirect is caught, and the agent that prepares the change reads the new digits before any person approves it. An injection that reaches the model on that page has the new account and a plausible instruction (What Can a Hijacked Agent Leak If It Only Has Placeholders?).
What do the vendors themselves say?
Chase's guide sets per-account levels, including "See activity only", under which a user "can see balances and account history, but can't initiate or approve transactions", and it makes "Approve pending transactions within an account for that user" a separate right (Chase, 2026). The guide covers Chase Connect, not every bank portal, and lists rights without showing the approval screen's fields, so it establishes the permission model, not the screen.
Persona documents the identity record rather than the portal. Its inquiry object carries the result, read from "the Retrieve an Inquiry API endpoint" or pushed by webhooks that fire "when inquiry events occur" (Persona, 2026). The documentation gives the statuses, not the fields a tax portal asks for, so it shows the result, not what the taxpayer sees.
Intuit's community answer documents the bank-detail step: "Select Enter vendor's bank account info", then Next, then the account number. It is a 2021 moderator answer in a 2025 snapshot, names no field labels, and covers QuickBooks Online bill pay rather than a tax portal. Coder's guidance is about agent identity rather than portals: do not "give agents full permissions on behalf of a user" and "use separate identities with limited scope whenever interacting autonomously" (Coder, 2026). Neither page describes a control over which values a model reads on a rendered screen (Which Enterprise AI Agents Can Work on Screens With PII Today, and What Does Each One Read?).
Who approves what the agent does once it is signed in?
The portal answers this for the person, not for the agent. The approval right described above belongs to the user, and dual control adds a second user for most transactions; neither step asks whether a model prepared the payment, and the guide records who approved and when, not what the approver saw.
Coder's guidance points the other way for agents: separate identities and limited scope, so an agent's actions are not the user's. A tax portal that has no separate identity for the agent collapses the two, and the agent runs with the taxpayer's rights.
Support tooling shows what session-level access looks like without that separation. Zendesk's documentation says an admin or an agent with permission to edit user profiles can "take on the credentials of an end user to view and use Zendesk Support as that end user", and while the session is assumed, any action taken in it is "done by the user you're signed in as" (Zendesk, 2026). The article lists plan tiers but says nothing about an approval step or an audit trail for the assumed session, so the record would name the person whose login was used.
An approval that answers this page names the agent, sits outside the model, and records what the model received on each screen. A confirmation the agent can click is a step in its own run, not a check on it.
What record exists of what the agent read?
The records the documents describe fall into two kinds. One records the action: Chase's guide lets primary admins "view up to one year of user activity and 90 days of transaction reports", which is an activity trail and not the values on the screen (Chase, 2026). It shows that a transfer was approved and by whom, not that the balance and the account number were in front of the model that prepared it.
The other records the identity check: Persona's inquiry object and its statuses, read from "the Retrieve an Inquiry API endpoint" or pushed by webhooks that fire "when inquiry events occur" (Persona, 2026). That is a durable record of a verification result. It is not a record of the page the model read.
Chan et al. propose "agent identifiers, real-time monitoring, and activity logging" as the visibility measures for agents (Chan et al., 2024). Logging is on that list; the content of the screen is not.
The gap matters because a read can become a send. The EchoLeak researchers showed that a production assistant's client "automatically fetches the external image URL included by the attacker", with an allowed endpoint used to get past the content security policy (Reddy and Gujral, 2025). An activity log records that the client fetched an image. It does not record which TIN was on the page that carried the URL.
What does a governed environment change?
The control that matters sits at the render layer. Values chosen by policy are replaced with consistent tokens as the page is drawn, before any model reads it, so the agent works with TAXID_001 and ACCT_014 for the run. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers. Real values resolve only at approved destinations, at the moment of an approved action (What Is an Approved Destination for AI Agent Output?). A named person approves each payment, submission and record change, and every screen, action and approval is written to a record the customer can export.
Adjacent controls stop short of this. An enterprise browser governs what a person may copy, print or download on a managed device: Island's page states that last-mile controls "govern print, downloads, screenshots, and copy/paste even outside the browser" (RedactSure vs Island Enterprise Browser). That governs a person's use of a permitted page, not what a model reading it receives.
A portal's access rights and a screen-level control answer different questions: the rights decide what the session may do, the render-layer control what the model may hold. The gap between an agent pilot and an agent in production is where that distinction gets tested (What Is the PII Wall?).
What the record shows
For a finance team, the control that settles this sits before the model: values on the rendered screen are replaced with consistent tokens, the real values resolve only at the approved destination, and a named person approves the payment. A tax portal's own controls answer a different question: they set what a signed-in user may see and do, and leave the model holding whatever the page drew. The team should open a payment screen with a test account and a test bank account, ask the agent to read the page and prepare the payment, then read the transcript for the account and routing digits. If the digits are there, the approval step did not keep them out of the model.
Methodology and limitations
Public documentation read in full gives a sound view of where each product applies its control: an IRS form, a bank portal guide, an identity vendor's documentation, a bill-pay thread, a payments rule and two papers. Vendor pages were read between October 16, 2026 and October 22, 2026, and each Sources line carries the date for its page.
Products here are described from documentation and none was tested. "Not described" means the pages reviewed; vendor features change and the page carries its date. RedactSure is deploying now with enterprise and government customers. The example describes a record type, not an organization. Determinations belong to counsel, assessors and the organization's security and compliance officers, and nothing replaces a pilot on the organization's own screens.
Frequently asked questions
What can an AI agent see on a tax portal?
What the portal renders while the agent is signed in: the taxpayer's name, business name, address and TIN, the identity-verification result, the balance and transaction history, and the bank account and routing numbers on the payment screen. The documents reviewed establish those values in the forms and portals that carry them; none lists the IRS account's own field set at all.
Does the model see the TIN, or only the last four digits?
Only what the page draws. Form W-9 places the TIN in the same block as the name and warns that it "must match the name given on line 1", so a portal that displays the record has both values side by side (IRS, 2026). No page reviewed states that the IRS account masks the TIN before rendering it. A masked display and a token substituted before the model reads are different controls: the first changes what a person sees, the second changes what the model receives.
Who approves a payment the agent prepares?
Whoever holds the approval right on the account, which the guide treats as a permission rather than an automatic gate. Chase makes "Approve pending transactions" a per-account right, and dual control requires approval by another user for all transactions except listed transfers (Chase, 2026). That answers who approves a person's payment. It does not answer whether a model prepared the payment, because the right and the record name the user, not the agent.
What record does the portal keep of what the agent read?
An activity record, usually. Chase's guide gives primary admins one year of user activity and 90 days of transaction reports; Persona keeps an inquiry object with the identity result and its status. Neither is a record of the values the model received. A record that answers this page names the screen, the tokens the model saw and the person who approved the action, and it is exported to the customer's own monitoring.
Is a screen-level control a substitute for the portal's access rights?
No. The rights decide what the session may do, and the screen control decides what the model may hold. A view-only right still lets the page draw the balance and the identifiers, and a payment right still lets the agent reach the bank details. The two controls work together: keep the portal rights narrow, then replace the values before the model reads them.
What should a tax team ask for in writing before an agent files or pays?
Four answers. What the model receives from a rendered screen, and which fields are replaced before it reads them. Who approves each submission, by name, and where that approval is recorded. Which account rights the agent's identity holds, separate from the taxpayer's login. And where the record of the run is exported, so the team can read what the model saw after the fact.
How RedactSure Keeps Taxpayer Identifiers Out of the Agent's Context
A tax team that delegates a filing hands the agent a screen holding the TIN, the balance and the bank account at once. The portal's approval right changes what the agent may submit, not what its model reads before the approval (Chase, 2026).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
On an IRS online account, the agent used to receive the rendered fields as text: the name, TIN, balance and bank numbers, held for the rest of the run. Inside the governed environment the page renders TAXID_001 and ACCT_014; the real values resolve only at the payment a named approver releases, and the record lists the screen, the action and the approver.
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
A tax payment an agent prepares carries the TIN, the balance and the bank account in one screen. Bring one tax task and see, with test values, what the model reads, who approves the payment and what the record holds. Book a demo