Destructive Action Warning Generation Prompt

This prompt is for safety engineers and platform architects building pre-execution guardrails for high-risk tool calls. Use it when a model or agent has selected a destructive tool—such as delete, overwrite, drop, or deprovision—and you need a structured, severity-graded warning before the operation proceeds. The prompt generates warning metadata for UI rendering, audit logging, and human-in-the-loop (HITL) approval flows. It does not decide whether to proceed; it produces the warning that enables a downstream decision. The ideal user is someone integrating an AI agent into a production system where destructive actions must be reviewed, not someone building a general-purpose chatbot.

This prompt assumes the tool call has already been classified as destructive by an upstream intent classifier or side-effect detector. It takes that classification as input and enriches it with irreversibility details, affected resources, recovery options, and a severity grade. In a typical implementation, you would wire this prompt into a pre-execution hook: the agent selects a tool, the guardrail system intercepts the call, classifies it as destructive, and then invokes this prompt to generate the warning payload. The resulting JSON is then rendered in a confirmation UI or written to an audit log before any execution occurs.

Do not use this prompt for read-only operations, low-risk writes, or as a standalone authorization layer. It is not a replacement for an IAM policy engine or a permission check. It is also not designed for user-facing conversational confirmation—use the Write Operation Confirmation Prompt for that. Avoid using this prompt when the destructive classification is uncertain; if the upstream classifier has low confidence, route to a human reviewer with the raw context instead of generating a potentially misleading warning. Finally, never use this prompt to generate warnings for operations that have already executed; it is a pre-execution tool only.

This prompt is designed to sit in a pre-execution guardrail layer. Before a destructive tool call (such as delete, overwrite, archive, or deactivate) is allowed to execute, this prompt generates a structured warning payload. The warning is intended for both machine consumption (to block or flag the call) and human consumption (to render a confirmation UI). The prompt requires the proposed tool call details, the affected resource inventory, and a risk-level classification to produce a calibrated output. It does not make the authorization decision itself; it produces the evidence that an authorization system or human reviewer uses to decide.

textCopy
You are a safety guardrail for a production system. Your task is to generate a structured warning for a proposed destructive tool call. You do not decide whether to proceed. You produce the warning metadata that downstream systems or human reviewers will use.

## INPUT
- Proposed Tool Call: [TOOL_CALL_JSON]
- Affected Resources: [AFFECTED_RESOURCES]
- Risk Level: [RISK_LEVEL] (one of: LOW, MEDIUM, HIGH, CRITICAL)
- User Intent Summary: [USER_INTENT]
- Context: [CONTEXT]

## OUTPUT SCHEMA
Return a single JSON object with these fields:
- `severity`: string matching the input [RISK_LEVEL]
- `irreversibility`: string explaining whether the action can be undone, how, and within what time window. If irreversible, state that explicitly.
- `blast_radius`: object with:
  - `direct_resources`: list of resources directly modified or deleted
  - `dependent_resources`: list of resources that depend on the affected resources and may break
  - `downstream_effects`: list of systems, users, or processes impacted
- `recovery_options`: list of strings describing recovery paths. If no recovery is possible, state "No recovery possible. This action is permanent."
- `warning_summary`: string, one sentence suitable for a UI warning banner
- `confirmation_required`: boolean, always true for HIGH or CRITICAL severity
- `recommended_reviewers`: list of role strings that should approve this action

## CONSTRAINTS
- Do not downplay irreversible data deletion. If data will be permanently destroyed, say so in the first sentence of `irreversibility`.
- If the tool call includes a `force` or `skip_confirmation` flag set to true, increase severity by one level (LOW->MEDIUM, MEDIUM->HIGH, HIGH->CRITICAL).
- If the blast radius includes resources tagged as `production`, `customer_data`, or `regulated`, severity must be at least HIGH.
- Do not invent recovery options that do not exist. If no backup, snapshot, or undo mechanism is present, state that clearly.
- Use plain language suitable for a non-engineering reviewer in `warning_summary`.

## EXAMPLES

Input:
Risk Level: HIGH
Proposed Tool Call: {"tool": "delete_customer_account", "args": {"customer_id": "cust_1234", "force": false}}
Affected Resources: ["customer_record:cust_1234", "billing_history:cust_1234", "support_tickets:cust_1234"]

Output:
{
  "severity": "HIGH",
  "irreversibility": "This action permanently deletes the customer account and all associated data. Recovery is only possible from a full database backup taken within the last 24 hours. Partial recovery of billing history may not be possible.",
  "blast_radius": {
    "direct_resources": ["customer_record:cust_1234", "billing_history:cust_1234", "support_tickets:cust_1234"],
    "dependent_resources": ["active_subscriptions tied to cust_1234", "analytics dashboards referencing this customer"],
    "downstream_effects": ["Customer loses access to all services", "Billing team loses payment history", "Support team loses ticket context"]
  },
  "recovery_options": ["Restore from nightly backup (within 24-hour window)", "Recreate account manually (billing history will be lost)"],
  "warning_summary": "This action permanently deletes the customer account cust_1234 and all associated billing and support data.",
  "confirmation_required": true,
  "recommended_reviewers": ["account_manager", "compliance_officer"]
}

Now generate the warning for the provided input.

To adapt this prompt, replace the square-bracket placeholders with live data from your tool execution pipeline. [TOOL_CALL_JSON] should be the serialized tool call object your model or agent produced. [AFFECTED_RESOURCES] should come from your resource inventory or dependency graph, not from the model's guess. [RISK_LEVEL] should be assigned by a prior classification step, not by this prompt. If you do not have a resource inventory, add a retrieval step before this prompt to look up dependencies. The examples section is critical for calibration; add at least two more examples covering MEDIUM and CRITICAL severity cases with your actual tool names and resource types. Test the prompt against edge cases where the blast radius is empty, where recovery options are null, and where the tool call includes a force flag. Validate the output JSON against the schema before rendering any UI or making an authorization decision.

This prompt is designed to sit directly in the pre-execution path of any tool call classified as destructive. It should not be used in isolation or as a post-hoc audit step. The ideal integration point is inside a tool-call guard service that intercepts function calls after the model has selected a tool and constructed arguments, but before the call is dispatched to the execution layer. The guard service receives the proposed tool call, the user's session context, and the tool's declared side-effect profile, then invokes this prompt to generate a structured warning payload. The warning is returned to the calling application, which must render it to the user and collect explicit confirmation before proceeding.

The harness must enforce a hard block on execution until a signed confirmation token is received. A common implementation pattern uses a state machine with three states: PENDING_WARNING, AWAITING_CONFIRMATION, and EXECUTING. When the guard service generates a warning, the tool call transitions to AWAITING_CONFIRMATION and the warning payload is sent to the frontend. The frontend renders the severity level, affected resources, irreversibility flag, and recovery options from the structured output. The user's confirmation action must include a non-replayable token (e.g., a UUID tied to the specific tool call) that the execution layer validates before proceeding. If the user rejects or the token expires, the tool call is discarded and an audit record is written. This prevents replay attacks where a stale confirmation is reused for a different destructive operation.

Validation and retry logic is critical because the prompt output directly controls a safety gate. Implement a JSON schema validator that checks for the required fields: severity, irreversible, affected_resources, recovery_options, and warning_text. If validation fails, retry the prompt once with the validation error appended to the [CONSTRAINTS] block. If the second attempt also fails, escalate to a human reviewer and block execution. Log every warning generation attempt, including the raw prompt, the model response, validation results, and the final disposition (confirmed, rejected, escalated). These logs form the audit trail for compliance reviews. For model choice, prefer a fast, deterministic model with strong instruction-following (e.g., Claude 3.5 Sonnet or GPT-4o) rather than a smaller model that might downplay severity. The cost of a wrong warning is a destructive action without adequate user understanding; the latency cost of a larger model is acceptable in this blocking path.

Common integration mistakes to avoid: (1) generating the warning but not blocking execution, which turns a safety guard into a notification; (2) allowing the model to decide whether to show the warning, which creates a single point of failure where the model can bypass its own guard; (3) using the same prompt for read-only operations, which trains users to ignore warnings; and (4) failing to include the specific resource identifiers and blast radius in the warning, which produces generic messages that users dismiss. Always include the actual resource names, counts, and downstream dependencies from the tool call arguments in the [CONTEXT] block. If the tool call targets DELETE /projects/1234, the warning must say 'project 1234' not 'a project'. Finally, pair this prompt with the Side-Effect Detection Prompt to ensure the tool's declared side-effect profile matches its actual behavior before trusting the classification.