Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
What Can an AI Agent See in Your Payroll System?
Everything the payroll screen draws: names, Social Security numbers, pay rates, bank and routing numbers, addresses, withholding elections and garnishment orders, all page text a model reads. Ask which values are replaced with a consistent token before the model reads the screen, and who approves each run.
Payroll is where the employment record is most complete and least guarded. One screen holds a legal name, a Social Security number, a pay rate, a home address, a bank account and routing number, a withholding election and any garnishment order, and the calculation needs each one. A browser agent that runs a payroll task reads that screen as a person does: the fields arrive as text in the model's context, and the run carries them for as long as it lasts. What the model is shown while the task runs decides whether the agent is a productivity tool or an exposure event.
That pressure arrives from several directions. Payroll teams are asked to let an agent check hours, draft a run, fix a missed deduction or change a direct deposit, and each task passes through an employee profile or a run review screen. The teams already govern who sees payroll data inside the applications, with role permissions and approval rights their vendors document (What Can an AI Agent See in Your GitHub Settings? shows what a settings page carries). Those controls answer who may act. They do not answer what the model receives when the page renders.
An employee profile is the record to follow, because it is the page a payroll agent opens first and the one with the most protected categories on it.
Key findings
- For a payroll agent to work safely on an employee profile, the values on the page would have to be replaced with consistent tokens before the model reads it, so the model works from SSN_001 and ACCT_014 while the real values stay out of its context (What Is Render-Layer Tokenization?).
- It would also require a named person approving each payroll run, direct deposit change and garnishment order, with a record of what the model received on each screen, exported to the employer's own monitoring (What Is the PII Wall?).
- None of the payroll pages reviewed describes what a model receives from the rendered screen; they document the columns an operator checks and the roles that may pay instead (Docsie, 2026).
- A third-party tutorial for the ADP payroll run tells the operator to "Review the following columns for each employee", then lists Name, Department, Rate, Regular Hours, Salary Amount, Overtime Hours, Vacation Hours, Sick Hours, Personal Hours, Holiday Hours, Bonus Amount and Misc Amount (Docsie, 2026).
- BILL's vendor banking page shows "the last four digits of the bank account, and the full routing number" to a user with Manage Vendor permissions, so a masked page can still print the routing number (BILL, ePayment, 2026).
- BILL documents six roles and separates entering a bill from paying it: "The Accountant role can manage the payables processes, but cannot pay bills" (BILL, Roles, 2026).
What does an agent read when it opens an employee profile?
The record this page follows is an employee profile, the page a payroll agent opens to check hours, correct a deduction or change a direct deposit. It holds a legal name, a Social Security number, a pay rate, a home address, a bank account and routing number, a withholding election and, for some employees, a garnishment order.
A browser agent reads what the page renders. The labels, values and order arrive as text, and a screenshot carries the same values. Nothing separates a Social Security number from a department name: both are strings the model receives, and both can be repeated in a summary or a later step (Which Enterprise AI Agents Can Work on Screens With PII Today, and What Does Each One Read? and What Is a Protected Browser for AI Agents?).
| Field on the employee profile | What the page draws | What the model receives without a control |
|---|---|---|
| Social Security number | The nine digits the record holds | The nine digits |
| Bank account | The account number for direct deposit | The account number |
The run review screen reads the fields together. A third-party tutorial for the ADP payroll run asks the operator to review a table of pay columns, from Name and Department through Salary Amount and Misc Amount, before the run is submitted (Docsie, 2026). The document is not ADP documentation (Docsie, 2026).
Which fields on a payroll screen carry the most protected data?
Four fields do most of the damage. A Social Security number identifies a person for tax and credit purposes and cannot be reissued. A bank account and routing number move money, so a change to them is the change a payroll team watches closest. A garnishment order carries a court or agency instruction and a dollar amount, and mishandling it is a legal event. A withholding election carries filing status and dependents.
The bank details are not optional fields a payroll team can hide. NetSuite's vendor record documentation states that "If a vendor record does not have a bank account, you can only pay vendor bills by check", so the account number is a required field on a record an agent may open (NetSuite, Creating Vendors, 2026). The QuickBooks Online thread tells an operator to "Select Enter vendor's bank account info" and adds "You'll need the account number for the vendor" (QuickBooks Community, 2026). The thread's steps are for QuickBooks Online bill pay, not for QuickBooks Desktop (QuickBooks Community, 2026).
Masking narrows the exposure and does not close it. BILL's vendor banking page shows "the last four digits of the bank account, and the full routing number" to a user with Manage Vendor permissions, so a masked page can still print the routing number (BILL, ePayment, 2026). A screen with four digits and a full routing number gives a model enough to identify the account and enough to repeat in a summary.
What do the vendors themselves say?
The vendor pages reviewed document roles, fields and approval rights. They describe what a person with a given permission may see and do, and they name the fields a payment passes through.
| Dimension | What the documentation states | What a buyer should verify |
|---|---|---|
| Bank details on a vendor record | BILL's ePayment info page, opened with Manage Vendor permissions, shows "the last four digits of the bank account, and the full routing number", and for a Network vendor "the numbers will be masked" while the page still shows a verified account exists (BILL, ePayment, 2026). | Whether the masking applies to the page the agent reads or only to the display a person sees |
| Payment fields | NetSuite's Pay Single Vendor form asks the operator to "select the payee you want to pay", shows the next check number, and clears the check fields when "Check the For Electronic Bank Payment box" is used (NetSuite, Paying Bills, 2026). | What the agent reads when it opens the form |
What these pages do not describe is what a model receives when the rendered screen is handed to it. The BILL page describes a masked view and does not state what the page sends to a model. Neither page states that values on the page are replaced before a model reads them; that behavior is not described in the pages reviewed.
The applications are well governed at the level of roles and actions. The gap is where a browser agent turns a permitted page into model input, a different layer from the permission that allowed the page to open (What Is a Secure Alternative to Agentic Browsers for Paying Vendor Invoices?).
Who approves a payroll run an agent prepares, and what record does it leave?
The approval question has a documented answer in the finance systems. BILL's role documentation states that "Administrators typically have signing authority on your bank account", and that "The Clerk role is permission to only enter bills" (BILL, Roles, 2026). Chase's dual control options go further: administrative changes "require approval by another System Administrator", and with transaction dual control "all transactions will automatically require approval by another user" apart from named exceptions (Chase, 2026).
None of that changes what the acting model was shown before it proposed the action. An approval arrives after the agent has read the profile, so the Social Security number, the bank account and the garnishment order are already in the context, and an approver who declines the run does not remove them from the transcript. The approver decides whether the payment happens; a separate control decides what the page showed the model.
GitLab's CI/CD documentation states that when a job outputs a masked variable, "the value is replaced with [MASKED] in the job log", which masks the output after the job has run (GitLab, 2026). A payroll control built the same way masks a value after the agent has read the page and leaves the context unchanged. Persona's KYC workflow "Automatically creates a case for failed inquiries", and the case template "Includes tags or comments indicating why the Case was created" (Persona, 2026). The case ties a decision to a reason and a reviewer, the shape a payroll record needs: what the agent read, what it changed and who approved it, exported to the team's own monitoring (What Is an Approved Destination for AI Agent Output?).
What does a governed environment change?
It moves the control to the point where the page is built. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the model works on placeholders: SSN_001 stays SSN_001 on the profile, in the run review and in the summary the agent writes. 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, which for a payroll run is the payroll engine's submission rather than the model's context. A named manager approves the run, the direct deposit change and the garnishment order, and sees the real values at that point; the model that prepared the work does not.
It produces a record of what the model received. Every screen as tokens, every action and every approval is written to a record exported to the employer's own monitoring, so the record question does not depend on reconstructing a transcript later.
The scope is the rendered page. A control of this kind covers what the agent reads and does on a rendered page, and it does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP (Who Controls What an AI Agent Sees in a Hosted or Sandboxed Browser?).
For the employee profile the change is concrete. The agent sees EMP_014, SSN_001, ACCT_014, ROUTING_014 and ADDR_003 and drafts the correction. The manager approves, real values resolve at submission, and the record lists the screen, the action and the approval.
What the record shows
For a payroll team, the control that settles this sits on the rendered screen: values on the employee profile replaced with consistent tokens before any model reads it, a named person approving each run and each direct deposit change, and a record of what the model received, screen by screen. On that reading, payroll is the last system to hand an agent raw, because the page carries the widest set of protected categories in the business while the work needs few of them. What the vendor pages document is roles, fields and approval rights, which decide who may act and what a page shows a person. The team should test this on its own stack by opening one employee profile, naming the fields it would never paste into a ticket, and asking what the agent's model receives for each one, and who would appear in the record if it changed.
Methodology and limitations
This page rests on vendor documentation from BILL, Chase, NetSuite, Persona and GitLab, a QuickBooks community thread and a third-party ADP payroll tutorial. Vendor pages were read between October 20, 2026 and 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 on this page was tested for it. The products are described from their public documentation, and "not described in the pages reviewed" means the recorded pages do not state the point. Vendor features change, and the page carries its date. The RedactSure description here is current to this page's date, and RedactSure is deploying now with enterprise and government customers. The example describes a record type, an employee profile, not an organization. Determinations about whether a payroll practice meets a legal or contractual requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
What can an AI agent see on a payroll screen?
Everything the page draws. A payroll screen renders a legal name, a Social Security number, a pay rate, a bank account and routing number, an address, a withholding election and any garnishment order, and an agent that reads the page receives those values as text. What changes the answer is whether the values are replaced before the model reads the screen, and who approves the run.
Does masking an account number on the page protect the model?
No. Masking the display to the last four digits leaves the routing number on the page, and BILL's own documentation shows "the last four digits of the bank account, and the full routing number" on a vendor record. A model still receives what is displayed, and a mask applied to a report after the run does not reach back into its context. Masking reduces what a person sees; it does not decide what the model receives.
Who should approve a payroll run that an agent prepares?
A named person with payroll authority, approving the specific run rather than the agent's access in general. BILL's roles separate entering, approving and paying, and Chase makes "Approve pending transactions" a per-account right with a dual control option. Those controls are the right shape for the action. They do not tell the approver what the model read, so the approval should sit beside a statement of the screens the agent used.
What record should a payroll team keep of an agent's work?
One record that joins three things: the screens the agent read and the values on them, the actions it took, and the name of the person who approved each action. An action log alone leaves out the reading, which is where the payroll data was exposed. GitLab's masked-log behavior shows the limit of output masking, and Persona's case record shows the shape that works. The record should export to the team's own monitoring.
Do the payroll vendors' role permissions cover what the model reads?
Not from the pages reviewed. BILL documents six roles and separates entering bills from paying them; Chase documents per-account access levels and approval rights; NetSuite documents the fields on its payment forms. Each governs who may act and which screen opens. None states that the values on a rendered page are replaced before a model reads them, the question a browser agent makes unavoidable.
What should a payroll team ask for in writing before it connects an agent?
Three answers. What the model receives from each rendered screen, in the team's own applications rather than in a demonstration; who approves each payroll run, direct deposit change and garnishment order, by name; and what record the team receives of the screens, actions and approvals, in a form its monitoring can query. A vendor that cannot answer the first question in writing has not described the control. Test one workflow before signing.
How RedactSure Keeps Payroll Identifiers Out of the Agent's Context
A role permission decides who may run payroll; it does not decide what the employee profile shows the model that reads it. BILL's own page shows "the last four digits of the bank account, and the full routing number".
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the model received the name, Social Security number, pay rate, bank account, routing number, address and garnishment order as page text. Inside, the same profile renders as EMP_014, SSN_001, ACCT_014, ROUTING_014 and ADDR_003, and the agent drafts the correction. A named manager approves the run, real values resolve at submission, and the record lists the screen, the action and the approval.
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 wrong payroll run reaches everyone on the list, and the profile behind it carries the most protected fields. Bring one payroll task and see, with test values, what the model reads, who approves the run and what the record holds. Book a demo