STRIDE — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege — has been the workhorse of structured threat modeling since the late 1990s. The framework holds up surprisingly well when you bring it to LLM applications, but only if you adapt the categories to fit how generative AI actually breaks. Without that adaptation, STRIDE for LLMs becomes a checkbox exercise that misses the things you most need to catch.
Step 1: Draw the Data Flow Diagram, Including the Model
Treat the LLM as a separate trust boundary. Anything passed into the model — system prompts, retrieved content, tool results, user input — crosses the boundary inbound. Anything the model outputs crosses outbound. Most teams underrepresent the inbound side. Document every source of text that ends up in the prompt.
Step 2: Spoofing — Who Is Talking to the Model?
Beyond standard authentication, ask: can a low-privilege actor inject content that the model will treat as if it came from a higher-privilege source? Indirect prompt injection (a malicious document, webpage, or email reaching the model through retrieval) is a spoofing attack against the model itself. Defences live in how you mark trust levels in the prompt and how strictly the model is instructed to honour them.
Step 3: Tampering — What Can Modify the Inputs?
Tampering covers training data poisoning (long-term), retrieval source poisoning (medium-term), and live prompt manipulation (short-term). The classic STRIDE question — what data can be modified by an attacker before it reaches the trusted system — applies here, but the trusted system is the model, and the data flows are wider than most teams realise.
Step 4: Repudiation — Can You Prove What the Model Did?
Logging matters more, not less, with LLMs in the stack. The model is non-deterministic. Six months from now, when someone asks what the system told a customer, you need a record. Log the full prompt (or a hash of any sensitive parts), the model output, the model and version used, and any tools the model invoked. Treat this as forensic evidence, not just observability.
Step 5: Information Disclosure — What Can Leak Through the Model?
This is the category where teams find the most surprises. System prompts can be extracted by sufficiently determined users (LLM07 in OWASP). Sensitive context retrieved for one user can leak into another user response if the cache or session boundaries are wrong. Training data can be reproduced verbatim under specific conditions. RAG systems can return documents the user was not authorised to see if the retrieval layer does not enforce authorisation properly.
The single most common information disclosure issue we see in production: retrieval that bypasses the application authorisation layer. The user asks a question, the retriever pulls relevant documents from the index without checking who can see what, and the model summarises content that was never meant to reach this user. Authorisation must be enforced before retrieval, not after.
Step 6: DoS and Elevation of Privilege
Denial of service is straightforward: token-cost-amplification attacks, recursive tool calls, context-window exhaustion. The defences are rate limits, max-token caps, and explicit termination conditions on agent loops. Elevation of privilege is the more dangerous one. If the model has access to powerful tools — file modification, transactions, external API calls — every prompt injection is a potential privilege escalation. The defence is privilege separation: the model should never have access to capabilities beyond what the current user, in the current task, with the current trust level, actually needs.
Run STRIDE the way you always have: per-component, per-data-flow. Just expand each category to include the LLM-specific attack classes above. The framework still works. It just has more rows in the threat list when an LLM is in the system.