Traditional threat modelling frameworks were built for a world where software did what it was told. AI systems don't. Here is how STRIDE-AI, MITRE ATLAS, and the OWASP LLM Top 10 layer together to address that gap.
The problem with traditional threat modelling
When security engineers talk about threat modelling, they are usually talking about a process that goes something like this: draw a diagram of your system, identify where data flows across trust boundaries, and ask what an attacker could do at each point. The classic tool for this is STRIDE -- Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
STRIDE has worked well for over two decades. It was developed at Microsoft in the late 1990s, and most of the threat models you will find in corporate security programs today still use it, or something derived from it.
The problem is that it was designed for deterministic software. Software that, given an input, produces a predictable output. Software where the code is the source of truth and the attack surface is primarily in how data moves, where permissions are granted, and whether authentication can be bypassed.
AI systems are not deterministic. They behave differently based on context, phrasing, temperature settings, and the content of their training data. A large language model does not just process your input -- it interprets it, reasons about it, and generates a response shaped by billions of parameters you cannot inspect. The attack surface is not just at the API boundary. It is inside the model's behaviour itself.
That shift breaks a key assumption that traditional threat modelling was built on. And it is why the industry has spent the last few years building new frameworks to fill the gap.
What STRIDE was built to do -- and where it stops
STRIDE maps each letter to a threat category:
- S -- Spoofing: Can an attacker pretend to be someone they are not?
- T -- Tampering: Can data be modified in transit or at rest?
- R -- Repudiation: Can an action be performed without leaving a trace?
- I -- Information Disclosure: Can sensitive data be accessed by unauthorized parties?
- D -- Denial of Service: Can the system be made unavailable?
- E -- Elevation of Privilege: Can an attacker gain more access than they should have?
Applied to a traditional web application, this is a complete and useful map. You work through each component, ask which STRIDE categories apply, and design controls against each one.
Apply it to an LLM-based system and you immediately hit the edges of what it was designed for. Prompt injection -- where an attacker embeds instructions in user input that override the model's intended behaviour -- does not fit cleanly into any single STRIDE category. It is partially Tampering (manipulating what the model does), partially Spoofing (making the model act as if it received different instructions), and partially Elevation of Privilege (getting the model to do things it should not be allowed to do). It is all three at once, and STRIDE gives you no language for that.
The same is true for model inversion attacks, training data poisoning, and adversarial inputs. Traditional STRIDE can gesture at these things but cannot name them precisely, which means the threat model ends up incomplete.
STRIDE-AI: extending the model for AI-specific threats
STRIDE-AI takes the original framework and adds the threat categories that emerge specifically from machine learning systems. The core letters stay the same, but the threat descriptions are rewritten for the AI context.
Under STRIDE-AI, the Spoofing category now includes model impersonation -- deploying a lookalike model that behaves slightly differently from the original to harvest user inputs or erode trust. Tampering expands to include training data poisoning, where an attacker injects malicious examples into training data to subtly shape model behaviour long before the system is deployed. Repudiation extends to cover the fact that AI outputs are often non-deterministic and difficult to attribute -- if a model produces harmful content, determining exactly why it did so is genuinely hard.
Information Disclosure in the AI context includes model inversion and membership inference attacks, where an attacker interacts with the model's outputs to reconstruct parts of its training data -- potentially exposing private information that was in the dataset. Denial of Service in AI includes prompt flooding and token exhaustion attacks designed to run up inference costs or degrade availability. Elevation of Privilege includes prompt injection and jailbreaking -- coercing the model into operating outside its intended guardrails.
STRIDE-AI does not replace STRIDE. It layers on top of it. If your system has an AI component sitting behind a traditional API, you still apply original STRIDE to the API layer and STRIDE-AI to the model layer.
MITRE ATLAS: the attacker's playbook for AI systems
MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is the AI equivalent of MITRE ATT&CK -- the framework that documents real-world adversary tactics, techniques, and procedures for traditional systems.
Where STRIDE-AI tells you what category of threat to consider, ATLAS tells you how an attacker would actually execute it. It is organised the same way as ATT&CK: tactics (the attacker's objective at each stage) and techniques (the specific methods used to achieve each objective).
ATLAS tactics include:
- Reconnaissance: Gathering information about the AI system before attacking it. This includes discovering model architecture, querying outputs to infer training data, or scraping public model cards.
- Resource Development: Acquiring the tools and capabilities needed for an attack -- this can include training a substitute model to probe a target system's decision boundary.
- Initial Access: Getting a foothold. In AI systems this often means prompt injection, or exploiting an API that exposes model functionality without sufficient access controls.
- ML Attack Staging: A tactic unique to ATLAS. Preparing the attack artefacts -- crafting adversarial inputs, poisoned datasets, or malicious plugins -- before executing the attack.
- Exfiltration: Extracting information. In AI contexts this includes training data theft via model inversion, or simply prompting the model into disclosing information it should not.
The real value of ATLAS is that its techniques are grounded in documented real-world incidents and published research. When you map a threat to an ATLAS technique, you get a reference to how that technique has actually been used, what detection looks like, and what mitigations exist. It turns a theoretical threat into a concrete, researched attack path.
OWASP LLM Top 10: risks ranked by real-world impact
OWASP -- the Open Web Application Security Project -- has been publishing its Top 10 lists since 2003. The original OWASP Top 10 (web application risks) became one of the most widely referenced documents in application security. The OWASP LLM Top 10 applies the same philosophy to large language model deployments.
The current top 10 (2025 edition) includes:
- Prompt Injection -- Malicious input overriding model instructions, either directly from users or indirectly via external content the model processes
- Sensitive Information Disclosure -- The model revealing private data from training, system prompts, or tool outputs
- Supply Chain Vulnerabilities -- Risks from third-party models, datasets, plugins, or fine-tuning pipelines
- Data and Model Poisoning -- Manipulation of training data or fine-tuning inputs to compromise model integrity
- Improper Output Handling -- Downstream systems trusting and acting on model output without validation
- Excessive Agency -- Giving the model too many permissions or too much autonomy relative to what the use case requires
- System Prompt Leakage -- The model revealing its own configuration or instructions when prompted
- Vector and Embedding Weaknesses -- Attacks against the retrieval components of RAG (retrieval-augmented generation) systems
- Misinformation -- The model confidently producing plausible but incorrect outputs that downstream users or systems rely on
- Unbounded Consumption -- Denial of wallet attacks, token flooding, and resource exhaustion
Where STRIDE-AI categorises and ATLAS documents attack paths, OWASP LLM Top 10 tells you where to focus first. It is prioritised by likelihood and impact, so it answers the practical question: given limited engineering time, where does this risk actually live and how critical is it?
How they layer together
The screenshot that prompted this post describes it as zoom levels, and that metaphor holds up well.
STRIDE-AI is the wide-angle view. You use it at the start of a threat model to make sure you have not missed an entire category of threat. It is fast, broad, and structured. It answers: what could go wrong?
ATLAS is the telephoto lens. Once STRIDE-AI has identified a threat, ATLAS tells you how an attacker would actually execute it -- the specific techniques, the real-world precedents, the tooling they would use. It answers: how exactly would someone do this?
OWASP LLM Top 10 is the framing. It helps you scope the work, prioritise the risks, and map each threat to the component of your system where it lives. It answers: where does this risk sit and how critical is it?
None of them alone gives you a complete picture. A threat model that only uses STRIDE-AI will identify threat categories but miss the specific techniques that make them exploitable. One that only uses ATLAS will have exhaustive attack paths but no prioritisation framework. One that only uses OWASP LLM Top 10 will know what the top risks are but lack the precision to threat-model the implementation.
Used together, they cover the full assessment cycle from initial scoping through to technical depth.
Why this matters now
Three years ago, most production AI systems were recommendation engines and classification models sitting inside consumer products. The threat model was relatively narrow: protect the training data, validate the API inputs, make sure the model's outputs were not being used to leak user data.
That is not the landscape anymore. AI systems are being deployed with tool access, memory, internet connectivity, and the ability to take actions in production environments -- booking meetings, writing code, sending emails, querying databases. An AI agent with a misconfigured set of permissions is not just a model that might say something wrong. It is an actor inside your environment that can do things.
The incidents that have dominated security news since July -- AI agents escaping sandboxes, models being weaponised for mass exploitation, autonomous attack frameworks targeting government infrastructure -- are all the result of this shift. The attack surface has changed fundamentally, and the frameworks we use to model threats need to reflect that.
STRIDE-AI, ATLAS, and OWASP LLM Top 10 do not solve the problem. But they give practitioners the vocabulary and structure to reason about it systematically rather than reactively. And in a field where the technology is moving faster than most organisations can track, having a structured way to ask the right questions is where good security starts.
If this was useful, follow for more.
Top comments (0)