Anthropic reported this year that users accept 93% of the permission prompts its coding agent shows them. That is not a sign of trust. It is a sign that the prompt has stopped carrying information, and every SaaS team shipping an "Approve" button for an agent is building the same prompt.
This article argues that approval screens fail because they ask about the command instead of showing the consequence. It covers what to put on the screen, how to tier actions so people see fewer prompts, and how to tell when your own gate has turned into a rubber stamp. It is for product designers and PMs adding agents to a SaaS product.
A 93% approval rate is a design failure
The default way to make an agent safe is to ask the human first. Before it sends the email, edits the record or runs the command, a dialog appears with two buttons. It feels responsible, and it is easy to ship.
The data on how that goes is not kind. In its write-up of Claude Code's auto mode, Anthropic says that "in practice users accept 93%" of manual prompts, and that this leads to "approval fatigue, where people stop paying close attention to what they're approving." Anthropic's own answer was to automate most of the decisions with a classifier. That is a reasonable move for a developer tool. A customer-facing SaaS product has a different problem. You cannot hand the decision to a classifier and tell a finance manager it was fine.
A write-up on permission prompts as a UX bug makes the useful point that "the user approved it" should not end a post-mortem. The question is whether the interface made an informed approval possible. If the dialog shows UPDATE invoices SET status = 'void' WHERE ..., the answer is no, and the approval means nothing.
A high approval rate is the symptom, not the goal. Teams often read it as proof the agent is accurate. It can equally mean nobody is reading.
Agents change more than you asked
The bigger reason a bare confirmation fails is that the thing being confirmed is rarely the whole change. Trail of Bits looked at every patch its engineers wrote with AI agents and that maintainers merged upstream. In their review, over 130 merged pull requests contained 21 confirmed regressions, 16 of them functional. The agent fixed the reported bug and broke something nearby.
That is code, but the pattern carries over to product work. Ask an agent to "clean up duplicate contacts" and the stated action is a merge. The side effects are a changed owner on 40 deals, a deleted email thread and a broken automation that keyed on the old ID. The person approving sees "Merge 212 contacts?" and says yes.
Trail of Bits found that the fix on their side was evidence, not more confirmation. Their regression tool traces the change to real interfaces and demands a live reproduction for every claim. If a step cannot produce proof, the result is marked inconclusive. Strip the security language out and the design principle is simple: do not ask the human to trust a summary.
For approval UX, that means the screen should show the second-order effects the agent already knows about or can compute. Which records change, which other objects reference them, what stops working, and what cannot be undone.
Put the consequence on the screen
Four elements turn a confirmation into a review. None needs new technology. They need the backend to expose a dry run, which is the real cost of doing this well.
First, a diff. Show before and after for the fields that change, the way a code review does. "Status changes from Active to Void" on 212 rows is readable. Group identical changes and let the reviewer expand one example.
Second, the blast radius. Say how many records, which customers, which downstream systems. A count that stands out ("1 of 212 is a customer with an open dispute") does more than a paragraph of explanation.
Third, reversibility, stated plainly. "Undo available for 30 days" and "Cannot be undone" should look different, because they call for different levels of attention. The Amazon Bedrock confirmation pattern that AWS documents returns only the function name and parameter values for a yes/no. AWS's own guidance lists "the proposed action only, without the reasoning chain, data sources, or potential consequences" as an anti-pattern that turns review into a formality. Read that as a warning about default framework behavior. The stock approval step is the thing to design past.
Fourth, the reason. One line on why the agent chose this action, linked to the evidence. If the reason is weak, the reviewer should be able to see that it is weak.
I would also drop the bright green Approve button. Make the primary action "Apply 212 changes" so the button repeats the scope.
Fewer prompts, tiered by reversibility
Richer screens only work if people see fewer of them. The tianpan write-up estimates, as the author's own rough figure rather than a measured one, that people give roughly 10 to 20 genuinely attentive approvals per session before they start pattern-matching. Treat attention as a budget and spend it where it matters.
AWS gives a workable baseline: read-only operations proceed on their own, low-risk writes need one reviewer, and financial transactions, data deletion and external communications need stricter approval. A product designer can sort any agent action into three bins.
Reads and drafts need no gate. Show the result and let the user edit it. Reversible changes run, then appear in an activity feed with an undo button. This is review after the fact, and for most actions it beats a blocking dialog because the user sees the real result rather than a prediction. Irreversible or external actions block. Think sending to customers, refunding money, deleting data and changing permissions. These get the full diff, blast radius and reason.
Two cautions. Trust should not leak across categories. A user who approved ten report exports has told you nothing about whether they want the agent to issue refunds. And AWS warns against wildcard grants such as "always allow this type of action", which remove oversight for a whole class. Bound any "don't ask again" to a specific object, parameter shape or time window, and let people revoke it from one screen.
The classifier that sorts actions into tiers should be deterministic rules, not another model reading the same untrusted input. AWS makes this point directly, because adversarial content can talk a model into labeling a request low-risk.
Measure whether your gate is real
You can tell if an approval step works by instrumenting it. Most teams log approvals for audit and never look at them as a design signal.
Track three numbers per action type. The approve rate. A flat 100% means the gate is decorative or the action should not be gated. Time to decision. The tianpan article suggests alerting on approvals faster than about 800 milliseconds, which is a heuristic, but a click that quick cannot include reading. And the trend within a session, because latency that falls as the session goes on is fatigue showing up in your data.
Then run one cheap test this week. Take your three most common agent actions and plant a deliberately wrong proposal in a staging build, such as a refund to the wrong customer or a merge that includes a record that should not be touched. See how many reviewers catch it, with the current dialog and with a diff version. Anthropic's classifier testing found that humans caught a disguised dangerous command only 13.6% of the time, a figure reported in a DevOps.com summary of the auto mode work that I could not confirm against Anthropic's own post, so treat it as indicative. Your own catch rate is the number that counts.
A checklist for the sprint. List every action the agent can take. Mark each as read, reversible or irreversible. Delete the prompt on the first two and replace it with an activity feed and undo. For the third, build the dry run and render the diff, blast radius, reversibility and reason. Ship the instrumentation with it. If catch rates do not improve, the screen is not doing its job yet.
The same logic applies when the agent is not yours. Stores are already deciding how to handle outside shoppers' bots, as I covered in AI shopping agents at checkout. Whether the agent is inside your product or knocking at its door, the question is the same. What will a human be able to see before it acts?
Originally published on kireev.us.
Top comments (0)