Threat Modeling Architecture Prompt Template

This prompt is for security architects and engineering leads who need to generate a structured threat model from a system design document, architecture diagram description, or data flow narrative. Use it early in the design phase, before implementation, when you have enough detail about components, trust boundaries, data flows, and external dependencies to reason about threats. The prompt produces a STRIDE-categorized threat inventory or an attack-tree analysis with prioritized risks, existing controls, and missing mitigations. It is designed for workflows where a human security reviewer will validate, refine, and sign off on the output before it becomes part of a security review record or compliance artifact.

To use this prompt effectively, you must provide a detailed description of the system's architecture. This includes a list of components (services, data stores, users, external systems), the data flows between them, and explicit trust boundaries. The quality of the output is directly proportional to the specificity of the input. For example, an input stating 'a web app with a database' will yield a generic and less useful threat model. A better input would specify 'a React single-page application authenticating users via OAuth 2.0 with an AWS Cognito User Pool, making API calls through an API Gateway to a set of Lambda functions that read from and write to a DynamoDB table, with all traffic encrypted via TLS 1.3.' This level of detail allows the model to reason about specific threats like token replay, Lambda event injection, or DynamoDB IAM policy misconfigurations. The prompt template uses placeholders like [SYSTEM_DESCRIPTION] and [TRUST_BOUNDARIES] to enforce this structured input.

Do not use this prompt on live production systems where runtime telemetry is available; it is a design-time analysis tool, not a replacement for dynamic testing or penetration testing. It cannot reason about vulnerabilities introduced by specific code implementations, library versions, or runtime configurations. Furthermore, avoid using this prompt for a system that is already fully built and deployed without also pairing it with a review of the as-built state, as design drift is a common source of missed threats. The next step after generating the threat model is to feed the output into a manual review session with the broader engineering team to validate findings, prioritize mitigations, and create actionable security tickets.

The following prompt template is designed to be copied directly into your AI harness. Every placeholder enclosed in square brackets—such as [SYSTEM_DESIGN], [TRUST_BOUNDARIES], and [OUTPUT_SCHEMA]—must be replaced with your actual system-specific context before sending the prompt to the model. The template assumes you have already gathered architecture diagrams, data flow descriptions, component inventories, and any existing security controls documentation. Do not send incomplete placeholders to the model; the output quality depends entirely on the specificity of the inputs you provide.

codeCopy
You are a senior security architect performing a structured threat model on the following system design. Your analysis must be rigorous, evidence-based, and actionable.

## SYSTEM DESIGN
[SYSTEM_DESCRIPTION]

## ARCHITECTURE CONTEXT
- Components: [COMPONENT_LIST]
- Data Flows: [DATA_FLOW_DESCRIPTIONS]
- Trust Boundaries: [TRUST_BOUNDARY_DEFINITIONS]
- External Dependencies: [EXTERNAL_SERVICES_AND_INTEGRATIONS]
- Authentication Mechanisms: [AUTH_MECHANISMS]
- Authorization Model: [AUTHORIZATION_MODEL]
- Data Classification: [DATA_CLASSIFICATION_LEVELS]

## THREAT MODELING METHODOLOGY
Use the [METHODOLOGY] approach. If STRIDE, cover Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege for each trust boundary crossing. If Attack Trees, build trees for each critical asset with AND/OR node decomposition.

## EXISTING CONTROLS
[EXISTING_SECURITY_CONTROLS]

## COMPLIANCE REQUIREMENTS
[COMPLIANCE_STANDARDS]

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "threat_model": {
    "methodology": "[METHODOLOGY]",
    "scope": "Brief scope statement",
    "assumptions": ["Assumption 1", "Assumption 2"],
    "trust_boundaries_analyzed": [
      {
        "boundary_name": "string",
        "crossing_flows": ["flow1", "flow2"],
        "threats": [
          {
            "threat_id": "TM-001",
            "category": "Spoofing|Tampering|Repudiation|InformationDisclosure|DenialOfService|ElevationOfPrivilege",
            "description": "Clear threat description",
            "affected_component": "component name",
            "attack_vector": "How an attacker would exploit this",
            "likelihood": "High|Medium|Low",
            "impact": "Critical|High|Medium|Low",
            "existing_controls": ["control1"],
            "control_effectiveness": "Adequate|Partial|Missing",
            "missing_mitigations": ["recommended mitigation"],
            "cvss_base_score": "0.0-10.0 or null if not applicable"
          }
        ]
      }
    ],
    "prioritized_risk_register": [
      {
        "rank": 1,
        "threat_id": "TM-001",
        "risk_score": "Critical|High|Medium|Low",
        "rationale": "Why this ranks here"
      }
    ],
    "control_gaps_summary": ["gap1", "gap2"],
    "recommendations": [
      {
        "priority": "P0|P1|P2|P3",
        "action": "Specific remediation action",
        "effort": "Small|Medium|Large",
        "owner_suggestion": "Suggested team or role"
      }
    ]
  }
}

## CONSTRAINTS
- Every threat must reference a specific trust boundary crossing or data flow.
- Do not invent threats for components or flows not described in the system design.
- If a control is listed as existing, evaluate its effectiveness; do not ignore it.
- Mark likelihood as "Low" only when multiple controls make exploitation impractical.
- If compliance requirements are provided, map relevant threats to specific control requirements.
- For any threat rated Critical risk, include a specific P0 recommendation.
- If the system design is incomplete for a category, note it in assumptions rather than guessing.

To adapt this template for your environment, start by replacing [SYSTEM_DESCRIPTION] with a detailed narrative of your architecture—include what the system does, who uses it, and where it runs. Populate [COMPONENT_LIST] with every service, database, queue, gateway, and external integration. Define [TRUST_BOUNDARY_DEFINITIONS] explicitly: a trust boundary is any point where data or control crosses from a higher-trust zone to a lower-trust zone, such as the public internet to your API gateway, or between microservices in different security domains. Choose [METHODOLOGY] based on your needs—STRIDE works well for systems with clear trust boundaries and data flows, while Attack Trees are better when you have well-defined critical assets like a payment processing pipeline or a customer PII store. If you lack existing controls documentation, replace [EXISTING_SECURITY_CONTROLS] with "No controls documented; assume baseline cloud defaults" rather than leaving it empty, so the model knows to flag missing controls rather than assuming they exist.

Before integrating this prompt into a production workflow, validate that every placeholder has been replaced with concrete, non-generic content. A common failure mode is providing vague component names like "auth service" without specifying the protocol, token format, or session behavior—this produces threats that are too generic to act on. Test the prompt first with a known architecture where you can manually verify the threat model output. If the model misses obvious threats, your system description likely lacks the detail the model needs to reason about attack paths. After generation, always have a human security architect review the output before filing findings into a bug tracker or risk register. The model can identify patterns and suggest mitigations, but it cannot replace the contextual judgment of an engineer who understands the business impact of each threat.

Integrating this prompt into a production security review workflow requires treating it as a structured data pipeline, not a chat interface. The prompt expects a system design document as [DESIGN_DOC] and an optional [THREAT_MODEL_METHODOLOGY] (e.g., STRIDE, attack trees, LINDDUN). The output is a structured threat model JSON object containing threats, existing controls, missing mitigations, and a priority score. The harness must validate this output against a strict schema before accepting it, because downstream risk registers and ticketing systems depend on consistent field types and completeness. A thin orchestration layer—whether a Python script, a CI/CD plugin, or a security orchestration platform—should own the lifecycle: fetch the design doc, assemble the prompt, call the model, validate the response, and route the result.

The harness should enforce a validate-or-retry loop. Define a JSON schema that requires threats (array of objects with id, title, category, stride_element, description, existing_controls, missing_mitigations, priority), methodology, coverage_notes, and unmodeled_areas. After the model responds, parse the JSON. If parsing fails, retry with the error message appended to the prompt, up to a maximum of 2 retries. If validation against the schema fails, extract the specific field errors and include them in the retry prompt. Log every attempt—raw prompt, raw response, parse errors, and validation errors—to an audit trail. For high-risk systems (e.g., financial transaction flows, healthcare data pipelines), insert a human approval gate after successful validation: route the structured threat model to a security architect's review queue before it is committed to the risk register. Use a model with strong JSON mode and reasoning capabilities (e.g., Claude 3.5 Sonnet, GPT-4o) and set temperature to 0.1–0.2 to maximize structural consistency without sacrificing threat creativity.

Common failure modes in the harness include: the model producing threats that don't map to the specified methodology, omitting the existing_controls field for threats where controls are absent (it should return an empty array, not null), and hallucinating threats for components not mentioned in the design doc. Mitigate these by adding an eval step that checks threat-to-methodology alignment and design-doc grounding. Run a second LLM call as a judge to score each threat on evidence_in_design_doc (1–5) and methodology_alignment (1–5). Flag threats scoring below 3 for human review. Do not ship threat models directly to Jira or a risk register without this grounding check—an ungrounded threat model erodes trust in the entire security review process.