Back to compare picker

Dangerous-action review vs Destructive action confirmation vs Typed confirmation vs Human approval gate vs Review before submit vs Security warning

Choose dangerous-action review when the action is armed but not yet executed and users need to inspect action verb, target, payload, actor, risk reason, evidence, freshness, permissions, side effects, safer alternatives, and audit before running it.

Decision dimensions

Dimension Dangerous-action reviewDestructive action confirmationTyped confirmationHuman approval gateReview before submitSecurity warning
UI or UX UI + UX - Pre-execution review of high-impact actions that may affect money, access, production systems, legal status, customers, external recipients, or safetyUI + UX - Final destructive commit reviewUI + UX - Exact target phrase gate before severe commitUI + UX - Runtime checkpoint that pauses AI or automation until an eligible human authorizes the next stepUI + UX - Final editable answer summary before committing a transactionUI + UX - Security-risk warning and safe interruption before unsafe navigation, download, submission, preview, or sensitive action
UI guidance Render dangerous-action review as a pre-execution checkpoint that names the armed action, actor, target, scope, affected systems, external effects, risk reason, evidence, freshness, permissions, alternatives, and exact outcome of Run, Cancel, Edit, or Escalate.Render a destructive confirmation after the user invokes a destructive command, with a title and final action button that repeat the destructive verb and target, such as Delete workspace or Cancel subscription.Render a visible non-secret text field inside a destructive or high-consequence confirmation, labelled with the exact target phrase the user must type before the final action enables.Render a human approval gate as a paused automation checkpoint with the proposed action, tool or workflow step, triggering rule, risk level, payload snapshot, requester or agent, approver eligibility, timeout, and explicit approve, reject, edit, cancel, or bypass controls.Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action.Render a security warning as a high-clarity interruption that names the detected risk, identifies the destination or object, explains the concrete threat, presents the safest action as the primary path, and separates any override behind deliberate risk detail.
UX guidance Use dangerous-action review when an action is not necessarily destructive but can create high-impact consequences such as sending money, changing access, executing production commands, contacting customers, publishing content, filing a legal response, or letting an agent use a privileged tool.Use destructive action confirmation to create one informed stop before permanent or externally visible loss, not to slow every routine cleanup action.Use typed confirmation only when reproducing the target phrase meaningfully reduces severe wrong-object or wrong-scope mistakes, such as deleting a repository, project, account, workspace, production dataset, or root credential.Use human approval gate when automation is ready to act but policy, risk, confidence, cost, access, publication, deployment, customer impact, or legal consequence requires a human decision before execution continues.Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed.Use security warning when a product, browser, operating system, or service has evidence that proceeding could expose credentials, install harmful software, leak sensitive data, bypass trust, or weaken account protection.
Good UI A production console shows Restart payment workers, affected region, open incidents, customer impact, rollback owner, evidence links, change window, dry-run result, and Run restart only after the reviewer checks the risk inventory.Delete Payments project? lists 4 dashboards, 12 saved views, 3 webhooks, and 8 shared links, offers Keep project, and labels the danger action Delete Payments project.Delete repository acme/payments-api? requires typing acme/payments-api, shows a mismatch until the exact path matches, and then enables Delete repository.An AI support agent pauses before issuing a refund, shows the proposed amount, customer, policy match, confidence, source grounding, approver role, timeout, Approve refund, Edit amount, Reject, and Stop run controls.A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address.A browser interstitial says Deceptive site ahead, shows the suspicious domain, explains that attackers may steal passwords, and makes Back to safety the primary action while placing Visit unsafe site behind Details.
Bad UI A privileged tool button says Continue and immediately sends a customer email, changes access, and updates billing without showing the payload or external recipients.A modal says Are you sure? with OK and Cancel after the user clicks Delete, without naming the project or what disappears.A dialog asks users to type YES before deleting a workspace, so the text does not verify the target object.A banner says Human approval needed but does not show the tool call, payload, approver, timeout, or resume consequence.A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links.A red page says Security issue with Continue as the only visible action.
Good UX A release manager sees that a deploy action affects production EU, has a stale smoke test, cancels execution, refreshes checks, and then runs the action with an audit record.A user opens Delete workspace, reviews the object count and webhooks, cancels, and returns to the same workspace with nothing changed.A user starts deleting acme/payments-api, mistypes the repository path, sees the mismatch, and cancels before deleting the wrong repository.A billing lead opens the paused refund gate, sees that the amount is under policy but source grounding is partial, edits the refund to the verified amount, approves, and the agent resumes only that step.A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved.A user clicks a payroll link that visually resembles the company domain, sees the suspicious-domain warning, returns to the trusted site, and reports the link to security.
Bad UX A user approves a notification from email after the underlying payload changed, and the system executes against a different customer.A user confirms deletion because OK looks like the primary next step, then discovers shared links and child reports were lost.A user types DELETE by habit and passes the gate without checking which workspace will be removed.A human approves a stale agent action from email and the agent applies it to a different customer state.A user selects Change address, edits one field, then has to repeat every later page before finding the review page again.A user sees a vague warning, assumes it is routine maintenance, proceeds, and enters credentials into a phishing page.
Best fit A user, agent, automation, or admin tool is about to execute a high-impact action that can affect money, access, production systems, legal/compliance state, customers, external recipients, sensitive data, or safety.A user has initiated a destructive command that can permanently remove, revoke, reset, deactivate, or cancel something valuable.A severe action affects repository, project, workspace, account, production, security, billing, or organization-wide scope.An AI agent, workflow, deployment, or automation is ready to perform a high-impact step and must pause for human authorization.A user has provided multiple answers and should verify them before a consequential submit action.A threat signal indicates phishing, malware, deceptive site, unsafe download, invalid certificate, insecure connection, mixed-content submission, suspicious redirect, file preview risk, or account-security danger.
Avoid when The risk is narrowly permanent deletion or loss of a named object; use destructive action confirmation.The action is a routine reversible archive, hide, dismiss, move, reorder, or trash move.The action is routine, reversible, local, or recoverable through undo or trash restore.The action has already happened and users only need an audit log.The task is a single low-risk field with clear inline validation and an obvious submit action.The message is only a general severe consequence before a product action; use warning text.
Required state Armed action state with verb, target, payload, actor, source, and exact execution boundary.Idle state where the destructive command is visible but not committed.No-typed-gate state for actions that do not need target-text escalation.Paused gate state with proposed action, payload snapshot, reason for gate, and run context.Initial review state with grouped captured answers, relevant sections, and explicit submit action.Safe path state with primary Back to safety, Cancel, Remove, Use trusted route, or Contact admin action.
Accessibility burden Use headings and labels that name the action and target before risk details.Use alertdialog semantics or platform equivalent when the destructive decision requires an immediate response.Associate the input with a label that includes or references the required phrase.Expose gate status, proposed action, target, payload summary, risk, approver rule, timeout, and current run state as text.Use headings that make the review task explicit, such as Check your answers before sending your application.Use a heading and text that name the risk before the destination or details, so screen reader users hear the warning context first.
Common misuse Using vague Are you sure, Continue, or Proceed copy without naming the dangerous operation.Using a vague Are you sure prompt that does not name the object, count, or consequence.Requiring users to type yes, confirm, or delete instead of the target name.Showing Approve without the exact action, payload, target, risk, or resume consequence.Using a review page that contains no captured answers.Using vague warning copy that does not say phishing, malware, certificate, insecure connection, dangerous download, or suspicious redirect.

Dangerous-action review

UI or UX
UI + UX - Pre-execution review of high-impact actions that may affect money, access, production systems, legal status, customers, external recipients, or safety
UI guidance
Render dangerous-action review as a pre-execution checkpoint that names the armed action, actor, target, scope, affected systems, external effects, risk reason, evidence, freshness, permissions, alternatives, and exact outcome of Run, Cancel, Edit, or Escalate.
UX guidance
Use dangerous-action review when an action is not necessarily destructive but can create high-impact consequences such as sending money, changing access, executing production commands, contacting customers, publishing content, filing a legal response, or letting an agent use a privileged tool.
Good UI
A production console shows Restart payment workers, affected region, open incidents, customer impact, rollback owner, evidence links, change window, dry-run result, and Run restart only after the reviewer checks the risk inventory.
Bad UI
A privileged tool button says Continue and immediately sends a customer email, changes access, and updates billing without showing the payload or external recipients.
Good UX
A release manager sees that a deploy action affects production EU, has a stale smoke test, cancels execution, refreshes checks, and then runs the action with an audit record.
Bad UX
A user approves a notification from email after the underlying payload changed, and the system executes against a different customer.
Best fit
A user, agent, automation, or admin tool is about to execute a high-impact action that can affect money, access, production systems, legal/compliance state, customers, external recipients, sensitive data, or safety.
Avoid when
The risk is narrowly permanent deletion or loss of a named object; use destructive action confirmation.
Required state
Armed action state with verb, target, payload, actor, source, and exact execution boundary.
Accessibility burden
Use headings and labels that name the action and target before risk details.
Common misuse
Using vague Are you sure, Continue, or Proceed copy without naming the dangerous operation.

Destructive action confirmation

UI or UX
UI + UX - Final destructive commit review
UI guidance
Render a destructive confirmation after the user invokes a destructive command, with a title and final action button that repeat the destructive verb and target, such as Delete workspace or Cancel subscription.
UX guidance
Use destructive action confirmation to create one informed stop before permanent or externally visible loss, not to slow every routine cleanup action.
Good UI
Delete Payments project? lists 4 dashboards, 12 saved views, 3 webhooks, and 8 shared links, offers Keep project, and labels the danger action Delete Payments project.
Bad UI
A modal says Are you sure? with OK and Cancel after the user clicks Delete, without naming the project or what disappears.
Good UX
A user opens Delete workspace, reviews the object count and webhooks, cancels, and returns to the same workspace with nothing changed.
Bad UX
A user confirms deletion because OK looks like the primary next step, then discovers shared links and child reports were lost.
Best fit
A user has initiated a destructive command that can permanently remove, revoke, reset, deactivate, or cancel something valuable.
Avoid when
The action is a routine reversible archive, hide, dismiss, move, reorder, or trash move.
Required state
Idle state where the destructive command is visible but not committed.
Accessibility burden
Use alertdialog semantics or platform equivalent when the destructive decision requires an immediate response.
Common misuse
Using a vague Are you sure prompt that does not name the object, count, or consequence.

Typed confirmation

UI or UX
UI + UX - Exact target phrase gate before severe commit
UI guidance
Render a visible non-secret text field inside a destructive or high-consequence confirmation, labelled with the exact target phrase the user must type before the final action enables.
UX guidance
Use typed confirmation only when reproducing the target phrase meaningfully reduces severe wrong-object or wrong-scope mistakes, such as deleting a repository, project, account, workspace, production dataset, or root credential.
Good UI
Delete repository acme/payments-api? requires typing acme/payments-api, shows a mismatch until the exact path matches, and then enables Delete repository.
Bad UI
A dialog asks users to type YES before deleting a workspace, so the text does not verify the target object.
Good UX
A user starts deleting acme/payments-api, mistypes the repository path, sees the mismatch, and cancels before deleting the wrong repository.
Bad UX
A user types DELETE by habit and passes the gate without checking which workspace will be removed.
Best fit
A severe action affects repository, project, workspace, account, production, security, billing, or organization-wide scope.
Avoid when
The action is routine, reversible, local, or recoverable through undo or trash restore.
Required state
No-typed-gate state for actions that do not need target-text escalation.
Accessibility burden
Associate the input with a label that includes or references the required phrase.
Common misuse
Requiring users to type yes, confirm, or delete instead of the target name.

Human approval gate

UI or UX
UI + UX - Runtime checkpoint that pauses AI or automation until an eligible human authorizes the next step
UI guidance
Render a human approval gate as a paused automation checkpoint with the proposed action, tool or workflow step, triggering rule, risk level, payload snapshot, requester or agent, approver eligibility, timeout, and explicit approve, reject, edit, cancel, or bypass controls.
UX guidance
Use human approval gate when automation is ready to act but policy, risk, confidence, cost, access, publication, deployment, customer impact, or legal consequence requires a human decision before execution continues.
Good UI
An AI support agent pauses before issuing a refund, shows the proposed amount, customer, policy match, confidence, source grounding, approver role, timeout, Approve refund, Edit amount, Reject, and Stop run controls.
Bad UI
A banner says Human approval needed but does not show the tool call, payload, approver, timeout, or resume consequence.
Good UX
A billing lead opens the paused refund gate, sees that the amount is under policy but source grounding is partial, edits the refund to the verified amount, approves, and the agent resumes only that step.
Bad UX
A human approves a stale agent action from email and the agent applies it to a different customer state.
Best fit
An AI agent, workflow, deployment, or automation is ready to perform a high-impact step and must pause for human authorization.
Avoid when
The action has already happened and users only need an audit log.
Required state
Paused gate state with proposed action, payload snapshot, reason for gate, and run context.
Accessibility burden
Expose gate status, proposed action, target, payload summary, risk, approver rule, timeout, and current run state as text.
Common misuse
Showing Approve without the exact action, payload, target, risk, or resume consequence.

Review before submit

UI or UX
UI + UX - Final editable answer summary before committing a transaction
UI guidance
Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action.
UX guidance
Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed.
Good UI
A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address.
Bad UI
A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links.
Good UX
A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved.
Bad UX
A user selects Change address, edits one field, then has to repeat every later page before finding the review page again.
Best fit
A user has provided multiple answers and should verify them before a consequential submit action.
Avoid when
The task is a single low-risk field with clear inline validation and an obvious submit action.
Required state
Initial review state with grouped captured answers, relevant sections, and explicit submit action.
Accessibility burden
Use headings that make the review task explicit, such as Check your answers before sending your application.
Common misuse
Using a review page that contains no captured answers.

Security warning

UI or UX
UI + UX - Security-risk warning and safe interruption before unsafe navigation, download, submission, preview, or sensitive action
UI guidance
Render a security warning as a high-clarity interruption that names the detected risk, identifies the destination or object, explains the concrete threat, presents the safest action as the primary path, and separates any override behind deliberate risk detail.
UX guidance
Use security warning when a product, browser, operating system, or service has evidence that proceeding could expose credentials, install harmful software, leak sensitive data, bypass trust, or weaken account protection.
Good UI
A browser interstitial says Deceptive site ahead, shows the suspicious domain, explains that attackers may steal passwords, and makes Back to safety the primary action while placing Visit unsafe site behind Details.
Bad UI
A red page says Security issue with Continue as the only visible action.
Good UX
A user clicks a payroll link that visually resembles the company domain, sees the suspicious-domain warning, returns to the trusted site, and reports the link to security.
Bad UX
A user sees a vague warning, assumes it is routine maintenance, proceeds, and enters credentials into a phishing page.
Best fit
A threat signal indicates phishing, malware, deceptive site, unsafe download, invalid certificate, insecure connection, mixed-content submission, suspicious redirect, file preview risk, or account-security danger.
Avoid when
The message is only a general severe consequence before a product action; use warning text.
Required state
Safe path state with primary Back to safety, Cancel, Remove, Use trusted route, or Contact admin action.
Accessibility burden
Use a heading and text that name the risk before the destination or details, so screen reader users hear the warning context first.
Common misuse
Using vague warning copy that does not say phishing, malware, certificate, insecure connection, dangerous download, or suspicious redirect.
Decision rules
  • Choose dangerous-action review when the action is armed but not yet executed and users need to inspect action verb, target, payload, actor, risk reason, evidence, freshness, permissions, side effects, safer alternatives, and audit before running it.
  • Choose destructive action confirmation when the dominant risk is permanent deletion, removal, reset, cancellation, revocation, or unrecoverable loss of a named object.
  • Choose typed confirmation when a severe wrong-target mistake is plausible and reproducing a visible repository, workspace, account, dataset, or target phrase materially reduces that risk.
  • Choose human approval gate when an automation or agent run is paused and cannot resume a specific step until an eligible human approves, rejects, edits, times out, or bypasses it.
  • Choose review before submit when the initiating user is checking ordinary form answers, entered data, or a transaction summary before submission rather than inspecting a privileged or high-impact operation.
  • Choose security warning when the system has detected an unsafe destination, phishing risk, malware, dangerous download, invalid certificate, insecure connection, suspicious redirect, mixed-content form, or file-preview risk.
  • Dangerous-action review should name high-impact consequences such as money movement, access grant, production command, customer notification, public publication, legal or compliance submission, external webhook, sensitive data mutation, privileged agent tool call, safety-sensitive action, or physical-world operation.
  • Dangerous-action review must expose safe alternatives such as edit payload, reduce scope, dry run, schedule, sandbox, cancel, defer, request approval, or escalate; generic Continue and warning-only copy are not enough.
  • Dangerous-action review must revalidate stale payload, target, permission, evidence, policy, model output, run context, and external state before allowing Run from reopened tabs, notifications, mobile links, or email.
  • Do not use dangerous-action review for routine low-risk tasks, recoverable cleanup, or actions where the product cannot show the payload or enforce a pre-execution boundary.
Inspect live examples
Failure modes
  • A user runs a production command after seeing only Continue, without environment, blast radius, stale check, rollback owner, or dry-run result.
  • A dangerous-action review is used for simple file deletion even though destructive action confirmation or undo would be more precise.
  • A typed phrase is added to a high-impact workflow but the UI hides the actual side effects, evidence gaps, and external recipients.
  • A paused automation approval is shown as a generic risk review and fails to enforce eligible approver, self-review, timeout, stale gate, or resume semantics.
  • An ordinary review-before-submit page is escalated into a severe risk review, creating habituation without adding risk evidence.
  • A security-warning case is handled as user discretion even though policy should block malware, phishing, certificate, or unsafe download risk before exposure.
  • A stale email or mobile decision executes after amount, recipient, command, model output, policy, or permission changed.
  • The audit record says Approved but cannot reconstruct what payload, evidence, risk inventory, and alternatives were visible before execution.