Threat Modeling Prompt for New Feature Design

This prompt is designed for security architects and engineering leads who need to generate a structured threat model from a feature specification or design document before a single line of code is written. It takes a feature description, architecture notes, data flow diagrams, and trust boundary definitions as input and produces a threat inventory organized by STRIDE categories, an attack surface enumeration, and prioritized mitigation recommendations. The primary job-to-be-done is shifting security analysis left into the design phase, where the cost of fixing architectural flaws is lowest. Use this prompt during design review gates, security architecture sprints, or as part of a formal shift-left security program that requires documented threat analysis before implementation begins.

The prompt requires four concrete inputs to produce a reliable output: a detailed feature specification describing what the system will do, architecture notes covering component interactions and technology choices, data flow diagrams or descriptions showing how data moves between trust boundaries, and explicit trust boundary definitions that mark where privilege levels or network segments change. Without these inputs, the model will hallucinate architecture details or miss entire attack surfaces. The output contract is a structured threat model containing a STRIDE-categorized threat inventory, an attack surface enumeration with entry points and exposure ratings, and prioritized mitigation recommendations mapped to specific threats. Each finding should include a unique identifier, the affected component, the threat scenario, and a severity rationale grounded in the provided architecture context.

Do not use this prompt for runtime incident response, live vulnerability scanning, or compliance audits. Those workflows require different evidence grounding, output contracts, and operational constraints. For incident response, you need prompts that correlate runtime signals with source code and recent changes. For vulnerability scanning, you need prompts that interpret static analysis or dependency scan results against exploitability context. For compliance audits, you need prompts that produce auditor-ready evidence packages with traceable citations to regulatory requirements. This prompt is also not suitable when the feature design is still in flux—wait until the architecture notes and trust boundaries are stable enough to serve as grounding evidence. If the design changes significantly after threat modeling, re-run the prompt with updated inputs rather than attempting to patch the previous output.

The following prompt template is designed to be copied directly into your AI harness, IDE, or orchestration layer. It accepts a feature specification and a set of constraints, and it produces a structured threat model. Every placeholder in square brackets must be replaced with concrete values before execution. Do not leave any placeholder unresolved in production—missing context is the most common cause of vague or incomplete threat models.

textCopy
You are a senior security architect performing a threat modeling review for a new feature. Your analysis must be grounded in the provided feature specification and design documents. Do not invent threats that are not plausible given the described architecture, data flows, and trust boundaries.

## INPUT
Feature Specification:
[FEATURE_SPECIFICATION]

Design Documents (optional):
[DESIGN_DOCUMENTS]

## CONSTRAINTS
- Risk tolerance level: [RISK_TOLERANCE: low | medium | high]
- Deployment environment: [DEPLOYMENT_ENVIRONMENT: cloud | on-premise | hybrid | air-gapped]
- Regulatory context: [REGULATORY_CONTEXT: none | GDPR | HIPAA | PCI-DSS | SOC2 | FedRAMP | custom]
- Scope boundary: [SCOPE_BOUNDARY: description of what is in and out of scope]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "feature_summary": "One-sentence summary of the feature under review.",
  "trust_boundaries": [
    {
      "boundary_id": "TB-01",
      "name": "Short boundary name",
      "description": "What crosses this boundary and why it matters.",
      "crossing_data": ["data element 1", "data element 2"],
      "crossing_direction": "inbound | outbound | bidirectional"
    }
  ],
  "attack_surface": [
    {
      "surface_id": "AS-01",
      "name": "Short surface name",
      "entry_point": "API endpoint, UI field, file upload, message queue, etc.",
      "exposure": "public | authenticated | internal | admin-only",
      "notes": "Why this surface is relevant to threat analysis."
    }
  ],
  "threat_inventory": [
    {
      "threat_id": "T-01",
      "stride_category": "Spoofing | Tampering | Repudiation | Information Disclosure | Denial of Service | Elevation of Privilege",
      "title": "Short threat title",
      "description": "Detailed description of the threat scenario.",
      "affected_asset": "What component, data store, or user is impacted.",
      "precondition": "What must be true for this threat to be exploitable.",
      "impact": "Confidentiality | Integrity | Availability impact with severity rationale.",
      "likelihood": "low | medium | high with rationale.",
      "risk_level": "low | medium | high | critical",
      "related_boundaries": ["TB-01"],
      "related_surfaces": ["AS-01"]
    }
  ],
  "mitigations": [
    {
      "mitigation_id": "M-01",
      "addresses_threats": ["T-01"],
      "strategy": "eliminate | reduce | transfer | accept",
      "description": "Concrete mitigation action.",
      "implementation_effort": "low | medium | high",
      "verification": "How to test that this mitigation is effective."
    }
  ],
  "completeness_notes": "Any threats or surfaces that could not be fully analyzed due to missing information in the specification.",
  "review_recommendation": "Proceed | Proceed with Mitigations | Escalate for Manual Review"
}

## INSTRUCTIONS
1. Start by identifying trust boundaries from the feature specification and design documents.
2. Enumerate the attack surface by listing every entry point where data or control crosses a trust boundary.
3. For each attack surface element, apply STRIDE to generate plausible threats.
4. For each threat, propose at least one concrete mitigation.
5. If the specification is missing critical details needed for analysis, note them in completeness_notes rather than guessing.
6. If the risk tolerance is low or the regulatory context is high-stakes, recommend Escalate for Manual Review when threats with critical or high risk are identified.

To adapt this template, replace each placeholder with data from your feature intake process. The [FEATURE_SPECIFICATION] should be the full text of the PRD, design doc, or RFC. If no design documents exist, set [DESIGN_DOCUMENTS] to "None provided" and expect the model to flag missing architectural detail in completeness_notes. The [SCOPE_BOUNDARY] is critical for preventing scope creep—be explicit about what components, services, and data stores are in scope. After generating the threat model, always run a completeness check: compare the enumerated attack surfaces against your known system topology and verify that every trust boundary crossing is represented. For high-risk features, route the output to a human security reviewer before accepting mitigations.

This prompt is designed to be called programmatically as part of a feature design review pipeline, not as a one-off chat interaction. The harness should accept a structured feature specification (the [FEATURE_SPEC]) and a design document (the [DESIGN_DOC]) as inputs, assemble the prompt with the correct STRIDE categorization schema, and parse the model's output into a machine-readable threat inventory. Because the output drives security decisions, the harness must validate the response against the expected schema before it is presented to a human reviewer or stored in a threat register.

Start by defining a strict output schema that the model must follow. The prompt already requests STRIDE categories, trust boundaries, attack surface elements, and mitigation recommendations. Your harness should validate that the returned JSON contains all required top-level keys (threats, trust_boundaries, attack_surface, mitigations), that each threat has a non-empty stride_category matching one of the six STRIDE types, and that every identified threat references at least one affected component from the design scope. Use a JSON Schema validator in your application layer—do not rely on the model to self-correct without a validation step. If validation fails, implement a single retry by feeding the validation errors back into the prompt as [PREVIOUS_OUTPUT] and [VALIDATION_ERRORS], with a hard stop after two failed attempts to prevent loops.

Model choice matters here. Use a model with strong reasoning capabilities and a large context window, as the combined feature spec and design doc can be lengthy. For high-sensitivity features, route the prompt to a model deployed in your own VPC or private cloud tenant. Log every request and response, including the validated threat model and any validation failures, to an append-only audit store. This log becomes critical evidence for compliance reviews and post-incident analysis. Do not log the raw feature spec if it contains sensitive business logic; instead, log a content hash for traceability.

The harness must enforce a human review gate before any threat model is considered final. After successful validation, route the output to a security architect or engineering lead for approval. The review interface should highlight threats that scored above a configurable risk threshold, flag any trust boundary that was not explicitly mentioned in the design doc (potential model hallucination), and allow the reviewer to accept, reject, or amend each finding. Only after human sign-off should the threat model be persisted to the threat register and linked to the feature's issue tracker.

Avoid wiring this prompt directly into a CI/CD pipeline without the human review gate. An automated threat model is a starting point for expert analysis, not a replacement for it. The most common production failure mode is scope creep: the model may invent components or data flows not present in the design doc. Your harness should cross-reference every component mentioned in the output against the input design scope and flag any additions for the human reviewer. This scope-anchoring check is the single most important guardrail for keeping the threat model grounded in reality.