Human-in-the-Loop Approval Policy System Prompt

This prompt is a behavioral contract for product teams building AI agents or assistants that can take consequential actions on behalf of users. It is designed for systems where the model can send emails, modify records, trigger payments, publish content, delete data, or execute code. The core job-to-be-done is to establish a reliable, predictable approval taxonomy that forces the model to pause and request human sign-off before executing any operation classified as high-risk. The ideal user is an engineering lead or AI architect who needs to prevent autonomous execution of dangerous actions without building a brittle, hard-coded state machine outside the model. The required context includes a defined list of available tools, a risk classification for each tool or action category, and a communication channel for the model to surface approval requests to a human reviewer.

You should not use this prompt for read-only assistants, low-risk classification tasks, or workflows where every action is already safe to automate. If your agent only retrieves information, summarizes text, or answers questions without mutating external state, this policy adds unnecessary latency and friction. It is also inappropriate for fully autonomous agents operating in sandboxed environments where actions are trivially reversible. The prompt belongs in the system message layer so it applies across all user and tool interactions, and it should be paired with application-level enforcement: even if the model fails to request approval, your execution harness must independently block high-risk tool calls until a human approves them. Never rely on the model's adherence to this policy as your sole safety mechanism.

Before deploying, test the prompt against a suite of adversarial scenarios where the user attempts to bypass the approval gate through social engineering, indirect requests, or by exploiting ambiguity in the risk taxonomy. Common failure modes include the model approving its own request after a timeout, classifying a high-risk action as low-risk due to user framing, or failing to surface enough context for the human reviewer to make an informed decision. Your next step is to copy the prompt template, map it to your specific tool set and risk levels, and run it through a red-team exercise before integrating it into your application harness.

The following system prompt defines a behavioral contract for an AI system that must gate high-risk actions behind human approval. It establishes a clear taxonomy of actions, specifies how the model should request approval, and defines what happens when a human reviewer does not respond within a configured timeout window. This template is designed to be dropped into a production agent or copilot where the model has access to tools that can mutate external state—such as sending emails, updating databases, or executing financial transactions—and where an incorrect autonomous action carries real business or user harm.

textCopy
You are an AI assistant operating within a product where certain actions require explicit human approval before execution. Your behavior is governed by the following policy.

## Action Taxonomy
Classify every tool call or action you intend to take into one of these categories:

- [READ_ONLY_ACTIONS]: Actions that retrieve or display information without modifying any external state. Examples: [LIST_READ_ONLY_EXAMPLES].
- [LOW_RISK_ACTIONS]: Actions that modify state but carry minimal risk of harm. Examples: [LIST_LOW_RISK_EXAMPLES].
- [HIGH_RISK_ACTIONS]: Actions that modify state and could cause significant harm if incorrect. Examples: [LIST_HIGH_RISK_EXAMPLES].

## Approval Rules
- [READ_ONLY_ACTIONS]: Execute immediately. Do not request approval.
- [LOW_RISK_ACTIONS]: Execute immediately but include a brief note in your response describing what you did.
- [HIGH_RISK_ACTIONS]: Do NOT execute. Instead, pause and request human approval using the format below.

## Approval Request Format
When you need approval for a [HIGH_RISK_ACTIONS] action, respond with exactly this structure:

APPROVAL_REQUIRED: Action: [NAME_OF_ACTION] Details: [PLAIN_LANGUAGE_DESCRIPTION_OF_WHAT_YOU_WILL_DO] Parameters: [KEY_PARAMETERS_AND_VALUES] Impact: [EXPECTED_OUTCOME_AND_POTENTIAL_RISKS] Timeout: [TIMEOUT_DURATION_IN_MINUTES] minutes

codeCopy

After issuing an approval request, do NOT proceed with the action. Wait for the human reviewer to respond with `APPROVED` or `DENIED`.

## Timeout Policy
If you do not receive a response within [TIMEOUT_DURATION_IN_MINUTES] minutes:
- Do NOT execute the action.
- Inform the user that the approval request has timed out.
- Offer to resubmit the approval request if the user still wants to proceed.

## Constraints
- Never execute a [HIGH_RISK_ACTIONS] action without explicit `APPROVED` confirmation.
- Never attempt to bypass the approval flow by reclassifying a [HIGH_RISK_ACTIONS] action as [LOW_RISK_ACTIONS].
- If you are unsure which category an action belongs to, treat it as [HIGH_RISK_ACTIONS] and request approval.
- Do not fabricate approval responses. Only the human reviewer can provide `APPROVED` or `DENIED`.

To adapt this template, replace every square-bracket placeholder with concrete values that match your product's action surface. The [READ_ONLY_ACTIONS], [LOW_RISK_ACTIONS], and [HIGH_RISK_ACTIONS] placeholders should map to your actual tool definitions and API endpoints. Be specific in your examples: instead of "send an email," write "call the send_transactional_email tool with a recipient outside the current domain." The timeout value should reflect your operational SLA for human reviewers—30 minutes is common for async review queues, while 2 minutes might be appropriate for synchronous copilot experiences. After adapting the template, run it through your eval suite with both compliant and adversarial test cases to verify that the model correctly gates high-risk actions and resists reclassification attacks.

This system prompt is one component of a larger human-in-the-loop architecture. The prompt instructs the model on when and how to request approval, but the application layer must handle the actual approval workflow. The prompt alone cannot pause execution, send notifications, or enforce timeouts—those are application responsibilities. The prompt's job is to produce a structured approval request that the application can parse and route. If the application simply passes the model's output to the user without acting on approval requests, the entire safety boundary collapses.

The implementation harness should parse every model response for an approval request signal before any action is taken. A reliable pattern is to require the model to output a structured JSON block with an approval_required boolean and an approval_request object containing action, rationale, risk_level, and idempotency_key fields. The application layer validates this structure, checks the idempotency key against a deduplication store, and routes the request to the appropriate human review queue. While waiting for approval, the system must maintain conversation state—typically by storing the pending request and presenting the user with a waiting message. If the approval times out based on a configured SLA, the application should execute the timeout behavior defined in the prompt (e.g., deny the action, escalate, or re-request).

Model choice matters here. Smaller or faster models may ignore the approval policy under pressure or produce malformed approval requests. Test your chosen model against adversarial scenarios where the user tries to bypass approval by rephrasing requests, splitting dangerous actions across turns, or exploiting urgency. Log every approval request, decision, and timeout with the full prompt context, model response, and human reviewer identity for auditability. Before deploying, run eval suites that inject high-risk actions and verify the application correctly gates them. The most common production failure is not a bad prompt—it's an application that silently executes actions the model flagged for review because the harness didn't parse the approval signal.