Risk Score-Based Escalation Prompt for Tools

This prompt is for security and risk engineers who need to replace binary approve/deny logic with a quantitative, defensible escalation gate directly inside an agent's tool-use loop. The job-to-be-done is not just to stop a bad action, but to produce a consistent, scored decision record that can be calibrated against historical incidents, audited by compliance teams, and monitored for false-positive drift over time. The ideal user is someone who already has a policy engine or identity-aware proxy in place and needs a scoring layer that sits between tool selection and execution, translating context into a structured risk assessment that downstream systems can enforce. You should use this prompt when the cost of a wrong autonomous decision is measurable, when you need to tune sensitivity thresholds without redeploying application code, and when you must prove to an auditor that every escalation decision followed a consistent, documented rubric.

To use this prompt effectively, you must provide the model with a weighted risk factor schema, a defined threshold tier map, and the proposed tool action context. The prompt instructs the model to score the action across each factor, compute a composite score, and map it to a tier that dictates the escalation action—such as proceed, escalate_to_human, or block. A concrete implementation would wire this prompt into a pre-execution hook in your agent framework: the agent proposes a tool call, the hook assembles the context, invokes the model with this prompt, parses the structured decision, and either allows execution, queues a human review task, or logs a block event. You must validate the output against the expected schema before acting on it, and you should log every decision with the raw score, threshold applied, and model version for later drift analysis.

Do not use this prompt as a replacement for a policy engine, an identity-aware proxy, or a hard-coded permission system. It is not designed to be the sole enforcement point for access control, nor should it be the only gate for actions that carry irreversible safety or financial consequences. The prompt works best when the risk factors are well-understood and can be described in natural language, when the thresholds have been calibrated against real incident data, and when a human review queue exists for escalated decisions. If your risk taxonomy is still evolving or your thresholds are arbitrary, start by using this prompt in a shadow mode—scoring and logging decisions without blocking execution—until you have enough data to set meaningful thresholds and measure false-positive rates.

This template is designed to be wired into your agent's pre-execution hook or tool-calling middleware. It receives the proposed tool call, its arguments, and the current execution context, then returns a structured risk assessment. The output includes a numerical score, a breakdown of contributing factors, and a mandatory escalation action (proceed, review, or block) based on configurable thresholds. Adapt the factor weights and tier definitions to match your organization's risk appetite and compliance requirements.

textCopy
You are a risk assessment engine for an AI agent. Your job is to evaluate a proposed tool action and return a structured risk score with an escalation decision. Do not execute the tool. Do not approve or deny based on intuition. Apply the rubric exactly.

## INPUT
- Proposed Action: [ACTION_DESCRIPTION]
- Tool Name: [TOOL_NAME]
- Arguments: [TOOL_ARGUMENTS]
- Affected Resources: [AFFECTED_RESOURCES]
- Execution Context: [EXECUTION_CONTEXT]
- User Identity: [USER_IDENTITY]
- Session History (last 5 actions): [SESSION_HISTORY]

## RISK RUBRIC
Score each factor from 0 (no risk) to 10 (critical risk).

1. **Irreversibility (weight: 0.30):** Can this action be undone easily? (0 = fully reversible, 10 = permanent and unrecoverable)
2. **Blast Radius (weight: 0.25):** How many users, systems, or records are affected? (0 = single record, 10 = entire production environment)
3. **Data Sensitivity (weight: 0.20):** What classification of data is touched? (0 = public, 10 = PII/PHI/PCI or classified)
4. **Financial Impact (weight: 0.15):** What is the potential cost of an error? (0 = $0, 10 = >$10,000 or unbounded)
5. **Compliance Exposure (weight: 0.10):** Does this action touch regulated workflows? (0 = none, 10 = SOX/GDPR/HIPAA violation potential)

## CALCULATION
- Weighted Score = (Irreversibility * 0.30) + (Blast Radius * 0.25) + (Data Sensitivity * 0.20) + (Financial Impact * 0.15) + (Compliance Exposure * 0.10)
- Round to one decimal place.

## ESCALATION TIERS
- **Score 0.0–3.0: PROCEED** — Action is low-risk. Log and execute.
- **Score 3.1–6.5: REVIEW** — Action requires human review before execution. Route to [REVIEW_QUEUE].
- **Score 6.6–10.0: BLOCK** — Action is high-risk. Do not execute. Escalate to [ESCALATION_CONTACT] and log for audit.

## OUTPUT SCHEMA
Return ONLY valid JSON. No markdown, no commentary.
{
  "risk_score": <float>,
  "factor_scores": {
    "irreversibility": <int 0-10>,
    "blast_radius": <int 0-10>,
    "data_sensitivity": <int 0-10>,
    "financial_impact": <int 0-10>,
    "compliance_exposure": <int 0-10>
  },
  "escalation_tier": "PROCEED" | "REVIEW" | "BLOCK",
  "justification": "<One-sentence summary of the primary risk driver.>",
  "recommended_reviewers": ["<role or team>"],
  "audit_reference": "<unique ID for this assessment>"
}

## CONSTRAINTS
- If any single factor scores 9 or 10, escalation_tier must be at least REVIEW, regardless of weighted score.
- If the same action has been executed more than [REPETITION_THRESHOLD] times in this session, add 2.0 to the weighted score before tier assignment.
- If the user identity does not match the expected role for this tool, set escalation_tier to BLOCK.
- Do not hallucinate factor scores. If information is missing to score a factor, default to 5 and note "insufficient data" in the justification.

To adapt this template, start by calibrating the factor weights and tier thresholds against your historical incident data. If you have a log of past tool actions and their outcomes, run a batch of representative samples through the prompt and compare the resulting tiers to what your operators would have chosen. Adjust the thresholds until the false-positive rate (unnecessary reviews) and false-negative rate (missed escalations) are both acceptable. For high-compliance environments, add a mandatory human-review flag for any action touching a specific data classification or regulatory scope, regardless of the computed score. Wire the output into your agent framework so that a REVIEW or BLOCK tier halts execution and enqueues the decision record, not just the action description, for the human reviewer.

This prompt is designed to sit inside a pre-execution gate for high-risk tool calls. When an agent proposes an action—such as a database write, a financial transaction, or a configuration change—the application layer should intercept the proposed tool call, assemble the required context, and invoke this prompt to compute a structured risk score and escalation decision. The prompt is not a standalone chatbot interaction; it is a deterministic scoring function that produces a machine-readable output schema suitable for downstream routing logic. The implementation should treat the prompt's output as a control-plane signal: if the score exceeds a configured threshold, the tool call is blocked and routed to a human approval queue; if it falls below, the call proceeds with an auditable decision record attached.

Integration pattern: Wrap the prompt in a thin service or middleware function that accepts a ToolCallRequest object containing the tool name, arguments, affected resources, estimated blast radius, data sensitivity tags, and any relevant historical incident context. The function should inject these into the prompt's [TOOL_CALL_CONTEXT], [AFFECTED_RESOURCES], [DATA_SENSITIVITY], and [HISTORICAL_INCIDENTS] placeholders. The model should be configured with temperature=0 and a strict JSON output schema to prevent creative scoring. Validate the output against the expected schema before acting on it: check that risk_score is a float between 0 and 1, that escalation_tier matches one of the defined enum values (auto_approve, peer_review, manager_approval, executive_approval, block), and that each weighted factor in factor_breakdown sums correctly. If validation fails, retry once with the validation error injected into the prompt's [CONSTRAINTS] field, then escalate to a human operator if the retry also fails.

Logging and audit trail: Every invocation must produce an immutable audit record. Log the raw prompt input, the model's complete output, the validation result, the routing decision, and the final outcome (approved, escalated, overridden). Store these records in a tamper-evident log or append-only database table. The decision_id generated by the prompt should be used as the correlation key across the approval queue, the tool execution log, and any post-execution review. For regulated environments, ensure the audit record includes the model version, the prompt template hash, and the identity of any human reviewer who approved or overrode the score. This traceability is essential for demonstrating that the escalation logic was applied consistently and that no tool call bypassed the risk gate.

Calibration and false-positive monitoring: The risk scoring rubric is only as good as its calibration against real incidents. Implement a feedback loop that captures false positives (escalations that proved unnecessary) and false negatives (auto-approved actions that caused incidents). Use these events to adjust the [WEIGHT_OVERRIDES] and [THRESHOLD_TIERS] parameters over time. Run periodic backtests against historical incident data to verify that the scoring model would have caught known failures. If the false-positive rate exceeds operational tolerance—typically when more than 20% of escalations are dismissed by reviewers—recalibrate the thresholds or add clarifying context to the prompt's factor definitions. Never silently lower thresholds to reduce review load; document every calibration change as a versioned update to the prompt configuration.

Human-in-the-loop integration: When the prompt returns an escalation decision, the application must place the tool call into a review queue with all context preserved. The reviewer should see the risk score, the factor breakdown, the proposed action, and the affected resources in a structured UI. The reviewer's decision—approve, deny, or modify—must be recorded and fed back into the calibration loop. Implement queue timeouts: if a review is not completed within the SLA defined in [ESCALATION_TIMEOUT], the system should either auto-deny the action or escalate to the next tier, depending on the risk level. Never allow a timeout to silently approve a high-risk action. For multi-step workflows, use the [CORRELATION_ID] to link related approvals and prevent a single reviewer from approving all stages of a sensitive sequence without independent oversight.