Which AI agent actions should ask for confirmation every time, and which can users always allow?

Illustrative situation: on her second day with an AI agent inside a helpdesk, a support lead meets 41 approval prompts. By the afternoon she clicks “Always allow” without reading the label. The label on the “send email” prompt says only that, and she does not know it covers every recipient. On day nine the agent emails a refund notice to a customer’s old address. The code worked as written, and the permission did exactly what its label said. The scene is invented. It shows the problem this guide covers: the policy behind the prompts, not the design of any single prompt.

Humbleteam, a digital product design agency, publishes this guide. It covers the confirmation policy across many agent actions: tiers, the scope of “always allow,” where standing permissions are managed, admin limits, expiry, and logging. It includes a policy worksheet and an invented worked example. Product behavior is described as of November 5, 2026 and can change.

Why do too many confirmations make an agent less safe?

A prompt protects only when someone reads it. Anthropic’s engineers wrote in March 2026 that users accept 93% of Claude Code’s manual permission prompts and described approval fatigue as people no longer paying close attention to what they approve.

Browsers saw this earlier. A 2013 field study of more than 25 million warnings, “Alice in Warningland,” found that users continued past 70.2% of Chrome’s SSL warnings and about a third of Firefox’s SSL warnings. The authors concluded that the way a warning is presented has a large effect on behavior.

Users also drift toward fewer prompts with experience. Anthropic’s study of Claude Code usage found full auto-approve in about 20% of sessions for new users and over 40% for experienced ones, though part of that rise may be people changing settings.

So the goal of a confirmation policy is fewer prompts, each one worth reading, and standing permissions narrow enough that repeating a yes stays safe.

How do you sort actions into tiers?

Score every action the agent can take on four questions. Can it be undone? How many records, people, or dollars can it touch? What does it cost? Can someone outside the product see it? Sending, paying, deleting, and sharing usually score high on at least one. We suggest four tiers:

1. Never ask: reads inside the user’s own access, and drafts nobody else sees.
2. Ask once, then remember inside a named scope: reversible changes with a small blast radius.
3. Ask every time: external, costly, or hard-to-reverse actions.
4. Never allowed: actions the product blocks for everyone, whatever the user clicks.

Shipping products have the same shape. Claude Code’s permission table lets file reads run without asking, saves a Bash “don’t ask again” permanently per repository and command, and keeps a file-edit approval only until the session ends. Codex rules offer three decisions, allow, prompt, and forbidden, and the strictest matching rule wins. Cursor’s Run Modes page lists browser, file-deletion, and external-file protections that can require approval even in modes that otherwise run automatically.

MCP tools can carry hints for read-only, destructive, idempotent, and open-world behavior. The schema calls them hints and says clients should never base tool-use decisions on annotations from untrusted servers. Use them to suggest a tier, and let your own product assign it.

What should “allow once,” “this session,” and “always” cover?

A button that says “Always allow” is a rule with its scope hidden. Put the scope in the label: “Always allow replies to acme.com.”

Products differ in what they let the user scope. VS Code’s approvals page offers a command prefix or the exact command for the terminal, the displayed host only for web fetches, and a folder scope that covers the nearest Git repository for files. “In this Session” lasts for the session, while Always Allow saves for future sessions on the same agent host. Codex can suggest a prefix rule during an escalation, and its docs say to review the suggested prefix carefully. Claude Code offers “don’t ask again” options only when the prompt can show everything they would allow.

Command patterns are weaker scope than they look. The same Claude Code page warns that Bash patterns constraining arguments are fragile: a rule meant to limit curl to one site misses options placed before the URL, a different protocol, or a redirect. Where you can, scope by something the system checks exactly: a recipient domain, a folder, a record type, a dollar ceiling.

Where do users see, edit, and revoke standing permissions?

Users cannot revoke a standing permission they cannot find. Claude Code’s /permissions dialog lists every rule and the settings file it comes from, and a change applies at Claude’s next tool call. VS Code has a Manage Tool Approval command that separates approvals letting a tool run without a dialog from those letting its results enter the chat without review. A second command clears all saved approvals.

We suggest one list. Each row names the action, its scope in plain words, who set it (the user, an admin, or a team default), when it was last used, and one revoke control. “Last used” lets people prune. Link the list from the approval prompt itself, because that is where the decision happens.

How do admins cap what users can auto-allow?

Across products, the admin sets a ceiling and users work below it.

• Claude Code: allowManagedPermissionRulesOnly makes managed settings the only source of permission rules, according to the settings reference, and the permissions page says a deny at any level cannot be allowed at another.
• Cursor: team settings take precedence over individual and project configuration, and admins can override which run modes users get.
• Codex: admins can enforce restrictive prefix rules through requirements.toml, and managed requirements take precedence over local settings.
• VS Code: device management policies can force manual approval for specific tools.

When a cap removes an option, say so in the prompt: “Your admin requires approval for refunds.” Users should be able to set a stricter rule than the admin, never a looser one. That wording is ours; the sources describe the controls, not the screens.

When should a permission expire or ask again?

Browsers and phones already expire grants. Chrome’s one-time permissions, added in Chrome 116, end when the page closes, after 16 hours, or after the page has been in the background for 5 minutes. Android 11 added “Only this time” for location, microphone, and camera, and resets sensitive permissions of unused apps after a few months.

Agent tools expire some grants too. Claude Code keeps a file-edit approval until the session ends. On entering auto mode it drops broad allow rules such as Bash(*) and keeps narrow ones such as Bash(npm test), then restores them on exit.

We suggest five re-prompt triggers: the scope changes (a new recipient, folder, or host), the count grows past the one shown at approval, the tool itself changes, a long idle period passes, or the user’s role changes. MCP servers can announce a changed tool list, and the tools spec says servers that declare the capability should send a notification. Name the trigger in the prompt: “Asking again because this address is new.”

Should auto-approved actions be logged?

Yes. The MCP tools spec says clients should show tool inputs before a call and log tool usage for audit. Claude Code’s auto mode lists blocked actions under a Recently blocked tab in /permissions.

We suggest the same for allowed actions. Every auto-approved step appears in the activity history with the rule that allowed it, such as “Allowed by: notes to my team, saved Oct 28,” and a control that turns the rule off from that row. A short digest after the first week, listing which rules ran most, helps people tighten what they set in a hurry. What the record should show for each step is covered in our guide to an agent’s activity history.

Illustrative worked example: the helpdesk agent

Everything here is invented. Orchard Desk is a fictional helpdesk product with an agent that drafts replies, updates tickets, and issues refunds. Noor Ashby leads support and opens the permissions list on her first day.

Reads and drafts never ask. Ticket edits ask once per session, scoped to “tickets in the Billing queue.” Notes to her own team can be remembered for that team. Replies to customers ask every time, and the only standing option is “Allow this thread.” Refunds ask every time, and an admin ceiling of $100 sends larger ones to a manager. Deleting tickets and changing who can see a queue are never allowed to the agent.

On day nine the agent drafts a reply to an address from an old record. The prompt reads “Asking again: this address is new for this customer” and shows the old and new addresses side by side. Noor rejects it. The team-notes permission is untouched, and the list shows it as “used 14 times, last today.”

Where do these rules stop working?

The sources are product documentation, one vendor post with usage data, one vendor study, and a 2013 browser study. We found no study that compares confirmation policies for AI agents, so the tiers and worksheet values are suggestions to test. The browser data covers security warnings, not agent approvals, and Firefox remembers an SSL exception by default while Chrome asks every time, so the two browsers’ rates are not directly comparable.

Vendors also say their own allowlists are not hard limits. VS Code calls terminal auto-approval a best-effort convenience, and Cursor calls run modes best-effort guardrails. Enforce limits in the system that performs the action, and treat the prompt as the explanation. OpenAI’s ChatGPT agent help article could not be opened, so that product is not covered. Regulated settings, shared accounts, and multi-agent runs need their own review.

What can you produce now?

Five things, before anyone draws the prompt:

1. The worksheet above, filled in for every action your agent can take.
2. A scope label for each “always” choice, written the way a user reads it.
3. A permissions list spec: columns, who set it, last used, revoke.
4. An admin ceiling table: which tiers an admin can lock, and the message users see.
5. A re-prompt rule per tier, with the exact sentence naming the trigger.

With those, you can test the helpdesk example above on a real workflow. For the single approval screen, including the fields it shows and what happens when the proposal changes, read our guide to approval, undo and human handoff for AI agents. For the step before a long run, see what a task setup screen should ask. For role-based limits, see permissions UX for enterprise AI. If you are choosing a partner for this work, our comparison of agencies with published agent-flow cases is a starting point.