Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is It Safe to Let an AI Agent Run Payroll?
No, not as payroll runs today: the ADP, Gusto and Workday screens behind a biweekly run render each employee's Social Security number, salary and bank account to whatever model reads them, and the task needs none of it. Replace those values with tokens before the model reads the screen and have a named person approve the submit.
Payroll is the recurring task where the screen and the job disagree about what matters, and the disagreement is expensive. A biweekly run needs this period's hours, the exceptions someone has to look at and a submit; the same screen lays out what every employee earns, the account a check goes to, and in the records behind it a Social Security number. An agent that opens the run receives all of it, because the page renders the roster rather than the three columns the job needs. The exposure a payroll manager takes on is the reading that arrives with the run; the payroll domain already grants the submit, and a run can be approved and paid without anyone reading the roster, which is why the reading is the part to design. The pages reviewed here describe access by security domain, a two-step code on a bank change and a preview dialog that asks whether the numbers look right, and none describes replacing the values before a model reads the screen. The answer turns on that distinction, on who signs the run, and on what record survives the submit. A payroll team that cannot say what the agent read cannot say what it disclosed.
Key findings
- For a payroll run to be safe for an agent to work, the values on the screen would have to be replaced with consistent tokens before any model reads it, so the agent works the roster as EMP_014 and never holds an employee's identifier or account number (What Is Render-Layer Tokenization?).
- It also requires a named person approving the submit and a record of what the model received, the gap a 2026 FINRA report flags when agents act without human validation (Is It Safe to Let AI Agents Access Financial Records?).
- The payroll pages reviewed stop at who may open a screen: Workday's payment elections page describes no approval step before an administrator changes a bank account (Workday, Payment Elections, 2026).
- ADP's payroll entry grid lists a Salary Amount column, and a warning dialog before the run asks whether the numbers look right, with Ignore Issues or Go Back And Fix (Docsie, 2026).
- Workday's payment elections page lets you "set up an additional bank account to split payments," and a bank account can be deleted only if it "isn't in use by a payment election" (Workday, Payment Elections, 2026).
- Gusto's help center says employees "can add up to 5 bank accounts and split pay between them," and that "Your legal name" and "Social Security Number (SSN)" are employer-only fields (Gusto, 2026).
What does an agent read when it opens a payroll run?
The record is a biweekly run on a payroll system's entry screen. A tutorial for ADP's payroll flow tells the operator to "Review the following columns 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 (Docsie, 2026). That grid holds the hours the task needs and each person's pay, which it does not. A browser agent receives the grid as the page renders it, because a page arrives at the model as text and layout rather than as a list of permitted fields.
The identifiers sit one page away, inside the same session. The ADP direct deposit documentation describes the routing field as "Indicates the Routing Number to which the Direct Deposit applies" and the account field as "Indicates the Account Number to which the Direct Deposit applies" (ADP, Direct Deposit, 2026). On the HR side, a state personnel job aid for the hire process instructs the operator to "Enter the nine-digit Social Security Number in the Identification # field," and flags a repeat entry (Maryland Department of Budget and Management, 2022).
An agent asked to check a run opens the employee record, the payment page and the bank tab the run links to, and each renders to the model the way the entry grid does.
Does the run need the values the screen displays?
The run needs three things: the hours for the period, the exceptions a person has to resolve, and a submit. Salary is computed by the system from compensation already on file. Nothing in the task requires the model to hold a rate, an account number or a Social Security number. The screen supplies them because it is built for a person who may see the roster.
The settlement side is mostly a filter and a button. Workday's Create Settlement Run task takes Currency, Display Currency, Auto Select Filters, Include Payments on Behalf of Other Companies, Exclude Negative Payments and Dynamic Supplier Payment Date, then "Click Add to search for and select the unpaid open items and pending payments," then "Click Manage Payments to edit payment details, or remove payments from the settlement run," and only then "click Process" (Workday, Settlement, 2026). Access is a security domain, "Process: Settlement domain in the Banking and Settlement functional area," which governs who may run the settlement and says nothing about what the model reads.
Accounts payable screens 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?).
What do the vendors themselves say?
Gusto's help center describes the employee side of a bank change: employees "can add up to 5 bank accounts and split pay between them," and a change requires them to "Complete the security check (2-step code and confirm current bank)" (Gusto, 2026). The check authenticates the employee making the change. It does not describe what an administrator's payroll screen shows an agent holding the administrator's session.
Workday's payment elections page says access is governed by security domains that include "Manage: Payment Election domain in the Expenses functional area" and "Worker Data: Payroll (Payment Elections) domain in the Core Payroll functional area," and that when bank details change, "Workday automatically updates all payment elections with the new account information" (Workday, Payment Elections, 2026). A domain decides who may open the page, not which fields the page renders once opened.
ADP's direct deposit developer documentation defines two role codes for its API, Practitioner and Employee, and states that "A system user is considered a practitioner," while the guide "contains nothing about approval limits for changing a deposit," so who signs a change is left to the customer's process (ADP, Direct Deposit, 2026).
The three pages stop at who may open a screen and what the screen will accept.
Who approves a payroll run, and what does that approval cover?
On the systems reviewed, the approval is the operator's own click. ADP's flow ends at a warning dialog that asks whether the payroll looks right, with "Choose Ignore Issues to proceed without changes, or Go Back And Fix to return to the entry screen" (Docsie, 2026). It creates no second signature and no record of what the model read. The design this page asks for stays rare across the agents reviewed: 1 of 15 documents asking a person by default before every consequential action, and 5 document a per-action record an administrator can export, while no payroll product was among the 15 (Do AI Agents Ask Before Making a Payment?).
OpenAI's agent governance paper calls human approval "a standard way to limit egregious failures" and requires that "at least one human entity is accountable for every uncompensated direct harm" (Shavit et al., 2023). A click by the same operator who ran the agent leaves accountability with that operator alone.
Payroll fraud has run on the gap. The FBI's advisory on payroll diversion says "Cybercriminals target employees through phishing emails designed to capture an employee's login credentials," after which "Direct deposits are then changed and redirected to an account controlled by the cybercriminal" (FBI, 2018). An agent holding a payroll administrator's session is the same access at machine speed. The control that changes the answer is a named approver outside the model, approving the specific run, with a record to show it (How Do I Set Credential Approval Rules for My Whole Team?).
What should a buyer ask for in writing before an agent runs payroll?
The question that decides the answer is not on a feature list. It is what the model receives from a rendered screen, asked per task.
| Question to put in writing | What the pages reviewed show | What to require |
|---|---|---|
| What does the model receive on the payroll screen? | The entry grid renders a salary column; the payment page renders account numbers | A per-field policy, with values replaced by consistent tokens before the model reads the screen |
| Who approves the submit? | The operator's own click, in the dialog that asks whether the payroll looks right | A named person outside the model, approving the specific run |
| What record shows what the model read? | The payroll system logs the user account that ran the payroll | A per-screen record of what the model received, exported to the customer's monitoring |
The tax payment uses the same account: IRS Direct Pay offers "Pay taxes from your bank account with Direct Pay," with "No sign-in required" (Internal Revenue Service, 2026).
According to 1Password's post on browser agents, "the AI agent and underlying LLM never need to see nor handle the credentials," and the value is injected "if, and only if, the human approves the access" (Is It Safe to Let a Browser Agent Use My Saved Logins?). The login stays out of the model while the payroll screen it opens still renders the roster. A study of browsing agents reports findings that "include prompt injection, domain validation bypass, and credential exfiltration," the attacks that arrive by reading a page (Why Should Submitting a Credential Require Its Own Permission?).
What does a governed environment change?
A governed environment moves the control to the point where the page is drawn. 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 before any model reads the screen, so the run renders EMP_014 and ACCT_014 for every employee, and the agent checks hours, finds the exception and submits against a roster it can work but not read. Real values resolve only at the approved destination, at the moment a named person approves that run. Every screen, action and approval goes to an exportable record.
That changes three things the systems reviewed leave open. The reading is bounded: the agent checks the hours and the exceptions against a roster drawn as EMP_014 and ACCT_014, and no Social Security number enters its context. The approval is separated: the click that releases the payout belongs to a named person outside the model. The record is produced: the run leaves a statement of what the model received on each screen.
The scope is the rendered page itself, not the endpoint. On the invoice side, the values a page renders would have to be replaced with consistent tokens before any model reads the screen, so the agent works from ACCT_014 throughout (What Is a Secure Alternative to Agentic Browsers for Paying Vendor Invoices?).
What the record shows
A payroll run is safe for an agent to work when three conditions hold together: the values on the screen are replaced with consistent tokens before the model reads them, a named person outside the model approves the submit, and a record shows what the model received on each screen. The pages reviewed do not meet that bar. ADP's entry grid renders a Salary Amount, Workday's payment elections page describes no approval step before an administrator changes a bank account, and the gate on the run is a warning dialog that asks the operator whether the numbers look right. A concrete test: attach an agent to a biweekly run, capture every screen the model received, and compare that list with the fields the task needed.
Methodology and limitations
The page rests on payroll and HR documentation from Workday, Gusto and ADP, a third-party payroll tutorial, guidance from the Internal Revenue Service and the FBI, and one governance whitepaper. 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 for it; the products are described from documentation, and "not described in the pages reviewed" means the recorded pages do not state it. The ADP walkthrough is a third-party tutorial, not ADP documentation. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a biweekly payroll run, and not an organization. Determinations about payroll, tax and recordkeeping obligations belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one workflow.
Frequently asked questions
Is it safe to let an AI agent run payroll?
No, not as payroll systems render a run today. The entry grid supplies a salary for every employee, the payment pages supply account and routing numbers, and the HR record supplies a Social Security number, so a model attached to the session receives values the task never needed. A named person approving the submit does not change what the screen already showed. Replace those values with tokens before the model reads the screen and the run becomes workable.
What does the model receive on a payroll screen?
Every column the page renders. On an ADP-style entry grid that includes Name, Department, Rate, Regular Hours, Salary Amount and the overtime and bonus columns, because the page is built for a person allowed to see the roster. A page delivered to a browser agent arrives as text and layout, not a permissioned subset, so the salary sits in the model's context beside the hours it was asked to check.
Who approves the run when an agent submits it?
Usually the operator whose session the agent used. ADP's flow ends at a warning dialog that asks whether the payroll looks right and offers Ignore Issues or Go Back And Fix, which is a pause for the person who entered the data rather than a second signature. Workday's payment elections page describes no approval step before an administrator changes a bank account. Approval outside the model, by a named person, on the specific run, is what the pages do not describe.
Does a two-step code or a security domain control what the screen shows the model?
No, because both govern who may open or change something. Gusto requires a two-step code and the current bank before an employee changes their own deposit, and Workday gates payment elections by security domain. Those controls authenticate a person at a door. They do not limit what the page renders once it is open, and an agent inside an authenticated session reads everything it shows.
What record proves what the agent saw and did?
The payroll system's audit log shows the user account that ran the payroll, the administrator the agent acted for, and that is the record most teams have. It does not show which fields the model received, which values it typed, or who approved the release. A per-screen record of what the model read, joined to the approval, answers that question after a bad run.
Can an agent work a payroll run from tokens and still get the numbers right?
Yes for the parts the run needs. Consistent tokens keep one employee and one account recognizable across every screen, so an agent can follow a row, find the exception, compare a total and submit the record it started with. The arithmetic stays in the payroll system, which computes pay from compensation on file. The model does not need the salary to submit a run; it needs the hours, the exception and the approval.
How RedactSure Keeps a Payroll Run on Tokens
A payroll agent reads the salary, the account number and the Social Security number because the screen puts them beside the hours it was asked to check.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the biweekly run and reads the grid the operator reads, salary and account included. Inside the governed environment: the same grid renders EMP_014 and ACCT_014, the hours and exceptions stay legible, and the submit resolves real payout values only on a named person's approval.
RedactSure is deploying now with enterprise and government customers. The FBI's payroll diversion advisory reports that stolen credentials are used to change direct deposits and redirect them to a criminal's account.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
A payroll run exposes a roster to whatever model opens it, and the approval line names one person. Bring a biweekly run with test values and see what the model reads, who approves the submit, and what the record holds. Book a demo