Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Run Payroll in ADP Without Seeing Employee Salaries?
No, an ADP payroll run renders each employee's rate and salary amount in the rows the agent works through, so a model on that screen reads what everyone earns. Require tokens in place of the pay values before the model reads the page, a named person approving the submit, and a record of what the model received.
A payroll run is a sequence of screens: an entry table where hours and pay arrive, a preview where the totals are checked, and a submit. Each screen prints money beside a name, and the agent is asked to confirm the hours and clear the exceptions, so the salary sits in the same row as the work it has to verify. The run needs the arithmetic, but the screen does not separate the arithmetic from what each person earns. A payroll team that wants the run finished faster, and a security lead who has to say what the agent read, are the two people with something at stake. The first has a deadline, the second has a staff list that would sit in a model's context for the rest of the run. A payroll screen is also the one page where a routine task and a confidential figure share a row, so the answer turns on what the page renders rather than on how carefully the agent is prompted. The example is one record type, an ADP preview screen, and the same test applies to any payroll system that renders a table of people and amounts.
Key findings
- For an agent to run payroll, the rate and salary amount columns are figures the run settles, so they are not tokenized; the employee names and identifiers beside them are replaced with consistent tokens before any model reads the entry and preview screens (What Is Render-Layer Tokenization?).
- It would also require a named person approving the submit outside the model and a record of what the model was shown, because the preview ends in a dialog an agent can clear (What Is Supervised Delegation?).
- No ADP page reviewed describes replacing the pay values before the model reads the run; the vendor's own guide covers the deposit API and leaves approval limits out (ADP, Direct Deposit, 2026).
- The payroll entry table the tutorial reproduces lists Rate and Salary Amount among the columns and tells the reader to "Review the following columns for each employee" before the preview (Docsie, 2026).
- After the preview, "If the system detects an issue, a warning dialog appears asking" whether the payroll looks right, and "Choose Ignore Issues to proceed without changes" continues the run (Docsie, 2026).
- In a study of prompt injection against agents executing tasks, requests to leak personal data the agent had observed reached "average attack success rates (ASR) around 20 percent" (Alizadeh et al., 2025).
What does an ADP payroll run render before the agent submits it?
The run moves through an entry step, a preview and a submit, and each renders a table of employees. The entry table is a grid with one row per person, and the guide lists Name, Department, Rate, Regular Hours, Salary Amount, Overtime Hours, Vacation Hours, Sick Hours, Personal Hours, Holiday Hours, Bonus Amount, Misc Amount and Misc Reimb (Docsie, 2026).
Contractors get a narrower version: "The contractor pay table includes Name, Department, Rate, 1099Comp Hours, 1099Comp Amount, and 1099 Exp Reimb columns" (Docsie, 2026). The rate sits beside the hours columns, which is why a model typing into an hours field has already received the pay.
A warning dialog appears when the system finds an issue, and the two choices are to proceed or return to the entry screen. An agent receives the dialog, the totals above it and the rows behind them.
OWASP's entry on sensitive information disclosure states what that exposure produces: "Personal identifiable information (PII) may be disclosed during interactions with the LLM" (OWASP, Disclosure, 2025). A salary is personal data about an employee, and the preview holds the whole staff at once, which makes a single screen the most valuable page in the run.
What the model receives is the rendered grid, so the question is not which step the agent is on but which values the page puts in front of it.
Which columns does the run need, and which does it only display?
The task decides which columns matter. Hours work takes Regular, Overtime, Vacation, Sick, Personal and Holiday hours; adjustments take Bonus Amount, Misc Amount and Misc Reimb; a submit needs a complete roster and the exceptions cleared.
None of those steps needs to know what a person earns. The preview is where that changes, because for a salaried employee with no adjustments, the total the system computes is the salary. A team that tokenizes the entry fields and leaves the totals alone has moved the value rather than removed it.
| Column group | What the run does with it | What it reveals |
|---|---|---|
| Regular, Overtime, Vacation, Sick, Personal and Holiday hours | The agent enters and corrects them | Hours worked, not pay |
| Rate | Multiplies hours for hourly staff | The hourly wage |
| Salary Amount | Pays salaried staff | The salary |
| Preview totals | What the system computed for the run | The salary again, for a salaried person with no adjustments |
The table reads one way for a model and another for a person, who sees the hours and the amount together and can ignore the amount. A model given the rendered row receives both fields as text in one string, and the amount is not a page to avoid: it is a column in the row where the hours are entered.
Payables has the same shape. The screens a model reads to match an invoice carry vendor bank accounts and routing numbers, and a model that reads the whole vendor record holds all of it (Can AI Work NetSuite Payables Without Bank Details?). Payroll substitutes a salary for an account number.
A run can be worked from hours and exceptions, and the amount columns, in the entry table and in the preview totals alike, are the ones a token policy has to name.
What do the vendors themselves say?
ADP's documentation in the pages reviewed is a developer guide for direct deposits, and its data dictionary describes the routing field as one that "Indicates the Routing Number to which the Direct Deposit applies" for U.S. clients, and the account field as one that "Indicates the Account Number to which the Direct Deposit applies" (ADP, Direct Deposit, 2026).
It documents a priority value, "Indicates priority value for DirectDeposit", and says the API "is available for ADP Workforce Now clients in the United States (U.S.) and Canada with Payroll features" (ADP, Direct Deposit, 2026).
Its permission model is thin: two role codes are defined, Practitioner and Employee, and "A system user is considered a practitioner" (ADP, Direct Deposit, 2026). That places an agent login in the administrator class, and the guide contains nothing about approval limits for changing a deposit (ADP, Direct Deposit, 2026).
The run screens themselves are documented in a tutorial rather than by ADP, so the column list here is evidence of what the screen carries, not of every field the product renders (Docsie, 2026).
What no ADP page reviewed documents is the run screen, the part of the flow a buyer asking about salaries cares about. The agents a team already runs matter for the same reason, since what each one documents about the page it reads decides what reaches the model (Which Enterprise AI Agents Can Work on Screens With PII Today, and What Does Each One Read?).
Who approves a payroll run, and what does ADP document about the approver?
ADP names the roles but not an approver. Practitioner and Employee are the only codes, and a system user is a practitioner, so an agent's login sits in the class that can work the run.
Workday's payment elections page says a payroll administrator can "Update existing payment elections for the person", and "Workday automatically updates all payment elections with the new account information" (Workday, Payment, 2026). The page describes no approval step before an administrator changes someone's bank account (Workday, Payment, 2026).
Its compensation manual puts a pay rate within reach of a task: "The task can change an employee's package, grade, rate of pay, salary amount, or plans" (Workday, Compensation, 2026).
BILL's role page gives the Administrator "Approve bills" and "Authorize payments" and adds that "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). That separation governs what a person may do; a role decides which screens an agent may open, not what the model receives once one is open.
Payroll approval does not come from the agent layer by default: of the 15 AI agents a documentation review covered, 1 documents asking a person by default before every consequential action and 5 document a per-action record an administrator can export, and ADP's payroll product was outside that review (Do AI Agents Ask Before Making a Payment?).
The FBI's advisory on payroll diversion shows why the login matters: "Cybercriminals target employees through phishing emails designed to capture an employee's login credentials", and once inside, "Direct deposits are then changed and redirected to an account controlled by the cybercriminal" (FBI, 2026).
An agent holding that login inherits both abilities, so the approval this page needs is a named person outside the model.
What does a governed environment change?
A governed environment is a control class that acts where a screen is rendered, before any model reads it. For each task the planner proposes what to tokenize, starting from personal information, account numbers, credentials and record numbers.Values a policy names are replaced with consistent tokens as the page draws, so the employee names and identifiers beside the rate column and the salary amount column render as tokens for the whole run, while the pay figures stay in the run's view because the checks depend on them. Real values resolve only at an approved destination, at the moment an approved action releases them, which here is the approved submit. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.
The run becomes the job it was for: hours entered, exceptions cleared, a submit proposed by an agent that never held an amount. The same substitution that fills a form without giving the model the values fills a payroll grid without giving it the salaries (Can a Browser Agent Fill In a Form Without Seeing the Values?).
OWASP's entry on excessive agency covers the submit, "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM" (OWASP, Agency, 2025), and an agent that read tokens has tokens to give away where it once had salaries (What Can a Hijacked Agent Leak If It Only Has Placeholders?).
The check that each amount is correct moves to the person who approves the run, or to a destination built for that check. What the control class adds is a run that can be worked and submitted without the amounts, and a record of the screens read and who approved the submit (What Is an Approved Destination for AI Agent Output?).
What the record shows
The control that settles this for a payroll team sits before the model: values replaced on the rendered screen, a named person approving the submit, and a record of what the model was shown. On the documentation reviewed, the run is a table of people and amounts, and the vendor's own pages cover the deposit API and two role codes without describing an approval limit. On that record the answer is no: the run's rows print Rate and Salary Amount beside each name, and an agent working the run reads them. The payroll lead should run one preview with test values, write down every column the model receives, then ask where a salary column would be replaced and who approves the submit.
Methodology and limitations
This page rests on ADP's developer documentation for direct deposits, a third-party payroll tutorial that reproduces the run screens, help pages from Workday and BILL, an FBI advisory, two OWASP entries, and one preprint on prompt injection. 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 on this page was tested hands-on. The products are described from their public documentation, "not described in the pages reviewed" means the recorded pages do not cover the point, and vendor features change. The payroll-entry columns come from a tutorial that is not ADP documentation, so confirm them against the tenant's own preview. RedactSure is deploying now with enterprise and government customers. The example describes a record type, not an organization.
Determinations about whether a run meets a control, audit or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers.
Frequently asked questions
Can an AI agent run payroll in ADP without seeing employee salaries?
No, not from the run screens as documented. The entry table lists Rate and Salary Amount for each employee, and the preview repeats the totals, so an agent working the run receives the pay values with the hours. The answer changes when those columns are replaced with tokens before the model reads the page and a named person approves the submit. Until then, the run and the salaries are one screen.
Which columns does an ADP run render for each employee?
Name, Department, Rate, Regular Hours, Salary Amount, Overtime Hours, Vacation Hours, Sick Hours, Personal Hours, Holiday Hours, Bonus Amount, Misc Amount and Misc Reimb, according to the tutorial that documents the flow. Contractors get Name, Department, Rate, 1099Comp Hours, 1099Comp Amount and 1099 Exp Reimb. That tutorial is a third-party guide with 2022 screenshots, so treat the list as evidence and confirm the set on your own preview.
Does ADP document an approval step for a payroll run?
Not in the pages reviewed. ADP's developer documentation defines two role codes, Practitioner and Employee, and states that a system user is considered a practitioner, which places an agent login in the administrator class. That guide covers the deposit API and says nothing about approval limits for a deposit change. Approval may well exist in the product. The reviewed pages do not describe it, so ask the account team for the screen and the sign-off rule.
Can an agent work a run from hours alone?
Only for the part of the run that does not audit amounts. Hours, exceptions and a complete roster can be checked without a salary, and the submit needs no pay value. A check that each amount is correct does need the number, so route that check to the person who approves the run. Decide which of the two jobs the agent has before you decide what the screen may show it.
Who should approve the agent's submit?
A named person outside the model, not the agent and not a role inside the payroll system. A role decides which screens open; it does not put a person's judgment between the agent's reading and the submit. The approver should see the roster, the hours and the exceptions, and the approval should be recorded beside the action. Workday's elections page and BILL's role page document permissions, not that approval.
What should a payroll team ask a vendor about what the model reads?
Which columns the model receives on the entry and preview screens, whether the amount columns can be replaced with tokens, who approves the submit, and what record shows the screen as the model saw it. Ask for the screen answer rather than the role answer: a permission tells you what the agent may open, not what it reads once open. Treat an answer the documentation does not support as unanswered until a test run confirms it.
How RedactSure Keeps Salaries Out of the Payroll Run
An agent working a payroll run reads the salary columns before the submit, and the roles reviewed here never change what the page shows it.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the entry table and the preview and receives every row as rendered, with the rate beside the hours and the salary inside the total. Inside the governed environment: the same rows render employee names and identifiers as tokens for the run, the agent clears exceptions against the real pay figures, and a named person approves the submit, where personal values resolve.
RedactSure is deploying now with enterprise and government customers. ADP's own guide defines two role codes, Practitioner and Employee, and places a system user in the practitioner class.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
One payroll run puts every employee's pay in front of the model that works it. Bring a run with test values and see what the model reads on the preview, who approves the submit, and what the record holds. Book a demo