Irreversible Action Approval Prompt Template

This prompt is for platform engineers and AI product teams building autonomous agents that can trigger destructive operations such as data deletion, resource teardown, state mutation, or configuration changes that lack a simple undo path. The prompt forces the model to stop, package a structured approval request, and wait for explicit human signoff before any action is taken. Use this when the cost of a wrong autonomous decision is high and when auditability of the approval decision matters. The primary job-to-be-done is inserting a non-bypassable, evidence-rich human checkpoint directly into an agent's tool-execution guard, not as a conversational nicety but as a hard control point.

Deploy this prompt template inside the agent's pre-execution hook for any tool classified as irreversible or high-risk. The ideal user is a platform engineer wiring an agent's tool-calling loop to a review queue, a compliance engineer requiring a structured audit artifact before every destructive action, or a product team building internal operator tooling where the blast radius of a mistake is measured in customer data loss or service downtime. Required context includes the proposed action's full payload, the affected resource identifiers, a rollback feasibility assessment, and the identity of the requesting agent or user. The prompt is designed to consume this context and produce a machine-readable approval card that can be routed to a human reviewer via Slack, a custom dashboard, or an API-driven approval system.

Do not use this prompt for low-risk read operations, idempotent writes with verified rollback, or workflows where a pre-action summary alone is sufficient. If the action can be safely reversed with a single, well-tested command and the cost of reversal is negligible, a lighter confirmation prompt from the 'Pre-Action Summary and Confirmation Prompts' group is a better fit. Avoid applying this blocking pattern to every tool in an agent's arsenal; doing so creates approval fatigue, slows down legitimate work, and trains human reviewers to click 'approve' without reading. Reserve this prompt for the small set of operations where an incorrect execution would trigger an incident, violate a compliance control, or require a time-consuming manual recovery process.

This prompt template is designed to be placed directly into your agent's system instructions or as a guard in your tool-use loop. It defines a strict contract: the agent must not execute any action classified as [IRREVERSIBLE_ACTION_CLASS] without first generating a structured approval request and halting for a valid [APPROVAL_SIGNAL]. The template uses square-bracket placeholders that you must replace with your specific operational context, such as the exact API calls that require approval, the format of the approval token, and the required fields in the confirmation payload.

markdownCopy
# IRREVERSIBLE ACTION APPROVAL PROTOCOL

You are an AI agent operating in a production environment. Your primary directive is safety and correctness. You are prohibited from autonomously executing any action that falls into the category of [IRREVERSIBLE_ACTION_CLASS]. This includes, but is not limited to: [LIST_OF_SPECIFIC_ACTIONS, e.g., data deletion, resource teardown, financial transfer, configuration change].

## APPROVAL GATE
Before executing any [IRREVERSIBLE_ACTION_CLASS], you MUST pause your workflow and output a structured approval request. You MUST NOT proceed until you receive a valid [APPROVAL_SIGNAL] from the user or an authorized system.

## APPROVAL REQUEST SCHEMA
When an irreversible action is the next required step, generate a single JSON object conforming to this exact schema:
{
  "approval_request": {
    "action_id": "[UNIQUE_IDENTIFIER]",
    "action_type": "[DELETE|MUTATE|EXECUTE|...]",
    "description": "[PLAIN_LANGUAGE_DESCRIPTION_OF_ACTION]",
    "target_resources": ["[RESOURCE_ID_1]", "[RESOURCE_ID_2]"],
    "impact_scope": "[DESCRIPTION_OF_BLAST_RADIUS_AND_AFFECTED_SYSTEMS]",
    "rollback_feasibility": "[IMMEDIATE|COMPLEX|IMPOSSIBLE] - [BRIEF_EXPLANATION]",
    "risk_level": "[LOW|MEDIUM|HIGH|CRITICAL]",
    "justification": "[REASON_THIS_ACTION_IS_NECESSARY]"
  },
  "required_approval": "[APPROVAL_SIGNAL_FORMAT, e.g., 'CONFIRM ' + action_id]"
}

## BLOCKING CONDITIONS
You must refuse to generate the approval request and instead output a `BLOCKED` message if any of the following are true:
- The target resource cannot be uniquely identified.
- The impact scope is unknown or cannot be reasonably inferred.
- The action violates a hardcoded policy in [POLICY_DOCUMENT_SECTION].
- The user's request is ambiguous regarding the target or scope.

## POST-APPROVAL BEHAVIOR
After receiving a valid [APPROVAL_SIGNAL], you may execute the action exactly as described in the approved request. After execution, you must immediately output a verification summary, including the new state of the target resource and any relevant audit log references.

To adapt this template, replace every square-bracket placeholder with concrete values from your system. For example, [IRREVERSIBLE_ACTION_CLASS] might become destructive_operations, and [LIST_OF_SPECIFIC_ACTIONS] should be an explicit list like DeleteTable, TerminateInstance, or TransferFunds. The [APPROVAL_SIGNAL] is critical; define a string that is unlikely to be generated accidentally, such as APPROVED: [action_id]. Before deploying, test this prompt against a suite of adversarial user inputs that attempt to bypass the approval gate, such as asking the agent to "summarize the action before doing it" or to "proceed for testing purposes." If the workflow involves regulated data or financial impact, ensure that the approval signal is cryptographically verified or originates from an authenticated user session, not just a text match in the chat.

This prompt is not a standalone chat interaction; it is a control-plane component inside an agent execution loop. The prompt should be invoked immediately before any tool call, API write, or state mutation classified as irreversible. The agent's planning layer must route the action context into this prompt, block execution of the destructive tool, and wait for a structured approval response before proceeding. The prompt's output is a machine-readable approval request payload, not a conversational message. Your application should parse this payload, present it to the designated human reviewer through a review queue or notification channel, and only call the downstream tool after receiving an explicit approved: true signal with the required signoff fields.

Wiring pattern: Wrap the prompt in a function that accepts an action_context object (action type, target resource, proposed parameters, impact scope, rollback feasibility) and returns an ApprovalRequest schema. The application layer should validate the output against a strict schema before surfacing it to a human. If the model returns malformed JSON, missing required fields like impact_summary or rollback_plan, or an approval_required field that is not a boolean, the harness must retry with a repair prompt that includes the validation error. Do not proceed to human review with a broken payload. Retry logic: Use a maximum of 2 repair attempts. If the model still fails, escalate the raw action context and the failure reason to a human operator through a fallback channel—never execute the action silently. Logging: Record the full prompt, the model's raw output, the parsed payload, the validator result, and the final human decision (approve/deny with timestamp and reviewer identity) in an audit log. This log is essential for compliance reviews and post-incident analysis.

Model choice: Use a model with strong instruction-following and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet) for this prompt. Avoid smaller or older models that may omit critical safety fields or hallucinate impact assessments. If your system supports structured output modes (e.g., JSON mode, tool calling with strict schemas), prefer those over free-text generation to reduce parsing failures. Tool integration: This prompt should be called as an internal function, not exposed as a user-facing tool. The agent's tool-execution layer must check for an active approval block before invoking any tool tagged as risk_level: high or reversible: false. Human review interface: The approval request payload should be rendered in a review UI that clearly shows the action description, impact scope, rollback feasibility, and required signoff fields. The UI must require explicit confirmation (e.g., a checkbox and a reason field) before the system proceeds. Do not allow single-click approvals for irreversible actions.

What to avoid: Do not use this prompt as a post-hoc audit log after the action has already executed. The approval must be a synchronous gate. Do not cache or reuse approval decisions across different action contexts—each irreversible action requires a fresh review. Do not allow the model to set approval_required: false for actions that match your organization's predefined high-risk categories; enforce this classification in the application layer before the prompt is called. Finally, ensure that the human reviewer can see the full action context, not just a summary, and that the review interface includes a link to the rollback procedure if one exists.