Teams building their first LLM application typically discover its security gaps in production, one incident report at a time: a user found a way to make the support bot discuss a competitor's pricing, another user got the internal wiki assistant to summarize a document it should never have retrieved, a third managed to get a coding agent to run a shell command nobody reviewed. Each incident gets patched individually, and the team ends up with a pile of point fixes that were never derived from a coherent picture of what could go wrong in the first place. That reactive posture is expensive, because the fix for incident three often would have prevented incident seven if anyone had looked for the pattern before it happened.
Threat modelling is the discipline of building that coherent picture before shipping: naming the assets worth protecting, the actors who might attack them, the trust boundaries those actors have to cross, and the specific ways an LLM's behavior makes those boundaries easier or harder to cross than in a traditional application. It borrows structure from decades of application security practice — STRIDE, attack trees, abuse cases — but an LLM application has attack surface those frameworks were not written with in mind: a natural-language interface that follows instructions from anywhere they arrive, and tool access that turns a persuasive sentence into a real-world action.
A team that threat-models before building knows in advance which of their planned features need a guardrail before launch and which are lower-risk enough to ship without one — the alternative is discovering that distinction from whichever failure mode a user or an attacker finds first.