The Are-You-Sure Confirmation Step Your Users Learned to Click Through
The confirmation dialog is the cheapest safety layer in the AI agent toolbox. It's a string, a button, and a callback. The product manager who asked for it left the meeting believing the agent was now safe. The engineer who built it shipped it in an afternoon. The compliance reviewer who audited it ticked the box. And the user who saw it for the seventh time that morning had already moved their mouse to the Confirm button before their eyes finished reading the title.
Within a week, the confirmation step is no longer a decision point. It's a rhythm. The agent says "are you sure you want to send this email?" and the user says yes the way they say bless-you at a sneeze. The day the agent proposes an action that is actually wrong — wrong recipient, wrong amount, wrong tone — the user confirms it with the same automaticity they used for the six correct ones before it, and the email goes out, and the team writes a postmortem that says "user error."
It wasn't user error. It was a system that mistook the existence of a click for the existence of consent.
Habituation is a feature of the user, not a bug in the dialog
The first thing to understand about confirmation prompts is that habituation is not a failure of attention. It's a successful adaptation. The user's brain encountered a stimulus that fired in identical form every time, with no information that predicted whether the action was risky or routine, and learned — correctly, by every reasonable inference rule — that the stimulus carried no signal worth processing.
A 2015 fMRI study at Brigham Young, University of Pittsburgh, and Google measured the visual cortex response to repeated security warnings and watched it collapse after the second exposure. By the fifth, the warning was, neurologically, not being seen. A separate 2014 SOUPS study found participants clicking through SSL warnings in under two seconds — fast enough that the click was a motor program, not a cognitive event. Another study reported that only 14% of users noticed when the text of a confirmation dialog was changed mid-experiment.
These numbers are not about lazy users. They are about a stimulus that gave the user no reason to keep paying attention, and a user whose attention reasonably went elsewhere. The dialog was designed to feel safe to the engineer who shipped it. It was not designed to remain salient to the user who lived with it.
When an AI agent fires the same generic confirmation before every tool call — "do you want to proceed?" — it is running this same habituation loop, but compressed. Agents act faster and more often than humans do. A user who saw a confirmation dialog from their old SaaS app twice a week now sees them from their agent twenty times a day. The half-life of attention to those dialogs is measured in hours, not months.
A friction budget, not a friction floor
The mental model that fails is treating confirmation as a uniform safety net you can drape over every irreversible action. The mental model that works is treating confirmation as a friction budget — a finite resource you can spend on a small set of decisions per session before the user stops processing any of them.
A friction budget has the property that spending it everywhere is the same as spending it nowhere. If every action gets a prompt, every prompt gets the same reflexive click. The high-stakes prompt that matters has been camouflaged by the dozens of low-stakes prompts that don't. The agent that tries to "be safe" by confirming everything has actually flattened the user's signal-to-noise ratio to zero, and is now operating with no confirmation at all — just the appearance of one.
The first move, before any UX work, is to build a stakes classifier on the action itself. Not on the action category — "email" is not a stake; "email to legal counsel quoting an unsigned contract" is a stake. Not on a static list — anything with a static list will be wrong on the action you didn't anticipate. A stakes classifier that can be evaluated per-call, scoring on dimensions like reversibility (can the user undo this in one click, or does it require a phone call?), blast radius (does this affect one record, one team, or one customer base?), and externality (does the result leave the user's control — sent, posted, paid?).
Actions below the threshold get no confirmation at all. The agent just does them, and the audit log records what happened. Actions above the threshold get confirmation that's worth the user's attention precisely because they don't see it often. The user who sees three confirmations a day, each one tied to something they would have wanted to think about, is a user whose confirmations still mean something.
The prompt has to surface the irreversibility, not just announce it
The second move is to stop asking "are you sure" and start showing what the user is committing to. A generic "are you sure you want to send this email?" is a question whose answer is always yes — because the user just told the agent to send it, and the agent is now asking the user to re-affirm the thing they already affirmed. The dialog is asking the user to ratify an intent, not to review an artifact.
A confirmation that earns its friction shows the artifact. The email itself, with the recipient, the subject, the body, and any attachments, rendered in the form the recipient will see it. The transfer, with the source account, the destination, the amount, and the resulting balance. The deletion, with the count of records, a sample of what's in them, and a statement of what depends on them. The user can now exercise judgment because the system has handed them the material for judgment. The preview is the confirmation; the button is just the trigger.
- https://uxplanet.org/confirmation-dialogs-how-to-design-dialogues-without-irritation-7b4cf2599956
- https://uxmag.com/articles/consent-fatigue-are-we-designing-people-into-compliance
- https://uxpsychology.substack.com/p/how-to-design-better-destructive
- https://uxmovement.com/buttons/how-to-design-destructive-actions-that-prevent-data-loss/
- https://www.smashingmagazine.com/2026/02/designing-agentic-ai-practical-ux-patterns/
- https://mantlr.com/blog/designing-for-ai-agents-ux-patterns-2026
- https://safeguard.sh/resources/blog/ai-agent-tool-confused-deputy-problem-2026
- https://www.cloudavize.com/security-fatigue-in-2026/
- https://www.helpnetsecurity.com/2015/03/19/polymorphic-security-warnings-more-effective-than-same-static-ones/
- https://dl.acm.org/doi/10.1145/2702123.2702322
- https://www.usenix.org/system/files/soups14-paper-bravo-lillo.pdf
- https://medium.com/design-bootcamp/the-one-click-action-paradox-why-sometimes-ux-should-make-you-think-twice-d7c3b514db7c
