Threat Analysis Reasoning Pattern Transfer Prompt

Use this prompt when you need a security engineer or architect to produce a consistent, structured threat assessment for a described system, component, or architecture. The core job-to-be-done is transforming a natural-language system description into a repeatable threat model that identifies attack vectors, estimates business impact, and proposes concrete mitigations. This prompt is ideal for design reviews, security backlog grooming, and internal security documentation where the primary goal is to teach a reasoning pattern through worked examples rather than exhaustive instruction sets. The ideal user is a security practitioner or platform engineer who can provide a clear system boundary, a data flow summary, and a trust model, and who will review the output for accuracy before it enters any decision pipeline.

The prompt requires a specific set of inputs to function reliably. You must provide a [SYSTEM_DESCRIPTION] that includes components, data flows, trust boundaries, and external dependencies. You must also supply a curated set of [WORKED_EXAMPLES] that demonstrate the exact threat-to-mitigation reasoning pattern you want the model to replicate. Each example should show a system snippet, a structured threat analysis, and the logical connection between them. Without high-quality, domain-relevant examples, the model will default to generic threat lists that miss system-specific risks. The prompt is designed for offline or asynchronous analysis, not for real-time incident response, automated blocking decisions, or any workflow where a false negative could cause immediate harm without human review. In those high-stakes scenarios, the model's output must be treated as a suggestion that requires human approval before action.

Do not use this prompt when the system description is too vague to establish a clear trust boundary, when you lack the expertise to validate the output, or when the analysis must meet a formal compliance standard such as PCI DSS or SOC 2 without further human attestation. The prompt is a reasoning accelerator, not a replacement for a qualified security reviewer. The most common failure modes—overestimation of low-probability threats, underestimation of insider risks, and complete blindness to entire threat categories like supply chain or physical attacks—are mitigated by the example set, but they are not eliminated. Before putting this prompt into a production harness, you must pair it with an evaluation rubric that checks for missing STRIDE categories, impact inflation, and mitigation vagueness. The next step after reading this section is to prepare your system description and select at least three worked examples that represent the threat diversity you expect in production.

This prompt template encodes a reasoning pattern for structured threat analysis. Instead of describing how to think about threats, it demonstrates the pattern through a worked example, then asks the model to apply the same reasoning structure to a new target. Replace each square-bracket placeholder with your specific context before sending to the model. The template is designed for security teams who need consistent threat descriptions covering attack vectors, impact, and mitigations, with explicit checks against overestimation, underestimation, and missing threat categories.

textCopy
SYSTEM: You are a security analyst conducting structured threat assessments. Follow the reasoning pattern demonstrated in the example. Do not skip steps. For each threat you identify, you must provide: (1) the threat description, (2) the attack vector, (3) the potential impact, (4) suggested mitigations, and (5) a confidence level. After listing all threats, perform a self-check for overestimation, underestimation, and missing threat categories. If the target system description is insufficient to assess a category, state that explicitly rather than guessing.

EXAMPLE INPUT:
[EXAMPLE_SYSTEM_DESCRIPTION]

EXAMPLE OUTPUT:
[EXAMPLE_THREAT_ASSESSMENT]

TARGET INPUT:
[TARGET_SYSTEM_DESCRIPTION]

OUTPUT SCHEMA:
{
  "threats": [
    {
      "id": "string",
      "description": "string",
      "attack_vector": "string",
      "impact": "string",
      "mitigations": ["string"],
      "confidence": "low|medium|high"
    }
  ],
  "self_check": {
    "overestimation_risks": ["string"],
    "underestimation_risks": ["string"],
    "missing_categories": ["string"],
    "insufficient_information": ["string"]
  }
}

CONSTRAINTS:
- Do not invent threats for which there is no evidence in the target description.
- If the target description lacks detail for a standard threat category, note it under insufficient_information.
- Confidence must reflect the specificity of the target description, not general possibility.
- Limit the assessment to [MAX_THREATS] threats, prioritizing by likelihood and impact.
- [ADDITIONAL_CONSTRAINTS]

To adapt this template, replace [EXAMPLE_SYSTEM_DESCRIPTION] with a concise description of a system similar to what you'll assess in production, and [EXAMPLE_THREAT_ASSESSMENT] with a complete, correct threat assessment following the output schema exactly. The example is the teaching mechanism—invest effort here. Replace [TARGET_SYSTEM_DESCRIPTION] with the actual system you want assessed. Set [MAX_THREATS] to a reasonable bound for your use case. Add any domain-specific threat categories or compliance requirements under [ADDITIONAL_CONSTRAINTS]. Before deploying, validate that the example output matches the schema exactly and that the reasoning pattern transfers correctly by testing against at least three known target descriptions with expected threat profiles. For high-risk security assessments, always route outputs through human review before actioning mitigations.

This prompt is designed to be integrated into a security operations or threat modeling pipeline, not used as a standalone chat interface. The core implementation pattern involves a pre-processing stage to assemble the system context, a model invocation stage with strict output validation, and a post-processing stage that logs the structured threat assessment and routes it for human review. Because the output directly informs security decisions, the harness must treat the model's response as a draft analysis that requires expert validation before it becomes an actionable finding.

The application layer should construct the [SYSTEM_CONTEXT] variable by pulling data from asset inventories, architecture diagrams, or previous threat models. The [WORKED_EXAMPLE] placeholder should be populated from a curated library of high-quality, peer-reviewed threat analyses stored in a database, ensuring the example format exactly matches the desired output schema. After the model responds, the harness must validate the output against a strict JSON schema that enforces the presence of required fields (attack_vector, impact, mitigations, risk_level). A failed validation should trigger a single retry with the validation error message injected into the [CONSTRAINTS] field. If the retry also fails, the task must be escalated to a human analyst queue with the raw output attached for manual repair.

For production deployment, use a model with strong reasoning capabilities and a large context window, such as claude-sonnet-4-20250514 or gpt-4o, to handle the detailed worked example and system context. Implement structured logging that captures the prompt version, the specific example used, the raw model output, and the final validated threat object. This trace is critical for regression testing when the prompt or example library is updated. To guard against the common failure modes of overestimation and underestimation, implement a post-hoc evaluator prompt that scores the output on a severity_alignment rubric, comparing the assigned risk level against the described impact. Any output with a low alignment score should be flagged for mandatory human review before it enters the case management system.