Prompt Injection Severity Scoring Rubric Prompt

This prompt is designed for incident responders and security leads who need a consistent, repeatable severity score for a confirmed prompt injection event. It is not a detection prompt. It assumes that a prior detection workflow—such as a production trace classifier, a red-team tool, or a manual review—has already identified and isolated a specific injection trace. The job-to-be-done is triage and escalation: taking a validated injection trace and producing a structured severity level, a justification grounded in a defined rubric, and a clear escalation recommendation that can feed into incident management systems and stakeholder notifications.

The ideal user is a security engineer or AI operations lead who has access to the full trace context, including the system prompt, user input, tool calls, retrieved documents, and model output. The prompt requires a structured input payload containing the injection trace, the known system prompt, and any relevant policy documents. It evaluates the event across four axes: data exposure (what data was visible to the attacker), tool misuse (what actions were taken or attempted), user impact (who was affected and how), and policy violation (which internal policies were breached). The output is a severity level (e.g., CRITICAL, HIGH, MEDIUM, LOW, NONE), a structured justification with evidence citations, and an escalation recommendation. Do not use this prompt for real-time blocking decisions; it is a post-detection analysis tool. Do not use it without a confirmed injection—feeding it benign traces will produce misleading severity scores.

Before using this prompt, ensure you have a validated injection trace and a defined severity rubric that maps to your organization's incident response tiers. The prompt template includes placeholders for your rubric criteria, escalation paths, and output schema. Wire the output into your incident management pipeline by parsing the severity level and escalation recommendation into automated ticket creation or alert routing. Always require human review for CRITICAL and HIGH severity events, and log every scoring result for auditability. If your organization lacks a formal injection severity rubric, start by defining one in terms of data sensitivity levels, tool risk classifications, and user impact categories before adapting this prompt.

This prompt template is designed to be injected into your incident response pipeline after a trace has been confirmed as a prompt injection event. It expects a structured trace payload and a pre-defined severity rubric as input. The model's job is not to detect the injection—that step must already be complete—but to apply consistent scoring logic, produce a structured justification, and recommend an escalation path. Replace each square-bracket placeholder with data from your upstream detection and trace extraction systems before sending the prompt to the model.

textCopy
You are a security incident severity assessor. Your task is to score a confirmed prompt injection event against a defined rubric and produce a structured severity assessment.

## INPUT
- Injection Trace: [INJECTION_TRACE]
- Severity Rubric: [SEVERITY_RUBRIC]
- System Prompt (for context): [SYSTEM_PROMPT]
- Affected Tool Definitions (if any): [TOOL_DEFINITIONS]
- Data Sensitivity Classification: [DATA_SENSITIVITY_LEVEL]

## OUTPUT SCHEMA
Return a single JSON object with these fields:
- severity_level: "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | "INFO"
- severity_score: integer between 0 and 100
- data_exposure_impact: "CONFIRMED_EXFILTRATION" | "POTENTIAL_EXPOSURE" | "NO_EXPOSURE" | "INCONCLUSIVE"
- tool_misuse_impact: "UNAUTHORIZED_EXECUTION" | "SCHEMA_PROBE" | "NO_MISUSE" | "INCONCLUSIVE"
- user_impact: "MULTI_TENANT" | "SINGLE_USER" | "NO_IMPACT" | "UNKNOWN"
- policy_violations: array of strings naming violated policies
- justification: string explaining the score with specific evidence from the trace
- escalation_recommendation: "IMMEDIATE_INCIDENT_RESPONSE" | "SECURITY_REVIEW_REQUIRED" | "MONITOR_ONLY" | "NO_ACTION"
- human_review_required: boolean
- confidence: float between 0.0 and 1.0

## CONSTRAINTS
- Only use evidence present in the provided trace. Do not speculate about unseen events.
- If the trace contains insufficient evidence to determine a field, use "INCONCLUSIVE" or "UNKNOWN" rather than guessing.
- When data sensitivity is "HIGH" or "CRITICAL," default human_review_required to true unless the evidence clearly shows no exposure.
- If tool_misuse_impact is "UNAUTHORIZED_EXECUTION," severity_level must be at least "HIGH."
- Justification must cite specific trace spans, tool call IDs, or retrieved document chunks.
- Do not include remediation steps in the justification. Those belong in a separate incident response workflow.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

Adapt this template by replacing the placeholders with data from your production trace pipeline. The [INJECTION_TRACE] should be a structured representation of the full trace—span IDs, tool calls, retrieved documents, user inputs, and model outputs—not raw log lines. The [SEVERITY_RUBRIC] must be your organization's pre-defined scoring criteria, included inline so the model applies it consistently rather than improvising. The [FEW_SHOT_EXAMPLES] placeholder should contain 2–4 scored examples that demonstrate how your team maps trace evidence to severity levels. If your rubric changes, update the examples to prevent drift. The [RISK_LEVEL] field allows you to pass a runtime risk context (e.g., "production-critical-endpoint" or "internal-testing") that can influence the escalation recommendation without hardcoding it into the prompt.

Before deploying this prompt into an automated pipeline, validate that the output JSON conforms to the schema using a strict validator. Reject and retry any response where severity_level does not match the allowed enum or where justification lacks specific trace citations. For CRITICAL or HIGH severity events, always route to a human reviewer regardless of the model's human_review_required boolean—the model's recommendation is advisory, not authoritative. Log every scored assessment alongside the trace ID and the model version for auditability. If you observe scoring inconsistency across similar traces, review your few-shot examples and rubric wording before adjusting the prompt.

This prompt is designed to operate as a post-detection scoring step inside an incident response or trace-review pipeline. It should never be the first stage of a pipeline; it assumes a confirmed injection event has already been identified by an upstream detector. The harness must enforce this dependency: the prompt should only be invoked when a detection system has flagged a trace with a confidence score above a configurable threshold and a human or automated triage step has confirmed the event is not a false positive. Wiring the scorer directly to raw user inputs without a detection gate will produce noisy severity scores on benign traffic and erode trust in the escalation logic.

Input assembly requires three data objects before the prompt is called: the full trace span or session log (the [TRACE_DATA] placeholder), the detection verdict from the upstream classifier (the [DETECTION_VERDICT] placeholder, including the attack vector and confidence), and the organization's severity rubric definitions (the [RUBRIC_DEFINITIONS] placeholder, mapping levels like LOW, MEDIUM, HIGH, CRITICAL to concrete criteria for data exposure, tool misuse, user impact, and policy violation). The harness should validate that all three inputs are non-empty and that the rubric definitions contain at least the four required severity levels before making the model call. If the rubric is missing or incomplete, the harness must abort and log a configuration error rather than allowing the model to invent severity thresholds.

Model choice and output validation are critical because this prompt produces a structured decision that may trigger automated escalation. Use a model with strong instruction-following and JSON output reliability (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set response_format to json_object where the API supports it, and always validate the output against the expected schema before acting on it. The harness must check that severity_level is one of the rubric's defined levels, that justification is non-empty, and that escalation_recommendation is a boolean. If validation fails, retry once with the validation error message appended to the prompt as a correction hint. If the retry also fails, log the failure, set the severity to a safe default (e.g., HIGH with escalation_recommendation: true), and flag the trace for manual review. Never silently accept a malformed severity score.

Logging and audit trail requirements are non-negotiable for security workflows. Every invocation must log: the trace ID, the upstream detection verdict, the complete prompt sent to the model, the raw model response, the validated severity output, any validation errors or retries, and the final escalation decision. These logs serve as the audit evidence for why a particular trace was escalated or dismissed. Store logs in an append-only system with retention aligned to your incident response policy. For regulated environments, ensure the logs do not inadvertently capture user PII from the trace data; apply redaction to the [TRACE_DATA] field before logging if necessary.

Escalation integration should connect the validated severity output to your incident management system (PagerDuty, Jira, Slack webhooks, etc.). The harness should read escalation_recommendation and severity_level together: a CRITICAL severity with escalation_recommendation: true should trigger an immediate page; a HIGH severity should create a high-priority ticket; MEDIUM should queue for review during business hours; LOW can be logged for trend analysis without active alerting. The harness must also respect a human-review override: if the upstream detector flagged the trace as human_review: true, the severity scorer's output should be treated as advisory and routed to a human analyst regardless of the computed severity. This prevents the scorer from accidentally downgrading an event that a human already determined needs attention.