What does mapping an LLM risk onto MITRE ATLAS add beyond the OWASP list?

## Two artifacts, two questions Teams often treat the OWASP GenAI lists and MITRE ATLAS as competing taxonomies and pick one. They are complements, and the difference is in the question each answers. The OWASP GenAI LLM Top 10 and the Top 10 for Agentic Applications are **builder-facing checklists of weakness classes**. They are organised by what can be wrong with your system: injection, disclosure, excessive agency, memory flaws, insecure inter-agent messaging. Their natural use is a design-time pass over a data-flow map, producing findings with owners. MITRE ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems — is an **adversary-facing knowledge base**. It is deliberately shaped like ATT&CK: tactic columns representing adversary goals (reconnaissance, resource development, initial access, model access, execution, persistence, defense evasion, discovery, collection, exfiltration, impact, and AI-specific staging tactics), populated with techniques carrying identifiers in the AML namespace, and backed by documented real-world case studies. Its natural use is describing what an attacker did or would do, step by ordered step. ## What the mapping actually buys **A shared register.** Most organisations already run a risk and detection function keyed on ATT&CK. An AI risk expressed only as "LLM01" has no home there; the same risk expressed as a tactic-and-technique chain slots into the existing process. This is unglamorous and it is the main reason to bother: AI risk that lives in its own spreadsheet gets reviewed on its own cadence by its own people and is invisible during a real incident. **Detection requirements rather than abstractions.** A checklist entry says a weakness class exists. A technique describes an action, and actions imply telemetry. Asking "what would we see if this technique were used against us?" converts the map into concrete logging: which prompts and retrieved spans entered context, which tools were invoked with which arguments under which identity, what left the network. That question is much harder to answer from a vulnerability-class list. **A chain, not a point.** ATLAS puts techniques in ordered tactics, so a scenario reads as a sequence: an adversary places instructions in a supplier-uploaded document, the document is ingested and retrieved, the model acts on it, a tool call escalates, data or consequence follows. Mapping a plant copilot's shutdown-scheduling path this way exposes intermediate stages where detection or a boundary can be inserted — stages a single OWASP category flattens into one line. **A common language across functions.** Security leadership, threat intel and incident response already speak this dialect. Presenting an AI risk in it removes the argument about whether AI risk is a special case, which is a real organisational obstacle when a new product needs sign-off. ## What it does not buy ATLAS is descriptive. It tells you what adversaries do; it does not tell you what to build, and it will not order your work. Prioritisation still comes from your own consequence ranking — which sinks are irreversible, which paths reach them after consuming untrusted content. A team that maps thoroughly and then implements nothing has produced a document, not a defense. It also does not replace the OWASP pass. The checklists catch design omissions that an adversary-behaviour catalogue will not prompt you to notice, because a weakness with no known technique in the catalogue is still a weakness. Notably, the OWASP agentic list ships with mappings to ATLAS and to NIST material, which is the clearest signal that the maintainers see them as layered rather than alternative. ## Doing the mapping without wasting a week Map the paths that matter, not everything. Take the two or three highest-consequence flows from your risk ranking and write each as an ordered scenario in tactic terms. For each stage record: what the adversary needs, what telemetry you have or lack, and whether a deterministic boundary exists there. The output is a short table per scenario, and its value is in the gaps it makes visible — a stage with no telemetry and no boundary is exactly the finding you want surfaced. Resist two failure modes. The first is completionism: mapping every technique in the catalogue against your system produces a large artifact nobody reads. The second is vocabulary theatre: relabelling existing findings with technique identifiers without changing any logging, detection or control. If nothing downstream changes because of the mapping, the mapping did not need to exist. ## Where it lands with an interviewer This is a differentiator question rather than a screener. What it tests is whether you have integrated AI risk into an existing security programme or run it as a side channel. The strong answer names the ATT&CK lineage, is precise about ATLAS being adversary-behaviour rather than a control set, and gives one concrete example of a detection requirement the mapping produced.