Risk Score Calculation Prompt for Autonomous Actions

This prompt is designed for platform engineers and AI architects building autonomous agent workflows where the system must decide whether to execute a tool call, continue a multi-step plan, or escalate to a human operator. The core job-to-be-done is to produce a structured, defensible risk score with a factor-level breakdown before any high-stakes action is taken. The ideal user is an engineering lead who needs to embed a consistent risk-evaluation layer directly into the agent's decision loop, not as a post-hoc audit but as a gating mechanism that runs inline before tool execution. You should use this prompt when the cost of an incorrect autonomous action—such as modifying a production database, sending a customer-facing communication, or executing a financial transaction—is high enough that a numeric risk score and a clear escalation recommendation are required for every action.

This prompt is not a general-purpose safety filter or a content moderation tool. It is specifically scoped to pre-action risk assessment for autonomous tool use. Do not use it for classifying the risk of user inputs in isolation, for scoring the toxicity of generated text, or for evaluating the overall safety of a model. The prompt requires a well-defined context: you must supply the proposed action, the tool that would be called, the relevant conversation or plan history, and any domain-specific risk factors that your application already tracks. Without this context, the model cannot produce a meaningful factor breakdown. The output is a structured JSON object containing a composite risk score, a list of weighted risk factors, and a binary escalation recommendation. This structure is designed to be consumed by an upstream orchestrator that enforces the decision—either blocking the action, requesting human approval, or allowing it to proceed.

Before adopting this prompt, confirm that your application has a clear definition of what constitutes a high-risk action in your domain. The prompt includes placeholder calibration tests against known risk scenarios, but these tests are only as good as the risk taxonomy you provide. If your team has not yet defined risk categories, severity levels, or approval thresholds, start there before integrating this prompt. Once integrated, every autonomous action should pass through this scoring layer, and the resulting scores should be logged alongside the action for auditability. The next step after reading this section is to review the prompt template, adapt the risk factors to your domain, and run the calibration tests to ensure the model's scoring aligns with your internal risk tolerance.

This prompt template is designed to be copied directly into your prompt management system or codebase. It instructs the model to act as a risk assessment engine that evaluates a proposed autonomous action, calculates a composite risk score, breaks down contributing factors, and recommends an escalation path. The template uses square-bracket placeholders that you must replace with your specific action context, tool definitions, risk policies, and output schema before use. Every placeholder is a required injection point—leaving one unresolved will cause the model to hallucinate policy or misjudge risk.

textCopy
You are a risk assessment engine for an autonomous agent platform. Your job is to evaluate a proposed action before execution and produce a structured risk score with factor breakdowns and an escalation recommendation.

## ACTION TO EVALUATE
[ACTION_DESCRIPTION]

## TOOL TO BE CALLED
Tool Name: [TOOL_NAME]
Tool Parameters: [TOOL_PARAMETERS]

## CURRENT CONTEXT
User Identity: [USER_IDENTITY]
Session History Summary: [SESSION_SUMMARY]
Relevant Data Accessed: [DATA_ACCESSED]

## RISK POLICY
[RISK_POLICY]

## OUTPUT SCHEMA
You must respond with a valid JSON object conforming to this schema:
{
  "risk_score": <integer 0-100>,
  "risk_level": "<low|medium|high|critical>",
  "factor_breakdown": [
    {
      "factor": "<factor name>",
      "score": <integer 0-100>,
      "rationale": "<evidence-based explanation>"
    }
  ],
  "escalation_recommendation": "<proceed|confirm|escalate|block>",
  "escalation_reason": "<concise explanation if escalation is recommended, otherwise null>",
  "uncertainty_flags": ["<list of factors where confidence is low>"]
}

## CONSTRAINTS
- Score each factor independently before calculating the composite risk_score.
- The composite risk_score is the maximum of all factor scores, not an average.
- If any factor score exceeds [CRITICAL_THRESHOLD], escalation_recommendation must be "block".
- If any factor score exceeds [HIGH_THRESHOLD], escalation_recommendation must be at least "escalate".
- If you cannot determine a factor with high confidence, flag it in uncertainty_flags and assume worst-case for scoring.
- Do not proceed if the action involves [BANNED_ACTION_CATEGORIES].
- Base all assessments on the provided context and policy only. Do not infer additional risk factors.

## CALIBRATION EXAMPLES
[FEW_SHOT_EXAMPLES]

Now evaluate the action and return only the JSON object.

To adapt this template, start by defining your [RISK_POLICY] as a concrete set of rules—vague policies produce inconsistent scores. Replace [FEW_SHOT_EXAMPLES] with at least three calibrated examples showing low, medium, and critical risk scenarios with expected scores and escalation decisions. This calibration is essential because without it, the model will apply its own subjective risk tolerance, which drifts across model versions. Set [CRITICAL_THRESHOLD] and [HIGH_THRESHOLD] to explicit integers based on your organization's risk appetite, and define [BANNED_ACTION_CATEGORIES] as a closed list of action types that must never proceed autonomously. Before deploying, run this prompt against your eval harness with known-risk scenarios and verify that the composite score calculation (max of factors, not average) is applied correctly—this is the most common implementation error we see in production.

The risk score prompt is not a standalone artifact. It must be wired into an agent execution loop so that every tool call is preceded by a risk assessment. The typical integration point is immediately after the agent selects a tool and populates its arguments, but before the tool is invoked. At that moment, the application assembles the prompt template, substituting the proposed tool name, arguments, current task context, and any relevant policy thresholds into the [TOOL_CALL], [TASK_CONTEXT], and [RISK_THRESHOLDS] placeholders. The model returns a structured JSON risk assessment, and the application inspects the escalation field to decide whether to proceed, request confirmation, or halt execution.

Validation is critical because a malformed risk score can silently permit a high-risk action. The application must validate the model's output against a strict schema before acting on it. At minimum, confirm that overall_score is an integer between 0 and 100, that each factor in factor_breakdown includes a non-null score and rationale, and that escalation is one of the allowed enum values: proceed, confirm, or halt. If validation fails, retry the prompt once with the validation error appended to the [CONSTRAINTS] block. If the retry also fails, default to halt and log the failure for review. For high-stakes domains such as finance or healthcare, insert a human approval step whenever escalation is confirm or halt, routing the full risk assessment and proposed action to a review queue before any tool execution.

Model choice matters. This prompt requires strong instruction-following and structured output reliability. Prefer models with native JSON mode or function-calling support, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid models known to drift on enum constraints or numeric scoring tasks without calibration. Log every risk assessment alongside the eventual tool outcome so you can measure calibration over time: how often did proceed actions succeed without incident, and how often did halt actions prevent real issues? Use these logs to tune the [RISK_THRESHOLDS] and to identify factors in the breakdown that are noisy or uninformative. Do not treat the risk score as a static policy; treat it as a signal that must be monitored, evaluated, and recalibrated as your agent's operating environment evolves.