Dangerous-action review

Problem Context

• The action may send money, issue refunds, change access, publish or delete customer-facing content, run production commands, deploy code, contact external recipients, submit legal or compliance material, launch a physical-world operation, or let an AI agent call a privileged tool.
• The action may not be destructive in the narrow sense; risk comes from external visibility, cost, permissions, security, customer impact, legal effect, production blast radius, or inability to recall the side effect.
• Users may encounter the review inside consoles, agent tool-call previews, workflow builders, admin tools, deployment screens, customer-support workspaces, finance tools, moderation systems, and mobile approval notifications.
• The system can compute or disclose action payload, target, risk reason, evidence, reviewer authority, freshness, alternatives, policy triggers, expected side effects, and execution result.

Selection Rules

• Choose dangerous-action review when the user is about to execute a high-impact action and needs to inspect the exact payload, risk, evidence, and side effects before it leaves the safe preview state.
• Use destructive action confirmation when the central risk is permanent deletion, removal, reset, cancellation, or unrecoverable loss of a named object.
• Use typed confirmation as an escalation when wrong-target risk is severe enough that the user must reproduce a visible target phrase.
• Use human approval gate when automation is already paused and cannot resume until an eligible human approves the next step; dangerous-action review may be initiated by the same user before manual or agent-assisted execution.
• Use review before submit for ordinary user-entered form answers; dangerous-action review is for high-impact side effects, privileged tools, production changes, external recipients, money, access, legal status, or safety-sensitive action.
• Use security warning when the system detected an unsafe destination, malware, phishing, certificate, transport, or file-risk signal.
• Show the action verb, target, payload, side effects, affected people or systems, evidence, uncertainty, policy trigger, freshness, permissions, alternatives, and execution boundary before Run is available.
• Block or re-open review when the action payload, target, permissions, evidence, policy, external state, model output, or run context changes after the review opened.
• Prefer safer alternatives such as dry run, preview, edit, schedule, sandbox, request approval, reduce scope, or cancel when the review exposes unresolved risk.

Required States

• Armed action state with verb, target, payload, actor, source, and exact execution boundary.
• Risk inventory state listing money, access, customer, production, legal, security, external-recipient, data, safety, or physical-world effects.
• Evidence and confidence state with source links, gaps, stale checks, and uncertainty stated in task language.
• Freshness revalidation state before execution when payload, target, permission, policy, or external data may have changed.
• Edit before run state that changes payload or scope and reopens the review summary.
• Dry run or preview state when the system can simulate the operation safely.
• Cancel, defer, escalate, or request approval state when risk remains unresolved.
• Run action state with duplicate-submit protection and one named action boundary.
• Blocked state for missing permission, stale evidence, policy restriction, maintenance freeze, or unresolved dependency.
• Executed state with audit receipt, side-effect result, failure handling, and rollback or follow-up status.
• Mobile compact review state that still exposes action, target, risk, evidence, side effect, and safe alternatives.

Interaction Contract

• The review is bound to a specific action ID, payload version, target, actor, permission scope, source context, evidence set, and policy trigger.
• The primary action label names the real operation, such as Send refund, Restart workers, Publish policy, Grant admin access, or Run production command.
• The review exposes what will happen outside the product boundary, including emails, webhooks, payments, permission changes, deployments, records, customer notifications, or irreversible third-party effects.
• Run is unavailable until required risk inventory, evidence freshness, permissions, and acknowledgements pass.
• Editing scope, payload, target, recipients, amount, command, environment, model output, or evidence returns the review to an updated pre-execution state.
• Opening a review from email, mobile, notification, or reopened tab revalidates current state and refuses stale actions.
• Cancel leaves the target unchanged and records no execution; defer, escalate, and request approval preserve the review context.
• Execution produces an audit record of the shown payload, reviewer, decision, timestamp, risk reason, revalidation result, side effects, and downstream outcome.

Implementation Checklist

• Define which operations count as dangerous by consequence: money movement, access changes, production commands, public publication, customer messaging, legal submission, sensitive data mutation, external integrations, safety-sensitive workflows, or privileged agent tool use.
• Capture action ID, actor, target, payload, recipients, environment, permissions, risk reason, policy trigger, evidence, confidence, source freshness, dry-run result, side effects, rollback options, and audit metadata.
• Design the review so the first screen names the action and target, then exposes risk inventory, evidence, alternatives, and execution controls without hiding the payload behind generic warnings.
• Add revalidation for stale payloads, changed recipients, changed permissions, expired evidence, maintenance windows, policy changes, model output changes, and external-state drift.
• Support safe alternatives such as edit, reduce scope, dry run, schedule, sandbox, request approval, escalate, cancel, or open supporting evidence.
• Prevent duplicate execution and make the in-progress boundary clear after the reviewer chooses the dangerous action.
• Record what was visible at review time and what actually executed, without logging secrets or unnecessary sensitive payload details.
• Test stale notification decisions, changed payloads, permission loss, duplicate clicks, mobile wrapping, keyboard flow, screen-reader status, audit receipt, failed execution, and post-run follow-up.

Common Generated-UI Mistakes

• Using vague Are you sure, Continue, or Proceed copy without naming the dangerous operation.
• Showing a risk warning but hiding the action payload, target, recipients, amount, command, environment, or external effect.
• Treating confidence, risk color, or severity score as a substitute for reviewable evidence.
• Allowing stale email or mobile approvals to execute a changed action.
• Combining many dangerous operations under one approval when the UI only described one of them.
• Using dangerous-action review for routine low-impact actions until reviewers stop reading.
• Recording only that a user clicked Run without preserving the shown payload and risk basis.

Critique Questions

• What exact action, target, payload, and side effects will execute if the reviewer continues?
• What makes this action dangerous: money, access, production, customer, legal, security, external recipient, data sensitivity, safety, or physical-world impact?
• What evidence, policy trigger, confidence, or freshness check supports the action, and what is missing?
• Can the reviewer edit, reduce scope, dry run, cancel, defer, request approval, or escalate instead of running?
• What revalidation prevents stale notifications, changed payloads, or lost permissions from executing?
• What audit record proves what the reviewer saw and what actually ran?
• Would destructive action confirmation, typed confirmation, human approval gate, security warning, or review before submit be more precise?