Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does an AI Agent Need Human Approval Before It Takes Action?

Not before every action, but before every action that is consequential, hard to reverse or leaves the organization, and that approval should come from a named person. Check which actions in your agent's workflow fall into those three classes, and confirm that the gate on them is enforced by the environment rather than by instructions to the model.

A shared approval gate stands before workflow branches leading to documents, payments and an output tray.

Not before every action, but before every action that is consequential, hard to reverse or leaves the organization, and that approval should come from a named person. Check which actions in your agent's workflow fall into those three classes, and confirm that the gate on them is enforced by the environment rather than by instructions to the model. The question is often posed as a binary, and both answers fail in practice. A prompt on every step produces approval fatigue, in which the person clicks through because the prompts are too frequent to read, and the gate stops meaning anything. No approval at all hands the organization's systems to a model that acts on what it reads, including content planted to mislead it. The useful answer is a classification: which actions a person should see before they happen, who that person is, and how the control holds when the model is wrong. This page works through where approval fatigue comes from, how to sort actions into classes, what a worked example looks like on a single customer account page, how the approval should be attached to a named and accountable person, how to measure whether the gate is working, and which vendor claims about approval a buyer should decline.

Key findings

  • Human approval before an agent acts is described by OpenAI's governance practices paper as "a standard way to limit egregious failures," paired with the principle that actions reviewed only after the fact "should be more easily reversible" (OpenAI, 2023).
  • Approval on every step does not scale. Anthropic's engineering team reports that moving enforcement into a sandbox with filesystem and network isolation "safely reduces permission prompts by 84%," which is a measure of how many prompts were noise rather than decisions (Anthropic Engineering, 2025).
  • Vendor policy converges on the same line: humans "should retain control over how their goals are pursued, particularly before high-stakes decisions are made," with cancelling a subscription offered as the kind of action that waits (Anthropic, 2025).
  • Regulation already names the capability. Article 14 of the EU AI Act requires that overseers of high-risk systems be able to "disregard, override or reverse the output" and to "interrupt the system through a 'stop' button or a similar procedure" (EU AI Act, 2024).
  • The failure mode when approval is absent has a name in the OWASP Top 10 for LLM Applications, Excessive Agency, which covers agents granted more function, permission or autonomy than the task requires (OWASP, 2025).
  • An approval is only as good as the record that shows who gave it; a gate that cannot name the person who approved an action is a prompt, not a control (What Is AI Agent Action Governance?).

Where does approval fatigue come from, and why does it matter?

Approval fatigue is a property of the gate's placement, not of the person's attention. When the only control available is a prompt, every action the system cannot otherwise constrain becomes a prompt, and the person approving them is asked to judge dozens of small, safe operations for every one that matters. The predictable result is that approval becomes reflexive: the person learns the prompts are almost always fine, approves them in a rhythm, and approves the one that was not fine in the same rhythm.

The Anthropic engineering account of sandboxing is useful here because it quantifies the effect. By enforcing filesystem and network boundaries in the environment, so that an agent could not reach outside its sandbox regardless of what it tried, the team removed the need to ask about operations the boundary already prevented, and reports that this "safely reduces permission prompts by 84%" while noting that "effective sandboxing requires both filesystem and network isolation" (Anthropic Engineering, 2025). The lesson generalizes beyond coding tools. Most of what an agent does inside a well bounded environment does not need a human decision, because the environment already decides it. The prompts that remain are the ones that matter, and a person who sees five prompts a day reads them in a way a person who sees five hundred does not.

The corollary is that an organization asking "does the agent need approval?" is asking the wrong first question. The first question is what the environment prevents without asking. The second is which remaining actions are consequential enough to pause for. Only then does the approval design, who approves, on what screen, with what record, become the right thing to specify.

Which actions should wait for a person, and which should not?

Three properties sort actions into the class that waits. The first is consequence: does the action change a balance, commit the organization to something, or alter a record that others rely on? The second is reversibility: can the action be undone cleanly after the fact, or does undoing it require a new transaction, a notification to a third party, or an apology? The third is externality: does the action leave the organization's boundary, by sending a message, submitting a form to another party, or moving money? An action with any of these properties should wait; one with none can run.

Action class Examples on a customer account page Approval posture
Read and navigate Opening the account, reading notes, moving between tabs None; the environment bounds what can be seen
Reversible internal edit Correcting a mailing address, adding an internal note Logged, not gated, unless policy says otherwise
Consequential internal change Changing the plan tier, closing the account Named person approves before commit
External or financial action Issuing a refund, sending a letter, submitting a dispute Named person approves; real values resolve only at the destination

OpenAI's governance practices paper supplies the design principle behind the table: actions "that can only be reviewed after the fact should be more easily reversible," which means that where the organization chooses not to gate, it should prefer actions it can undo (OpenAI, 2023). Anthropic's agent framework offers approval before an agent cancels subscriptions as its example of a decision that waits (Anthropic, 2025). A cancelled subscription is exactly the fourth row.

How does the classification play out on a single customer account page?

Consider a customer account page in a subscription billing system. The agent's task is to resolve a complaint: the customer says they were charged twice. The page shows the account identifier, the customer's name and email, two recent charges, the plan tier and a refund button.

The agent reads the page. That is a read action and needs no approval, though what it reads should be bounded; in a governed environment the identifiers it sees are tokens rather than the real values, so the model works with ACCT_001 and never holds the customer's actual account number. The agent compares the two charges and finds they are identical in amount and timestamp, which supports the complaint. It drafts an internal note recording the finding. That is a reversible internal edit; a policy may log it and let it through.

Then the agent reaches the refund. A refund is financial, external in effect, and reversible only by a new transaction that the customer would notice. It is the action in this workflow that should wait. The agent prepares the refund, the amount and the target charge, and the workflow pauses. A named person, the billing supervisor who owns this queue, sees the prepared action on the same screen, with the tokens the agent saw, and approves or declines. Only on approval does the real account identifier resolve, at the payment system, at the moment the refund is submitted. The follow-up email to the customer is also external and also gated.

The point of the example is proportion. Of perhaps a dozen actions in this workflow, one or two wait. The person approving them is not fatigued, because they were not asked about the other ten.

Who should the approval be tied to, and what should the record show?

An approval is a decision by a person, and the design should make that person identifiable in advance and in the record afterward. The OpenAI practices paper puts the principle in terms of accountability: "at least one human entity is accountable for every uncompensated direct harm" (OpenAI, 2023). An approval that routes to a shared mailbox, or to whoever is online, satisfies the form of the control and not its purpose.

In practice this means the approver is named per workflow, not per deployment. The billing supervisor approves refunds; the records manager approves changes to retention settings; the person who owns a vendor relationship approves messages sent to that vendor. The person who would have been accountable for the action if a human had taken it is the person who approves it when an agent prepares it. Institutional guidance on managing generative AI systems makes the same point from the governance side, asking that systems operate under identified human ownership (Harvard University Information Security and Data Privacy).

The record should show four things for every gated action: what the agent proposed, what the approver saw when deciding, who the approver was, and when the action was committed. If the approver saw tokens, the record shows tokens, which means the record itself does not become a new copy of the sensitive values. That is the difference between an approval queue and an audit trail an assessor can read.

How should an organization measure whether its approval gate is working?

Measure four figures per workflow in a pilot. First, the prompt rate: how many approval requests a person sees per completed task. If the number is in the dozens, the environment is not bounding enough and the gate will be clicked through. Second, the decline rate: how often the approver says no. A gate with a zero decline rate over hundreds of actions is either placed on actions that did not need it or is being approved by reflex; both are worth investigating. Third, the time to decision, which shows whether approvals are read or rubber stamped; a decision that consistently takes under two seconds on a refund is not a decision. Fourth, the coverage: of the actions the classification says should wait, how many actually did, verified from the record rather than from the design document.

The classification itself should be tested against the OWASP description of Excessive Agency, which treats excess permission and excess autonomy as distinct failures (OWASP, 2025). An agent can have exactly the right approval gates and still hold permissions far beyond its task, in which case a model error or an injected instruction does damage through an ungated path. The measurement, therefore, includes an inventory of what the agent's credentials can do that the workflow does not require. The Hugging Face position paper argues against building fully autonomous agents at all; whether or not an organization accepts that conclusion, its reasoning supplies the test, which is whether a human remains in a position to stop the system before harm (Mitchell et al., 2025).

What does a governed environment change?

In a governed environment, approval is required for the small set of actions that are consequential, hard to reverse or leave the organization, and the gate on those actions is enforced by the environment rather than by instructions to the model.

This class of control makes approval a property of the action path. Actions are classified in advance, and a classified action cannot commit without a named person's approval, regardless of what the model decided. Routine actions proceed unprompted. Sensitive values on the rendered screen are replaced with consistent tokens before any model reads them, so the task runs on tokens, and real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves payments, submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

Approval and a bounded environment are one design, not alternatives. Moving enforcement into an isolated sandbox reduced permission prompts by 84 percent, a measure of how many prompts were noise rather than decisions (Anthropic Engineering, 2025); a well bounded environment is what makes a small number of real approvals possible. A model's decision to ask is a model output, which prompt injection and model error corrupt, and documented tool-use paths treat human-in-the-loop as a configured property rather than something the model volunteers (OpenAI, 2025). The record of each approved action answers who, what and when, and yields the prompt rate per task.

The control does not alter the application, the user's permissions or the model, and it does not decide which actions an organization classifies as consequential.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design answers the title question with a classification enforced outside the model. The agent works in a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so the model sees consistent tokens such as ACCT_001 or PATIENT_001 for the whole run and never holds the real identifiers. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy before the run and approves every payment, submission and record change, the arrangement the design calls Supervised Delegation; reads and reversible internal edits proceed without a prompt. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own workflow would show, for this question, the prompt rate per task, which actions waited and which did not, who approved each one and what they saw at the time, all read from the record rather than from a design document. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on published governance practice and vendor documentation: OpenAI's whitepaper on practices for governing agentic AI systems (2023), Anthropic's framework for developing safe and trustworthy agents (August 2025) and its engineering account of sandboxing (October 2025), OpenAI's Agents SDK human-in-the-loop documentation (2025), Article 14 of the EU AI Act as published on artificialintelligenceact.eu, the OWASP Top 10 for LLM Applications entry on Excessive Agency (2025), Harvard University's best practices for managing generative AI systems, and the Hugging Face position paper on fully autonomous agents (arXiv, 2025). All sources were read as of October 16, 2026. The classification of actions into read, reversible, consequential and external is this page's synthesis of those sources, not a scheme any one of them publishes.

No hands-on testing of any product was performed. Where a vendor's documentation is described, the description is of what the pages reviewed say, and "not described" means not described in those pages, not absent from the product. Vendor features change, and the page carries its date. The 84% reduction in permission prompts is Anthropic's reported figure for its own coding tool and is cited as an illustration of the fatigue problem, not as a benchmark for other systems. Statements about RedactSure describe current design, with deployments in pilot. The customer account page and the refund workflow describe a record type and a task shape, not any organization.

Whether a given workflow's approval design, its choice of gated actions or its record retention satisfies an organization's legal and regulatory obligations is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

The published guidance agrees more than the debate suggests. Human approval before consequential action is treated as a standard control by OpenAI, Anthropic and the EU AI Act alike, and none of them asks for approval on every step. The sandboxing figure shows why: most prompts in an unbounded system are noise, and a bounded environment removes them, leaving a small set of decisions a person can read. What remains contested is placement. A gate the model operates is a gate the model's failures bypass; a gate the environment operates holds when the model is wrong. The design that follows is a classification, enforced outside the model, with a named approver and a record of what they saw, and RedactSure's Supervised Delegation is one implementation of it. The test is to name one agent and one task and ask: which actions in this task wait for a person, who is that person, and can the record show me what they saw when they said yes?

Frequently asked questions

Does every AI agent action need human approval?

No. Approval on every action produces fatigue, in which the person approves by reflex and the gate stops functioning. The published guidance from OpenAI and Anthropic reserves approval for consequential or high-stakes decisions. The practical design bounds the environment so that reads and reversible internal edits proceed without a prompt, and gates the actions that change balances, commit the organization, leave its boundary or cannot be undone. The result is a small number of real decisions rather than a stream of clicks.

What counts as a consequential action?

Three properties mark an action as one that should wait. Consequence: it changes a balance, a commitment or a record others rely on. Irreversibility: undoing it needs a new transaction, a notification or an apology rather than a quiet correction. Externality: it leaves the organization by sending a message, submitting to another party or moving money. Payments, submissions and record changes typically carry at least one of these. Reading a page, navigating between tabs and adding an internal note typically carry none.

Can the model decide for itself when to ask for approval?

It can be prompted to, but that is not a control. A model's decision to pause is a model output, and prompt injection and ordinary model error corrupt model outputs. The gate must be enforced by the environment that performs the action, so that a payment or a record change cannot be committed without approval regardless of what the model decided. Vendor documentation that treats approval as a configured property of the tool-use path, rather than as something the model volunteers, reflects this placement.

Who should be the approver?

The person who would have been accountable for the action had a human taken it. The billing supervisor approves refunds; the records owner approves retention changes; the person who owns a vendor relationship approves messages to that vendor. Approvals routed to a shared queue or to whoever is online satisfy the form of the control but not its purpose, because no one can later say who decided. The approver should be named per workflow in advance and recorded per action afterward.

How does sandboxing relate to approval?

They are one design. Sandboxing bounds what the agent can reach, so the environment prevents most unwanted operations without asking anyone. That removes the prompts that would otherwise have been noise, which is what Anthropic's reported 84% reduction in permission prompts measures. The approvals that remain are for actions the boundary permits but the organization wants a person to see. A system with approvals and no boundary fatigues its approvers; a system with a boundary and no approvals has no human decision on the actions that matter.

What should an approval record contain?

Four things for every gated action: what the agent proposed, what the approver saw when deciding, who the approver was, and when the action was committed. If the approver saw tokens in place of real identifiers, the record shows tokens, so the record does not become a new copy of the sensitive values. A record that answers who, what and when for a single refund or record change is the test of whether the approval design is an audit trail or only a queue.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.