Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Can an AI Agent Deprovision a Leaver's Accounts Safely?
No, an agent that reads a real admin console holds the leaver's name, address and role, so a confirmation prompt narrows what it may do, not what it already read. Approve the account list by name, then let it execute where the screen renders tokens and the record shows what it saw.
Offboarding is the admin task with the shortest list and the longest tail. One person leaves, and an agent is asked to disable the identity account, the mailbox, the finance application and the VPN group before the end of the day. To do that it opens the console that holds the accounts and reads the user list, which is a page of real names, work addresses, managers, last sign-in times and group memberships. The instruction names the leaver; the page shows which row is theirs. When the model holds the row, a wrong choice is a person rather than a field, and the account it disables may belong to someone still on staff. The vendor pages describe the role that may change an account and the second administrator who approves the change; they do not describe the list being replaced before the model reads it. The question is whether the approval can move to the list, where a person can see it, and the values can move out of the model, where a wrong row cannot reach. Both failure directions matter: one locks out a colleague, the other leaves a live account behind.
Key findings
- For an agent to take a leaver's accounts safely, the console would have to render a consistent token such as USR_014 in place of the name, the address and the manager before the model reads the list, with real values resolving only at the console a named person approved (How to Protect Data From Screen-Reading AI Agents).
- It would also require a named person approving the list of accounts, one row per account, and a record that shows which screens the model read and who approved each disable (What Is Supervised Delegation?).
- None of the pages reviewed describes a user list that renders tokens before an agent reads it; they document the role and the second administrator who approves the change (Chase, 2026).
- Chase's Connect guide states that administrative changes "require approval by another System Administrator" and that transactions "must be approved within three days," a control on the change that does not describe what the administrator's screen showed (Chase, 2026).
- BILL's role page states that the Accountant role "is not able to manage users" and that the Clerk role "is permission to only enter bills," so a console's role boundary decides what an agent signed in as that role can do, not what it read (BILL, 2026).
- A study of web agents found that injections asking an agent to leak personal data seen during a task reached "average attack success rates (ASR) around 20 percent," which is what a user list of names offers (Alizadeh et al., 2025).
What does an agent read when it opens the leaver's account list?
The record for this page is a leaver checklist, approved before the run: one row for the identity account, one for the mailbox, one for the finance application and one for the VPN group. The agent disables each account on that list, in the console that holds it. The console draws a table: display name, username or mail address, department, manager, last sign-in and the groups the account belongs to, with a control at the end of each row. The task names the leaver; the page shows every row.
The name and the mail address are the selector, and the groups and the sign-in history are the access the person still holds. A model holding the real list can match the wrong row for reasons that have nothing to do with the instruction: a similar name, a rehired employee, a shared mailbox. The agent decides the next action from what it sees (Who Controls What an AI Agent Sees in a Hosted or Sandboxed Browser?).
What the action does depends on the console. Microsoft's Entra page states that after a user is deleted "the account remains in a suspended state for 30 days" and can be restored, that past that window "the permanent deletion process automatically starts and can't be stopped," that "A permanently deleted user can't be restored by anyone, including Microsoft customer support," and that "You can see all the users that were deleted less than 30 days ago," a window and a second list of real names that set what a wrong delete costs and say nothing about what the agent read to choose the row (Microsoft, 2026).
Which accounts should the agent change, and who approves them?
The decision that needs a person is the list, not the click. A list of four accounts is short enough to read row by row. The person who owns the checklist approves the accounts and the action on each one, and the agent executes the approved list; a prompt at each click produces the same decision later, after the model has read the page. For a run that disables four accounts, that approval is unusual: 1 of the 15 agents reviewed describes asking a person before every consequential action, and 5 describe a record of each action an administrator can export (Do AI Agents Ask Before Making a Payment?).
If the approval screen shows the agent's session and a job title, the approver cannot tell a display name from a duplicate; if it shows the leaver's name beside the token the model is working on, the approval settles the identity the run will act on (Can a Coding Agent Ask for More Access When It Needs It?).
Separation of duties is the other half. Creating an account and disabling it are two permissions, and a run that holds both has no second person in the path (Do Coding Agents Break Separation of Duties?). OWASP's entry for excessive agency names "excessive permissions" among its root causes, which is what a run that can read the list and disable any row in it holds (OWASP, 2025).
AWS's guidance states that "audit logs attribute every action unambiguously to either an agent or a human actor," which an agent signed in as a person does not give (AWS, 2026). A record that shows what the model read, who approved the rows and what the console returned is the one an auditor can use (What Is an AI Control Record?).
What do the vendors themselves say?
Chase's Connect guide is the closest the pages come to the offboarding decision. It sets per-account access levels, "See activity only", "Transact only" and "See activity and transact", and makes approval a per-account right: "Approve pending transactions within an account for that user" (Chase, 2026). With Chase Dual Control-Administration, administrative changes "require approval by another System Administrator," and the guide lists rights and levels without showing the fields of the approval screen (Chase, 2026).
BILL's role page sets the scope of a console account. "BILL offers six (6) pre-defined roles," the Accountant role "is not able to manage users or view/manage banking information," and a Payer "cannot enter or approve bills," so entering work and approving it sit with different roles, a boundary on the console that says nothing about the list an agent reads (BILL, 2026).
The vendor page answers who may make the change and how a second person agrees to it, not which account is the leaver's.
| Dimension | What the vendor page documents | What a buyer should verify |
|---|---|---|
| Role scope | BILL's six roles, with the Accountant unable to manage users | Which role the agent signs in as, and whether it can change an account outside the list |
| Administrative approval | Chase's dual control, where another System Administrator approves an administrative change | Whether the approval names the account and the action, or only the session |
| Record | Chase's three-day approval window and one-year view of user activity | Whether the record shows what the agent read, not only what it did |
What does the research record show about an agent that acts on what it reads?
A study of web agents measured how often an injection could make an agent leak personal data it saw during a task and reported "average attack success rates (ASR) around 20 percent" (Alizadeh et al., 2025).
A 2026 benchmark study found that "existing agentic security benchmarks are easily saturated by a simple approach" and that its tool-input filter "can also remove information that is important for task success, leading to a drop in utility" (Bhagwatkar et al., 2026).
Information-flow research reaches the same place: "poisoned data retrieved from one component can change the model's behavior and compromise the entire system, including coercing the model to spread confidential data to untrusted components" (Siddiqui et al., 2025). A note or a ticket comment can be that component.
The lab record is concrete about a write that lands on the wrong row. A position paper from Columbia's DAPLab lists incidents that include "Cursor's agent deleted PocketOS's production database via a single rogue API call" and "a 13-hour AWS outage was caused by Amazon's own Kiro agent autonomously rebuilding a production environment" (Columbia DAPLab, 2026). It describes such failures as "the predictable consequence of deploying agents that can write to systems designed only to be read by careful humans," and adds that "access control governs who can touch data, integrity constraints govern what gets stored, but neither governs how data flows and is used during agentic execution" (Columbia DAPLab, 2026).
What does a governed environment change?
A governed environment acts where the page is drawn. Values chosen by policy are replaced with consistent tokens before any model reads the screen, so the user list can render USR_014 where the leaver's name sits, and the same token appears on every later screen for the run. Real values resolve only at an approved destination, at the moment of an approved action, so the disable reaches the real account and the model never held it. A named person approves the account list, and every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.
For an offboarding run the change is in two places: the model matches USR_014 from the approved checklist instead of a display name it found on a page, and the person who signs the list sees the leaver's name beside that token, with the record showing both.
The role boundary and the second administrator still decide whether the change can happen; what changes is what the model read before it proposed the change. A permission that arrives as a sentence in a chat is a request; the same permission on an approved row is a decision a person made (How Do I Turn a Plain-English Request Into an Agent Permission?).
Its scope is the rendered page. A run that calls an identity provider's API directly, or that follows a feed written from the HR system, is outside a control that sits at the screen, and that path needs its own grant, its own approver and its own record.
What the record shows
The control that settles this page is what the model receives on the screen, who approved the account and what record exists afterward. The pages reviewed document the role that may change an account and the second administrator who approves the change, and none of them describes a list that renders tokens before an agent reads it. A run that reads the real user list is choosing a person from a page, and whether the choice can be undone depends on disable versus delete. That makes the answer no for the run as it is usually assembled, and yes only where the account list is tokenized before the model reads it and a named person approves the rows. To check it, take one leaver checklist, open the console the run opens, and compare the fields the model received with the rows the approver signed; the difference is the test.
Methodology and limitations
This page rests on vendor documentation from Chase, BILL and Microsoft, three research preprints, one standards entry from OWASP, AWS's agent guidance and a lab position paper, plus the RedactSure pages linked above. 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 this page, and "not described in the pages reviewed" means those pages. Vendor features change and the page carries its date, so a release after October 22, 2026 is unreviewed until the check above is repeated. RedactSure is deploying now with enterprise and government customers. The example describes a record type, a leaver checklist and the accounts it names, not an organization. Determinations about whether an offboarding process meets a contractual, regulatory or audit requirement belong to counsel, assessors and the organization's own security and compliance officers, and nothing here replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Can an AI agent deprovision a leaver's accounts safely?
No, not on the console most runs open. The agent reads the user list to find the row, and that list carries the leaver's name, address, manager and groups, so the model holds the values that identify a person before it acts. A delete can be undone for 30 days in the console Microsoft documents and is permanent after that (Microsoft, 2026). The condition that changes the answer is a list that renders tokens before the model reads it, with a named person approving the rows.
What does the agent read on the user list?
Whatever the table draws: display name, username or mail address, department, manager, last sign-in and group memberships, plus the control at the end of each row. A task description names the leaver; the page shows every row beside it. The model receives the page rather than the fields the task mentions, so a duplicate name or an edited row can move its choice. The fields are drawn whether or not the task needs them. Ask to see the list as the run received it.
Who should approve the accounts?
The person who owns the leaver checklist, with the owner of each application the accounts open, and the approval names the rows and the action on each one. Approving the agent's session is a different decision: it answers who runs the tool, not which person loses access. A list is short enough to read row by row, which is why it can carry the approval a per-click prompt cannot.
Does a confirmation prompt change what the model read?
No. A prompt stops the action and asks a person, and by then the model has read the list and chosen the row. It narrows what the agent may do, not what it already read, and the person who answers it is usually reading a summary the agent wrote rather than the console. The check that matters sits earlier, on the page the model reads, and later, on the record of what it saw there.
What should the record show after a disable?
The screens the model received, the accounts in the list, the action taken on each and the name of the person who approved them. A console log records the state change and a session transcript records the agent's steps, and neither shows what the user list drew. Export the set to the team's monitoring, beside the approval, so a reviewer can compare the approved rows with the rows the model acted on.
Does deprovisioning through an API change the answer?
Yes, it moves the question. A control at the rendered page covers a run that opens the admin console; a call to the identity provider's API, or a feed written from the HR system, is outside it and needs its own scoped credential, its own approver and its own record. The same decision applies in a different place: which accounts, approved by whom, with what record of what the system returned.
How RedactSure Keeps a Leaver's Account List Off the Agent's Screen
An offboarding list is short, and one wrong row takes access from a person who still works there. Injections that asked web agents to leak personal data seen during a task reached "average attack success rates (ASR) around 20 percent" (Alizadeh et al., 2025).
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the console draws the leaver's name, address and manager, and the model picks the row from that page. Inside: the row renders USR_014, the model works on the token the approved checklist names, and the disable reaches the real account only on the approval a person gave.
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 leaver's checklist is short enough that one wrong row is the whole risk. Bring one offboarding task and see, with test values, the account list as the model reads it, the approval, and the record it leaves. Book a demo