A STRIDE Threat Modeling Prompt That Skips the Workshop

Threat modeling has a scheduling problem. It's the security practice everyone agrees matters and almost nobody does, because the honest version means booking a room, three engineers, and a security lead for most of a day. So it gets skipped, and the trust boundary nobody drew is the one that leaks.

A STRIDE threat modeling prompt collapses that workshop into a structured pass one engineer runs in an afternoon. You describe the feature, the prompt extracts the data-flow model, walks the six STRIDE categories against each component, and hands back a ranked mitigation plan you can file. Not a demo that a model can find a threat. A workflow that produces the artifact.

The tools that rank for this query mostly aren't prompts you can copy. They're hosted apps.

Why the ranking tools don't give you a reusable prompt

Search "STRIDE threat modeling with AI" and the top result is usually STRIDE GPT, a genuinely good open-source project. But it's a Streamlit app and a Python CLI, not a prompt template. You deploy it, feed it structured fields, and it returns threats, attack trees, and DREAD scores. Useful. Also a thing you have to run and maintain.

The academic and vendor write-ups have the opposite gap. Pieces like the everpuredata walkthrough on LLM-driven STRIDE explain the methodology and show that a model can reason about threats, but they stop at illustration. There's no locked output contract, no per-component enumeration you can rerun, no path from "here are some threats" to "here are the tickets."

That's the gap. A copyable prompt with a fixed structure, that a developer pastes into Claude or ChatGPT with no deployment step, and that ends in something a sprint can absorb.

The four passes that make it work

One giant prompt asking for "a threat model" produces a wall of generic threats. The reliable shape is four passes that each hand their output to the next.

1. Extract the data-flow model. Before any threats, the model names the elements: external entities, processes, data stores, and the data flows between them. Then it draws the trust boundaries. This is the step everyone skips, and it's why their threat lists are shallow.
2. Enumerate STRIDE per element. Walk each component against the six categories. A data store gets Tampering and Information Disclosure threats; a process crossing a trust boundary gets Spoofing and Elevation of Privilege. Per-element enumeration is what stops the model from listing the same three OWASP threats it always reaches for.
3. Write the top threats as abuse cases. Take the highest-risk threats and expand them into step-by-step attacker narratives, including the detection gap. "An attacker with a stolen session token replays it against the export endpoint; nothing logs the anomaly" beats "session hijacking risk."
4. Plan the mitigations. Each surviving threat gets a mitigation, an owner hint, and an effort band, sorted so the exploitable-and-cheap fixes lead.

Anatomy of the prompt

Variables → {{feature_description}}, {{tech_stack}}, {{trust_assumptions}}
Role      → Application security engineer running STRIDE.
Pass 1    → data-flow model: entities, processes, stores, flows, boundaries
Pass 2    → per element: threats across all six STRIDE categories
Pass 3    → top threats as abuse-case narratives + detection gap
Per threat → ID | STRIDE category | element | likelihood | impact | mitigation
Verdict   → ranked plan, risk = likelihood × impact, highest first

The {{trust_assumptions}} variable is the one people leave blank and shouldn't. State what you're trusting: the CDN, the internal network, the auth provider. The model can only find a violated assumption if you tell it what the assumption was.

How the models behave on this

Threat enumeration is where model differences show up sharply.

Claude holds the per-element structure across a long feature description and is willing to say a component has no realistic threat in a given category rather than inventing one to fill the grid. GPT-4o is often more creative on the abuse-case narratives, spotting a chained attack Claude states more flatly, but it tends to over-enumerate, tagging low-risk theoretical threats as if they mattered. Anchor the likelihood scale explicitly and that settles down. Gemini's long context helps when you paste an entire design doc as {{feature_description}}, though it needs the output contract restated at the end or it drifts back to prose.

Prompt-craft patterns for threat work

Pattern 1: force the data-flow model before threats

Make pass one a hard gate. If the model jumps straight to threats, the output is a checklist, not a threat model. Requiring the entities-and-boundaries table first grounds everything downstream.

Pattern 2: anchor likelihood and impact

likelihood high:   any anonymous user can reach it with common tooling
likelihood medium: needs a valid account or specific preconditions
likelihood low:    needs insider access or an unlikely chain
impact high:       auth bypass, data exfiltration, or RCE
impact medium:     single-user data exposure or integrity loss
impact low:        information leak with no direct exploit

Without anchors, "high" means whatever the model felt that run, and two threat models of the same feature won't agree.

Pattern 3: require the detection gap

For each top threat, ask "would we know this happened?" Naming the missing log or alert turns the mitigation plan into two workstreams: prevent it, and detect it if prevention fails. That second column is what auditors actually want.

Variables you'll set

Getting started

1. Write the feature description as if briefing a new engineer. Vague input, vague threats.
2. Run pass one alone first and eyeball the data-flow model. If a trust boundary is wrong, fix it before enumerating.
3. Fill {{tech_stack}} precisely; it decides which threats are realistic.
4. Anchor likelihood and impact in the prompt, then let it rank.
5. Review the top five abuse cases yourself. This is where business-logic threats hide that a model won't reach without your domain context.
6. Export the mitigation plan straight into your tracker; each row is already ticket-shaped.

Threat modeling is a design-time practice, so it pairs naturally with a code-time one. Once the feature ships, the Threat Modeling Workflow System gives you the model to review the implementation against, and a dedicated code pass catches what got built wrong.

Threat modeling finds where weaknesses could exist; the review that follows finds where they actually do. For the code-level pass mapped to a taxonomy, see a security code review prompt mapped to CWE. And if the thing you're modeling is an AI agent rather than a web service, the injection surface is different — read prompt injection defense for coding agents for the threats a normal STRIDE pass won't name.