The conventional wisdom: Your existing threat modeling framework will work fine for AI systems. Just add LLM-specific threats to your STRIDE analysis, update your data flow diagrams, and you're covered.
Security teams are treating AI deployments like any other third-party integration. They're mapping trust boundaries, identifying spoofing risks, and checking for elevation of privilege vectors. The same frameworks that worked for your REST APIs and microservices.
Here's the problem: you're bringing the wrong mental model to a fundamentally different attack surface.
Why Traditional Models Fall Short
Traditional threat modeling assumes you control the logic. You write the code, define the state transitions, and know what "normal" looks like. When you model a web application, you can enumerate the paths through your code and identify where each security control should live.
LLMs break this assumption. You don't control the model's internal logic. You can't enumerate the paths. The system's behavior emerges from training data and probabilistic token generation, not from deterministic code you wrote.
Consider what changed at the recent [un]prompted AI Security Practitioners Conference: practitioners reported that the "meantime to availability of an exploit" has dropped from months to hours. That's not just faster vulnerability discovery. It's a signal that the attack surface itself operates on a different timeline than your traditional applications.
Your STRIDE model asks: "Can an attacker tamper with data in transit?" For an LLM, the relevant question is: "Can an attacker inject instructions that the model will treat as more authoritative than your system prompts?" That's not tampering. That's exploiting how the model weighs context.
The Evidence
The conference emphasized a defense-in-depth approach across three layers: application, middleware, and model. Notice what's missing from your typical threat model: the model layer itself.
When you threat model a traditional application, you're modeling YOUR code. With LLMs, you need to model:
Prompt injection as a first-class threat category. This isn't input validation. An attacker can embed instructions in user content that override your system's intended behavior. Your input sanitization won't catch it because the malicious payload looks like legitimate text.
Context window poisoning. Traditional threat models don't account for attacks that work by filling limited memory with attacker-controlled content. Your LLM has a finite context window. An attacker who can populate it with carefully crafted examples can effectively reprogram the model's behavior for that session.
Training data extraction. You can't threat model this with data flow diagrams because the "flow" happened during training, not runtime. Yet the model may regurgitate sensitive training data under the right prompting conditions.
The "Prompt as Code" concept highlighted at the conference makes this concrete: if prompts are code, then prompt injection is code injection. But your Web Application Firewall won't catch it. Your static analysis tools won't flag it. Your code review process isn't examining prompts with the same rigor as SQL queries.
What to Do Instead
Build a parallel threat model specifically for your AI components. Don't try to shoehorn LLM threats into your existing STRIDE documentation.
Start with the model's trust boundaries. Map what the model trusts implicitly. System prompts? User input? Retrieved context from your RAG pipeline? Every trust boundary is a potential injection point.
Model the prompt construction pipeline. Trace how user input flows into prompts. Where does sanitization happen? How do you separate instructions from data? If you're concatenating user content directly into prompts, you've already failed.
Identify your context sources. For RAG systems, model the retrieval mechanism as an attack surface. Can an attacker poison your vector database? Can they manipulate search rankings to inject malicious context? Your traditional threat model probably treats your database as a trusted component. Your vector store isn't.
Add a "model behavior" threat category. Ask: "What happens if the model ignores my instructions?" This isn't a bug in your code. It's inherent model behavior. Your mitigations need to work even when the model doesn't follow your prompts.
Threat model your fine-tuning data. If you're fine-tuning models, treat your training pipeline like a supply chain. Who controls the training data? How do you validate it? A poisoned fine-tuning dataset is a backdoor that no runtime security control will catch.
Integrate these AI-specific models into your existing security review process, but keep them separate. When you're reviewing a new LLM feature, you need both: the traditional application security model AND the AI-specific model. They're complementary, not redundant.
When Traditional Models Are Still Relevant
Your existing threat modeling isn't useless. It's necessary but insufficient.
You still need to model the application layer. Authentication, authorization, session management, API security, these don't change because you added an LLM. If your LLM feature has broken access control, no amount of AI-specific threat modeling will save you.
The defense-in-depth approach the conference highlighted requires both layers. Your application security controls prevent unauthorized access to the LLM. Your AI-specific controls prevent prompt injection once someone has legitimate access.
Traditional threat modeling is also right about one thing: you need to model what you actually built, not what you wish you built. If you're using a third-party LLM API, model the trust boundary at the API call. You don't control the model, so you can't model its internals. Focus on what you send, what you receive, and how you handle both.
But don't convince yourself that updating your existing STRIDE analysis is enough. The attack surface is different. The threats are different. Your model needs to reflect that reality, not paper over it with familiar frameworks that don't quite fit.
