Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Who Approves an AI Agent Granting Admin Rights?
A named person on the organization's own staff, every time, with the agent preparing the grant and that person releasing it. Check that the request page names the approver, that the release runs on a person's own connection, and that the record keeps what the model read and who released the change.
An admin grant is the point where a request becomes someone's authority. A provisioning tool assembles the change, and a person with the standing to release it decides whether the request stands. Automation speeds the assembling, and speed is what turns a release into a formality: a summary in a chat window, a confirmation button, a role that lands on an account nobody checked.
The exposure sits with whoever releases the grant, and it does not turn on whether the agent is competent. A grant hands over an identity, a mailbox, a billing account or a set of customer records, and it outlives the task that produced it. The person who releases it is the person an auditor asks about months later. Published controls describe how a request is routed and who may open the approval page. Fewer describe what the model read while it prepared the request, and fewer still keep a record that ties the two together.
The record here is an admin grant held on an approval page: a request for an elevated role, pending, with a requester, a scope, a justification and an approver who has not released it. What the agent put in front of that person, and what the record shows after the release, decide whether the grant can be defended.
Key findings
- For an admin grant to be answerable, the values on the approval page would have to be replaced with consistent tokens before any model reads it, so the requester renders as USER_014 and the role as ROLE_002 for the whole run (What Is Supervised Delegation?).
- It would also require a named person approving each release and a record of what the model read while it prepared the request (What Is an AI Control Record?).
- The approval material reviewed describes the chain, the approver field and the confirmation prompt, and none of it describes a filter on the account values a model reads while it prepares the request (Workato, 2026).
- Workato's prebuilt approvals server gives a model a tool that "Approves a pending approval if it hasn't changed since it was last reviewed," and the same page says the model approves "after showing the document summary and obtaining confirmation" (Workato, 2026).
- Coupa's Approvals API exposes "Perform Approve action on an approval" and carries approver and approved-by among its elements (Coupa, Approvals API, 2026).
- ToolEmu's sandbox found that "even the safest LM agent exhibits such failures 23.9% of the time," counting risky actions such as irreversible ones among the failures (Ruan et al., 2024).
What does an agent prepare before an admin grant is released?
The request arrives as a page, and the page is where the agent works. On an access request, the agent opens the identity console or the application's admin screen, finds the person, reads the roles held and proposes the new one. The University of Wisconsin job aid has the same shape: it starts from the worker profile and asks the initiator to "Attach documentation with justification for the compensation change" (Universities of Wisconsin, 2026). The preparer supplies the reasoning; someone else supplies the authority.
Infinite Campus shows why that authority is not a single yes. Its catalog tells administrators to "Review User Groups and Suggested Tool Rights as a starting point for assigning tools and rights to user groups," and the same page adds that "appropriate calendar rights in addition to SSN rights" are required to view the value, so the grant is a bundle rather than one switch (Infinite Campus, 2026).
MIT Sloan defines the class as "autonomous software systems that perceive, reason, and act in digital environments," and notes that with payment permissions an agent can finish a transaction without a person (MIT Sloan, 2026).
Preparation is not release. The agent can gather the case, draft the justification and stage the change; the grant still needs a person with the standing to make it. A mid-task request for more access tests the distinction, because it arrives while the agent is already inside the session (Can a Coding Agent Ask for More Access When It Needs It?).
Who approves the grant, and what does the approver release?
Coupa's Approvals API requires that "an approval must be Pending (and not already approved or rejected) for the action to be valid", so the held state is the window in which a person decides (Coupa, Approvals API, 2026). The same API carries an approver and an approved-by field, so the release lands against a name and a time. The field is thin on default approval: 5 of the 15 AI agents reviewed document a per-action record an administrator can export, and only 1 documents asking a person by default before every consequential action (Do AI Agents Ask Before Making a Payment?).
GitLab's guide describes the routing. An "On Behalf Of" field is "used to create a request on behalf of another user," and the approval chain follows the person named there (GitLab, 2026). It does not say what the model read while it filled the request in.
The OpenAI governance paper states the principle: human approval "is a standard way to limit egregious failures" (Shavit et al., 2023). Approval narrows what can go wrong; it does not describe what the approver was shown.
What the approver releases is the version of the request on the page. If the model assembled the request, the approver confirms the model's account of a change the model also read from the account. A payee change has the same property: whoever prepares it can make the new account number look correct on the form. That is why the release sits with a second person, and why separation of duties has to be restated for a machine preparer (Do Coding Agents Break Separation of Duties?).
A coding agent that can approve its own permission request is the same failure in another console: the release never leaves the session that prepared it (Can a Coding Agent Approve Its Own Permission Request?).
What do the vendors themselves say?
Workato's page describes the tool that puts an approval in front of a model: "Your LLM uses this tool to approve a pending item after showing the document summary and obtaining confirmation" (Workato, 2026). The confirmation is a chat exchange, and the document summary is the model's own account of the request. The same page adds that "A request made without the required permission returns a permission-denied outcome," so the release runs on the approver's own connection (Workato, 2026).
Coupa's Approvals API documents the other half, exposing approve, hold and reject actions and listing approver, approver-type and approved-by among its elements (Coupa, Approvals API, 2026). It carries no permission rule: the page states no authentication, permission or role requirement and marks most elements output-only (Coupa, Approvals API, 2026).
GitLab's guide is a configuration record. It says "The greater the amount of the requisition, the more approvers will be needed," and that a watcher "cannot approve or reject the cart" (GitLab, 2026). It is GitLab's own setup from August 2025, so it describes one company's chain.
The University of Wisconsin job aid notes that "An Amount Change and Percent Change will auto-populate," which separates who prepares a change from who approves it (Universities of Wisconsin, 2026).
What the approver sees on the rendered request screen is not described in the pages reviewed. Workato shows the document summary, Coupa lists the fields and GitLab shows the approvers beneath the cart line, and none states which account values the model read while assembling the case.
| Dimension | Workato and Coupa, per their pages | What a buyer should verify |
|---|---|---|
| Who may approve | Workato runs on the approver's own connection and returns a permission-denied outcome; Coupa's page states no permission requirement | Which role the connection carries, and whose it is |
| What the model reads | Workato shows "the document summary" before confirmation; no page reviewed describes field-level filtering on the request screen | What values the model receives from the rendered request page |
What record should an admin grant leave?
The record has to answer two questions at once: what changed, and what the model knew when it changed. Workato's tool is a small lesson in why the version matters. It "Approves a pending approval if it hasn't changed since it was last reviewed," which makes the reviewed version part of the decision (Workato, 2026). A record that keeps only the final state cannot show which version was released.
The OpenAI paper puts the accountability in one sentence: "at least one human entity is accountable for every uncompensated direct harm" (Shavit et al., 2023). The harm from a wrong grant is direct and often uncompensated, so a grant with no named approver cannot say who that entity is.
A default is not a record. The AI Agent Index entry for one agent says "The default is that approval is required," while adding that users can switch the requirement off (AI Agent Index, 2026).
What to export: the requester, the role granted, the scope, the justification, the screens the model read, the values it saw, the approver's name and the time. The list is longer than most change logs, and the extra entries are the ones an access review asks for (What Is an AI Control Record?). An approval is also the handoff that can send data on, which is why the record has to name a destination as well as a person (Who Approves an AI Agent Before It Sends Sensitive Information?).
What does a governed environment change?
A governed environment moves the control to the render layer, before a model reads the page. Values chosen by policy are replaced with consistent tokens for the whole run, so an agent preparing an admin grant works with USER_014 in the requester field and ROLE_002 where the role appears. Real values resolve only at the approved destination, at the moment of an approved action.
The release is a separate layer. A named person approves each grant, sees the tokenized request, and decides; the agent cannot complete the release from inside its own session.
Every screen the agent read as tokens, every action and every approval with a name is written to a record that exports to the organization's own monitoring.
Stopping is part of the design. Hadfield-Menell and co-authors show that "giving machines an appropriate level of uncertainty about their objectives leads to safer designs," the property that lets a person stop an agent before it releases a grant (Hadfield-Menell et al., 2017).
Its scope is the rendered page. A direct API call, a script that authenticates to the identity provider, or a terminal session is outside it. Privileged-access products govern the identity that holds a role, which is a different layer from what the model reads while it prepares the release (RedactSure vs CyberArk: 2026 Comparison & Alternative).
What the record shows
A release a named person makes on a page a model never reads is the version of an admin grant an auditor can follow. The approval pages reviewed put the release in a record with an approver and a status, and they leave open what the model read while it assembled the request: one page carries approver and approved-by, another approves only what has not changed since review, and neither describes a filter on the account values the preparing model holds. That gap is the one an access review will name first. The test a team can run is a sample: take the last ten admin grants the team released and ask, for each, which screens the model read, which values it saw and who pressed approve. The grants that cannot answer all three are the work in front of the team, and the answer for the next ten is a page the model reads as tokens and a release a person makes.
Methodology and limitations
The page rests on vendor and product documentation, two preprints, a governance whitepaper, a research index and one piece of industry analysis. They are a procurement MCP server, an approvals API, a handbook guide, a student information system's catalog and a university job aid. 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, and "not described in the pages reviewed" 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, an admin grant held on an approval page, and not an organization. A pilot of one workflow on the organization's own screens remains the test, and whether a particular grant meets a contractual, regulatory or audit requirement belongs to counsel, assessors and the organization's own security and compliance officers.
Frequently asked questions
Who approves an AI agent granting admin rights?
A named person on the organization's own staff, not the agent and not the model that summarized the request. Coupa's approvals API carries an approver and an approved-by field, so the release lands against a person. Workato's server approves a pending item only after showing a summary and obtaining confirmation in the conversation. The record should name the person even when a group owns the queue.
Can the agent approve its own admin grant?
Only where a person's own connection performs the release. Workato's approve tool runs on the approver's Coupa connection and returns a permission-denied outcome when that connection lacks the right. Coupa requires the approval to be pending before an approve action is valid. Nothing in the pages reviewed describes a bar that would stop an agent holding an approver's session from pressing approve, which is the case to test.
What does the model read while it prepares an admin grant?
Whatever the request page and the account page render: the person's profile, current roles, the proposed scope, the justification, and any values the console shows beside them. The approver sees a summary built from that reading. The pages reviewed describe the request fields and the approval record. They do not describe a filter that removes account values before the model reads them, which is the exposure to name.
Does an approval chain keep the request data away from the model?
No. A chain decides who must release a change, and GitLab's guide shows routing that follows the person named On Behalf Of. Routing does not filter a page. The model that assembles the request still reads the account it is changing, and the approval page still renders the values the approver confirms. A chain and a render-layer control answer different questions, and an admin grant needs both.
What record should an admin grant leave?
One that names the requester, the role granted, the approver, the time and the version the approver reviewed. Workato's tool acts only on an approval that has not changed since it was last reviewed, which makes the reviewed version part of the decision. Coupa's elements include approver, approved-by and status. Add the screens the model read and the values it saw, and the record answers both questions an auditor asks: what changed, and what the model knew when it changed.
Is an approval setting enough for an admin grant?
No, not when the setting can be switched off. The AI Agent Index entry for one agent says approval is required by default, then notes that users can turn the requirement off and that automatically triggered agents run without approval. A default is a starting position and not a control. What survives a change of default is a release the system cannot complete without a named approver, and a record of the person and version released.
How RedactSure Keeps an Admin Grant Behind a Named Approver
An approval queue that asks a person to confirm an agent's summary leaves the account values in the model's context and the release unexamined.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before, the agent reads the requester's profile, the roles held and the values beside them, then carries its summary to an approver. Inside the environment, the page renders USER_014 and ROLE_002, the approver sees the request without the account values, and real values resolve only when that person releases the grant. The screens and the approver's name go to the record.
RedactSure is deploying now with enterprise and government customers. ToolEmu's sandbox found risky actions in 23.9 percent of runs even for the safest agent.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
An admin grant a person releases on a page the model never reads is a decision the record can defend. Bring one access request and see, with test values, the page the model receives, the approval and the record. Book a demo