TL;DR
An AI assistant that asks permission for every small step can make the important requests easy to miss. Let routine work run inside clearly defined, tested limits. Ask a person before an action changes those limits or creates a consequence they need to judge. Show exactly what will happen, what remains uncertain, and how to decline. Removing a prompt is useful only when the replacement control works; a quieter workflow must not silently grant broader access.
In this article
Last updated October 15, 2026
7 min read
“Approve” can mean permission to read a file, agreement with a proposed change, or permission to send that change to someone else. Those decisions need different information. Putting them behind the same button leaves the reviewer to work out the difference every time.
A useful starting point is the next action: what can it affect, can it be reversed, and who is able to judge it? That is more specific than deciding whether to trust an AI assistant in general.
Why constant confirmation is a weak safeguard
Anthropic reports that users approved roughly 93% of permission prompts in its telemetry. It also describes declining attention as approvals became routine. That is an observation from its own product, not a universal approval rate or proof that any particular human review failed. Its account of containment across Claude products argues for technical limits alongside supervision.
The wider human-factors literature helps explain why attention deserves consideration. Parasuraman and Manzey’s review of automation complacency and bias connects these problems with attention and competing tasks. It is general automation research, not a measurement of coding-agent users. It does not establish a safe number of prompts per hour.
So use approval counts to locate interruptions, then inspect what those interruptions ask someone to decide. A high acceptance rate could reflect sensible requests. It could also reflect prompts that people cannot interpret. The percentage alone cannot distinguish them.
One task can need three different controls
Consider an illustrative task: prepare a diagnostic report from an application’s test results and send it to an external support contact. This is a proposed workflow, not a customer incident or an executed security test.
Preparing the report and sending it are separate actions. A team might allow the assistant to read a specific test-output directory and create a local draft. That permission need not include reading credentials, contacting arbitrary servers, or emailing the result.
Choose the control
| Action | Control | Verify |
|---|---|---|
| Read the named test-output folder | Allow inside a restricted workspace | Access stays within that folder |
| Read secrets outside folder | Deny access | A request cannot override the boundary |
| Send the prepared report | Review the exact send | Recipient, attachment and sensitive content are checked |
These are design choices for the example. Reading files can itself be sensitive, and a test command can have network or filesystem side effects. A command’s familiar name does not make it harmless. Determine its actual permissions and behaviour before putting it on an allowlist.
This is where risk-based development lanes help: group work by its consequences and required evidence, then decide which controls apply. Do not use the size of a code change as a substitute for examining its effect.
Make the approval request about the action
A reviewer should not need to reconstruct a long conversation to discover that a report contains private data. The request should expose the material decision directly, with access to the underlying draft.
The unresolved check is a reason to keep this request pending. Do not present “approve anyway” as the default way to clear the queue. If the reviewer cannot assess the logs, route that part to someone who can; the original owner still needs to know what answer they are waiting for.
Bind the eventual answer to the recipient and report that were reviewed. If either changes, the earlier answer no longer describes the proposed send. A new review should show the difference rather than ask the person to reread an unchanged transcript.
What an “approved” flag misses
A small local Python example makes the scope problem visible. It starts with a synthetic report and a recipient at example.invalid. One check looks only for an approved status. The other also compares the proposed recipient and report with the reviewed values:
status == "approved" and proposed == reviewedThe example ran with Python 3.14.2. These are its observed results; “allow” means the comparison returned true, not that an email was sent.
Local comparison results
| Case | Status only | Status + scope |
|---|---|---|
| Waiting | Deny | Deny |
| Rejected | Deny | Deny |
| Reviewed action | Allow | Allow |
| Recipient changed | Allow | Deny |
| Report changed | Allow | Deny |
The status-only check accepts both changed actions because it never examines what was approved. Comparing the two reviewed values catches those changes in this example. It also gives a reviewer a concrete reason for a fresh request: the destination or material has changed.
This is a reproducible comparison, not a secure sending system. The two dictionaries contain only recipient and report. Real execution needs to preserve all relevant parameters, authenticate the decision, and prevent a change between checking and sending. Persistence, concurrent changes and actual sending were not tested here.
Check that waiting really prevents the action
A written instruction to wait is only one part of the design. The process that can send the report needs to enforce the decision. Keep its credentials and execution path outside work that should remain limited to drafting.
Before relying on that arrangement, rehearse it with fake data and a controlled destination. Leave the decision unanswered and confirm that nothing sends. Reject it and check the same result. Change the recipient after a test approval and confirm that the old answer cannot authorise the new destination. Include a restart so that “waiting” is not lost when the process resumes.
These are proposed checks for the example, not tests performed for this article. A failed rehearsal is a control defect to repair, even if the assistant’s final message says it waited correctly. The human review authority guide develops the distinction between giving an opinion and controlling what happens next.
Remove interruptions without hiding uncertainty
Review a short, representative set of recent approval requests. For each one, record the action it would permit and what the reviewer had to establish. Mark requests that repeat an unchanged decision, lack enough information, or ask the wrong owner.
Replace a redundant request only when another control covers its purpose. For example, preparation within a restricted workspace may proceed without repeated permission, while the external send stays paused. If the team cannot enforce that separation, retain the necessary restriction and fix the execution path first.
After the change, look for requests returned for missing evidence, decisions that changed the proposed action, and actions that occurred outside the accepted scope. Record the type and number of reviewed requests alongside those observations. Faster response time is useful context, but it does not establish that reviewers understood more or prevented harm.
If your team needs help separating routine preparation from decisions with real consequences, request an AI Delivery Programme conversation.
Frequently Asked Questions
How do you design human approval without approval fatigue?
Begin with the requests people struggle to answer. Ask the reviewer what information was missing and whether their answer could change the action. That reveals whether to improve the request, move it to another owner, or replace a redundant interruption with an enforceable rule.
Which AI decisions actually require a human gate?
A useful trigger is an unresolved choice about who may be affected or what outcome is acceptable. Technical checks can establish facts, but they cannot supply an owner’s missing intent. Even after that intent is settled, an organisation may retain a separate release approval required by its own policy.
Can several actions share one approval?
Only when the reviewer can understand the group and the approval identifies every included action. Avoid combining an ordinary local change with an external action that has different consequences. If one item changes, define whether it leaves the group or causes the whole request to return for review.
What should happen when the reviewer is unavailable?
Name an authorised substitute in advance, together with the decisions they may make. A timeout should notify or escalate according to that arrangement. Silence should not become consent. Independent preparation can continue where it does not depend on the missing answer.
Does an approval still count after the underlying data changes?
Recheck the facts the decision depended on. A reviewer may have accepted a report built from one dataset, while a later run adds different records. Preserve the reviewed version and explain what changed before using the answer for a new result.
How do we know whether a reviewer understood the request?
Ask them to explain the intended effect and the unresolved concern in their own words during a sample review. If they cannot, inspect the request and their access to evidence before blaming attention. This is a diagnostic conversation, not a validated psychological test or a quota for rejecting work.
