No. An LLM can draft a system description, suggest threats per data flow, and tidy the output, but it cannot know your business context, confirm the model matches the real system, or own the decision to accept a risk. Use it to prepare and extend a session, not to skip one.
What the process needs
OWASP's cheat sheet describes threat modeling as four steps: system modeling, threat identification and ranking, response and mitigations, and review and validation. It also advises inviting security specialists, building shared knowledge across teams, and updating the model as the system changes.
Several of those are about people and facts, not text generation.
Where an LLM helps
- Drafting the first system description from a README or design doc, for a human to correct.
- Breadth. Walking each flow through STRIDE so nothing obvious is skipped. See a STRIDE prompt for an LLM assistant.
- Translating a technical threat into plain language for a product manager.
- Formatting accepted mitigations into tickets.
- Recall. Reminding you of attack patterns you rarely think about.
Where it falls short
- Truth of the model. It cannot see your deployment. If the description is wrong, the threats are wrong, and the output sounds equally confident either way.
- Ranking. Likelihood and impact depend on your users, data, and existing controls. The model has a generic view.
- Ownership. Accepting a risk is a business decision with a name attached.
- Shared understanding. A major value of a session is that engineers, product, and operations learn how the system can fail. A document the model produced does not transfer that.
- Novel or business logic threats, such as abuse of a pricing rule, which come from knowing how your business works.
A decision guide
- New feature or small change: a short human review, with an LLM generated checklist as input.
- Major architecture change: a full session, with the LLM used for preparation and follow up.
- Regulated or safety critical system: a full session with specialists, and the LLM only for drafting.
- No threat modeling yet: start with a human session, and add the LLM once you have a baseline.
A sensible hybrid
Before the session, have the model draft the description and a first threat list. In the session, correct the description first, then review the threats, striking the unrealistic ones and adding the missing ones. After the session, use the model to write the summary. Keep the artifacts with the project so they can be updated.
Watch for the false comfort
A tidy, complete looking threat model is persuasive. Compare it against something real, such as your last incident review, to see whether it would have caught what happened.
Quick check
Is a model generated threat model better than none?
For a team that would otherwise do nothing, probably yes, as a starting point. It becomes a problem when it is treated as finished and nobody checks it against the real system.
Sources
Last reviewed: 19 October 2026.
