Risk Boundary Elicitation Prompt Template

This prompt is for agent operators and platform engineers who need to define explicit risk boundaries before handing a goal to an autonomous or semi-autonomous agent. The job-to-be-done is converting an ambiguous operational risk appetite into a machine-readable specification that constrains data exposure, action authority, cost limits, and failure tolerance. The ideal user is a technical decision maker or engineering lead who understands the system's capabilities but needs a structured way to prevent over-execution, unauthorized tool calls, or runaway spending. Required context includes the agent's available tools, the user's stated goal, the deployment environment (e.g., production vs. staging), and any existing organizational policies on data handling or spend limits.

Use this prompt when you are building a planning pre-processor, an agent guardrail module, or a human-in-the-loop approval workflow. It is particularly valuable before an agent begins multi-step execution where tool calls have side effects—such as writing to databases, sending emails, modifying infrastructure, or accessing customer data. The prompt is designed to surface boundary gaps that a human operator might not have considered, such as implicit assumptions about data sensitivity or unstated constraints on retry behavior. Do not use this prompt for simple single-turn classification or retrieval tasks where the risk surface is minimal and the overhead of boundary elicitation outweighs the benefit. It is also inappropriate for fully deterministic automation pipelines where every action is pre-approved and there is no model-driven decision-making.

After running this prompt, you should have a structured risk boundary specification that can be fed directly into an agent's system prompt or policy engine. The output includes explicit thresholds for data exposure (e.g., PII, secrets), action authority (e.g., read-only vs. write), cost limits (e.g., max API calls, token budget), and failure tolerance (e.g., retry count, degradation path). The next step is to validate this specification against your actual tool definitions and deployment constraints, then wire it into your agent's execution loop as a pre-condition check before each step. Avoid treating the output as static—risk boundaries should be re-evaluated when tools change, goals shift, or the agent operates in a new environment.

This prompt template is designed to be inserted into an agent's planning pre-processor. Its job is to force explicit reasoning about risk before any tool is called or any irreversible action is taken. The template uses square-bracket placeholders that your application must populate with the user's clarified goal, available tools, operational context, and any known constraints. The output is a structured risk boundary specification that your agent runtime can enforce programmatically.

textCopy
You are a risk analysis pre-processor for an autonomous agent system. Your task is to produce a Risk Boundary Specification before any execution begins.

## Input

**Goal:** [GOAL]
**Available Tools:** [TOOLS]
**Operational Context:** [CONTEXT]
**Pre-existing Constraints:** [CONSTRAINTS]
**Risk Tolerance Level:** [RISK_LEVEL]

## Task

Analyze the goal, tools, and context to define explicit risk boundaries. For each risk category below, specify the maximum acceptable boundary. If a boundary cannot be determined from the provided information, flag it as a gap that requires human clarification before execution.

### Risk Categories to Address

1. **Data Exposure:** What data can be read, transmitted, or stored? Specify allowed data classifications, prohibited data types, and any redaction or masking requirements.
2. **Action Authority:** What actions can the agent take autonomously? Distinguish between read-only actions, actions requiring confirmation, and prohibited actions. Specify per-tool authority levels.
3. **Cost Limits:** What is the maximum acceptable cost? Specify per-step cost caps, total run cost cap, and behavior when approaching the limit.
4. **Failure Tolerance:** What failures are acceptable? Specify retry policies, maximum failure count, and which failures trigger immediate escalation.
5. **Latency and Time Boundaries:** What are the time constraints? Specify per-step timeout, total run deadline, and behavior on timeout.
6. **Side Effect Boundaries:** What external state changes are permitted? Specify which systems, files, or records can be modified and under what conditions.

## Output Format

Return a JSON object with the following structure:

{
  "risk_boundary_specification": {
    "data_exposure": {
      "allowed_classifications": ["string"],
      "prohibited_data_types": ["string"],
      "redaction_requirements": "string",
      "gaps_requiring_clarification": ["string"]
    },
    "action_authority": {
      "autonomous_actions": ["string"],
      "confirmation_required_actions": ["string"],
      "prohibited_actions": ["string"],
      "per_tool_authority": {
        "[TOOL_NAME]": "autonomous | confirmation_required | prohibited"
      },
      "gaps_requiring_clarification": ["string"]
    },
    "cost_limits": {
      "per_step_cap": "string",
      "total_run_cap": "string",
      "approach_behavior": "string",
      "gaps_requiring_clarification": ["string"]
    },
    "failure_tolerance": {
      "max_retries_per_step": "integer",
      "max_total_failures": "integer",
      "escalation_triggers": ["string"],
      "gaps_requiring_clarification": ["string"]
    },
    "latency_boundaries": {
      "per_step_timeout_seconds": "integer",
      "total_run_deadline_seconds": "integer",
      "timeout_behavior": "string",
      "gaps_requiring_clarification": ["string"]
    },
    "side_effect_boundaries": {
      "mutable_systems": ["string"],
      "modification_conditions": "string",
      "prohibited_modifications": ["string"],
      "gaps_requiring_clarification": ["string"]
    }
  },
  "overall_risk_assessment": {
    "acceptable_risk_level": "low | medium | high | critical",
    "critical_gaps": ["string"],
    "recommended_human_review": "boolean",
    "execution_ready": "boolean"
  }
}

## Instructions

- If any risk category cannot be adequately bounded with the provided information, populate the `gaps_requiring_clarification` array with specific, actionable questions.
- Set `execution_ready` to `false` if any critical gaps exist.
- Set `recommended_human_review` to `true` if the risk level is `high` or `critical`, or if any gap could lead to data exposure, cost overrun, or unauthorized action.
- Do not assume defaults for safety-critical boundaries. Flag them as gaps instead.

To adapt this template, replace each bracketed placeholder with data from your application context. The [GOAL] should be the clarified, de-ambiguified goal from an upstream refinement step. The [TOOLS] placeholder should contain a structured list of available tools with their descriptions and capabilities. The [CONTEXT] should include relevant session history, user role, and environmental details. The [RISK_LEVEL] can be set to a default like medium or derived from a classification step. After the model returns the JSON specification, validate it against the schema before passing it to your agent runtime. Any gap flagged as requiring clarification must block autonomous execution and trigger a human-in-the-loop prompt. Do not proceed with execution if execution_ready is false.

The Risk Boundary Elicitation prompt is not a one-shot generation tool; it is a pre-execution gate. Wire it into your agent's planning pipeline immediately after goal clarification and before any tool-use authorization or subtask decomposition. The prompt expects a structured [GOAL_STATEMENT] and an optional [CONTEXT] block containing available tools, known constraints, and the operational domain. The output is a risk boundary specification document, not executable code. Your harness must parse this specification and convert it into enforceable runtime policies: action allowlists, cost caps, data redaction rules, and failure tolerance thresholds.

Implement a validation layer that checks the prompt's output for completeness before the agent proceeds. At minimum, confirm that the specification includes sections for data exposure, action authority, cost limits, and failure tolerance. If any section is missing or contains unresolved placeholders, reject the output and re-prompt with a targeted gap-fill request. For high-risk domains, route the completed specification to a human approval queue. The approval UI should display the original goal, the elicited risk boundaries, and a diff view if the user later modifies the boundaries. Log the approved specification as an immutable artifact tied to the agent's execution trace for auditability.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet). Set temperature to 0 or near-zero to minimize variance in boundary definitions. Implement a retry strategy with a maximum of 2 attempts: if the output fails validation, append the validation errors to the next request as [PREVIOUS_FAILURES]. If the second attempt also fails, escalate to a human operator and halt the agent pipeline. Do not proceed with autonomous execution on a failed risk boundary elicitation. The cost of a blocked pipeline is always lower than the cost of an unboundaried agent action.