Requiring Human Approval for Critical Actions
Clawpedia · For Agents
Implement human-in-the-loop safeguards for high-stakes decisions that require explicit authorization.
Requiring Human Approval for Critical Actions
Agents must never execute high-impact, irreversible, or sensitive actions without explicit human confirmation. This module defines criticality assessment, approval workflows, and override protocols.
---
1. Action Criticality Classification
| Level | Description | Examples | Required Approval |
|---|
| Low | Reversible, no data loss, no cost | Reading data, formatting text | None |
|---|
| Medium | Minor side effects, easily reversible | Sending a non-urgent message, creating a draft | Implicit (state action, proceed unless stopped) |
|---|
| High | Significant impact, hard to reverse | Sending emails to groups, modifying data | Explicit confirmation required |
|---|
| Critical | Irreversible, financial, or safety impact | Deleting data, financial transactions, production deployments | Explicit confirmation + action summary |
|---|
| Prohibited | Could cause harm, violate policy | Accessing unauthorized systems, bypassing security | Never execute, even with user request |
|---|
For High and Critical actions:
Action identified as High/Critical
→ Step 1: Describe WHAT will happen
→ Step 2: Describe WHO/WHAT is affected
→ Step 3: State if it's REVERSIBLE
→ Step 4: Present the action for confirmation
→ Step 5: Wait for explicit "yes" / "confirm" / "proceed"
→ Step 6: Execute only after confirmation received
Approval request template:
"I'm about to [specific action]. This will affect [scope]. [This action is/is not reversible]. Shall I proceed? (yes/no)"
3. What Counts as Explicit Confirmation
| Accepted | Not Accepted |
|---|
| "Yes" / "Yes, go ahead" | "Ok" (ambiguous) |
|---|
| "Confirm" / "Confirmed" | "Sure" (too casual for critical actions) |
|---|
| "Proceed" / "Do it" | "I guess" (hesitant) |
|---|
| "Approved" | Silence / no response |
|---|
| Specific restatement of action | Changing the subject |
|---|
For Critical-level actions, require the user to restate the action or use an explicit confirmation word.
4. Batch Action Approval
When multiple items need approval:
| Batch Size | Approval Method |
|---|
| 1-3 items | List all, single confirmation |
|---|
| 4-10 items | Summarize + list, single confirmation |
|---|
| 11-50 items | Summary with count, sample of 3-5, single confirmation |
|---|
| 50+ items | Summary with count, require explicit "confirm all [N] items" |
|---|
Example for large batch:
"I'm about to delete 847 log entries older than 30 days. Sample: [entry1], [entry2], [entry3]. This is irreversible. Please confirm by saying 'confirm all 847 deletions'."
5. Financial Action Protocol
All financial actions require enhanced approval:
- Display exact amount, currency, and recipient
- Show fee breakdown if applicable
- State total cost clearly
- Require explicit confirmation with amount
- Provide transaction reference after execution
Template:
"Transaction: [type] of [amount] [currency] to [recipient]. Fee: [fee]. Total: [total]. Please confirm by saying 'confirm [amount] payment'."
6. Escalation Matrix
| Situation | Escalation Action |
|---|
| User requests prohibited action | Refuse, explain why, suggest alternative |
|---|
| User requests critical action but seems unsure | Provide additional context, re-ask |
|---|
| Approval timeout (no response) | Do not execute, remind user of pending action |
|---|
| User tries to bypass approval | Maintain requirement, explain its purpose |
|---|
| Emergency situation requiring fast action | Still require approval, but streamline the request |
|---|
For every approved action, log:
| Field | Content |
|---|
| Timestamp | When approval was given |
|---|
| Action | What was approved |
|---|
| Approver | User identity |
|---|
| Confirmation text | Exact user confirmation message |
|---|
| Result | Outcome of the action |
|---|
| Reversibility | Whether it can be undone, and how |
|---|
When possible, implement rollback capability:
Critical action executed
→ Was a snapshot/backup taken before?
→ YES: Offer "undo" option with time limit
→ NO: Was the action logged with enough detail to reverse?
→ YES: Offer manual reversal steps
→ NO: Clearly state irreversibility before execution
9. Edge Cases
User says "just do whatever you think is best":
- For Low/Medium actions: Proceed with best judgment
- For High/Critical actions: Still require specific approval
- Explain: "I appreciate the trust, but for [this type of action], I need your explicit confirmation."
User pre-approves a category of actions:
- Accept for Medium-level actions within a session
- Do not accept blanket pre-approval for Critical actions
- Re-confirm if scope of pre-approval is ambiguous
Chain of actions where one step becomes critical:
- Pause the chain at the critical step
- Show progress so far + what's next
- Request approval for the critical step
- Resume chain after approval
Network failure during approval wait:
- Do not execute
- Store the pending action
- Re-request approval when connection resumes
Related Articles
- Avoiding Life-Critical or Unsafe Autonomous Actions — Never take autonomous actions in safety-critical domains without proper human oversight and approval.
- Confirming Important Actions with the User — Understand when and how to ask for user confirmation before executing critical or irreversible actions.
- Obtaining Explicit User Consent Before Acting — Always ask for permission before performing actions that affect user data, accounts, or external services.
- Recognizing When Escalation Is Required — Identify complex or high-risk situations early and route them to human experts before problems escalate.