An LLM can speed up STRIDE threat modeling by walking each data flow through the six categories and proposing threats you may have skipped. It works from the description you give it, so the output is only as good as your system model, and every proposed threat still needs a human to accept, rank, or reject it.
STRIDE in one paragraph
Microsoft's threat modeling documentation defines STRIDE as six categories: Spoofing (using another user's authentication information), Tampering (malicious modification of data), Repudiation (denying an action when nobody can prove otherwise), Information Disclosure (exposing data to people who should not see it), Denial of Service (making a service unavailable to valid users), and Elevation of Privilege (an unprivileged user gaining privileged access).
OWASP's threat modeling cheat sheet adds the process: model the system with data flow diagrams, identify and rank threats with STRIDE, choose a response (mitigate, eliminate, transfer, or accept), then review and validate.
Step 1: describe the system plainly
Write down the components, the data stores, the external parties, and the trust boundaries. A short list is better than a diagram the model cannot see.
Components: web app, API, Postgres, object store, third-party payment provider.
Flows: browser to API over HTTPS; API to Postgres; API to payment provider with an API key.
Trust boundaries: internet to API; API to payment provider.
Sensitive data: account details, invoices.
Step 2: ask per flow, per category
Do not ask for "all threats". Ask for one flow at a time and require all six categories, with "not applicable" allowed.
For the flow "browser to API", list one or two realistic threats for each STRIDE category.
For each: the attacker's goal, the precondition, and a mitigation that would address it.
Say "not applicable" where nothing realistic applies. Use only the system description above.
The "use only the description" line keeps it from inventing components you do not have.
Step 3: separate brainstorming from judgment
Take the list into a team session and sort it. The model is good at breadth. Your team knows which threats are realistic given your customers, your deployment, and your existing controls. Rank by likelihood and impact, and record why you accepted any risk, as the OWASP guidance advises.
Step 4: turn mitigations into work
Each accepted mitigation becomes a requirement or a ticket with an owner. A threat model that stops at a document has not changed anything.
Step 5: validate
Ask the fourth question from the Threat Modeling Manifesto: did we do a good enough job? Compare the model's list to your last incident or pen test findings. If real issues were missing from the list, add them to your system description or your prompt.
Limits
The model will miss threats that depend on business context or on how your team actually operates. It may also repeat generic advice. Treat it as a checklist generator, not a reviewer. If your team has never done threat modeling, start with the four questions for small teams.
Quick check
Should the model draw the data flow diagram?
It can draft a text description or diagram code, but your team must check it against reality. A wrong diagram makes every later step wrong.
Sources
Last reviewed: 19 October 2026.
