MITRE ATLAS for LLM Deployments: A Threat Model Banks Can Actually Use
MITRE ATLAS gives bank security teams a named, examiner-recognizable framework for AI threat modeling — not another ad-hoc checklist, but the same tactics/techniques structure ATT&CK already uses, extended to LLM-specific attacks.
- Zeeshan SiddiquiEnterprise Architect: AI Platforms
In this article
Most bank security teams already run MITRE ATT&CK against their traditional infrastructure. It is the shared vocabulary examiners expect, the reference a SOC analyst points to when explaining why a control exists, and the taxonomy vendors map their products against in every RFP response. When banks start deploying large language models, the instinct is to treat AI security as a brand-new discipline requiring brand-new language. It isn't, entirely. MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) extends the same tactics-and-techniques structure ATT&CK uses to attacks that specifically target AI systems. That matters less for the novelty of the content and more for what it gives a security team politically and operationally: a shared, third-party-maintained vocabulary instead of an internally invented list that an examiner has never seen before and has no way to independently verify.
What MITRE ATLAS actually is
ATLAS is a publicly documented knowledge base, maintained by MITRE with contributions from industry, structured exactly like ATT&CK: adversary tactics and techniques. A tactic is the attacker's goal at a given stage of an operation — reconnaissance, initial access, ML model access, execution, exfiltration, impact. A technique is the specific method used to accomplish that goal at that stage. Reconnaissance might be achieved by scraping public model documentation or probing an API with crafted queries. Initial access might be achieved through prompt injection, embedded in a document a user uploads to the assistant. ML model access might be achieved through a jailbreak that gets the model to ignore its system-level constraints. Exfiltration might involve coaxing the model into repeating training data, system prompts, or content it retrieved from a permissioned data store. Impact is what happens when the attack succeeds — fraudulent transactions authorized, disinformation generated under the bank's name, sensitive data breached.
That structure is worth distinguishing from what we covered in The 6 Attack Classes Every Enterprise LLM Faces. That post is Sphere's own practical categorization — a way to organize a conversation with an engineering team about what can go wrong with an LLM deployment, built for clarity and speed. ATLAS is not a replacement for that; it's a different kind of artifact. It's the industry-standard reference framework a bank can point to in an exam, a vendor questionnaire, or a board risk report, because it isn't something Sphere or any other vendor invented — it's maintained independently, versioned publicly, and cross-referenced against ATT&CK itself. The two are complementary: the 6 attack classes post gets your team talking the same language internally; ATLAS gets you talking the same language externally, with examiners and auditors who may already know the framework by name.
Mapping a bank's LLM deployment to ATLAS tactics
The practical value of ATLAS shows up when you walk a real deployment through its tactic stages and ask, for each one, what a Sphere control actually does about it. That mapping looks like this:
| ATLAS tactic | What it means for a bank's LLM | Sphere control that addresses it |
|---|---|---|
| Reconnaissance | An adversary probes the deployed assistant with varied queries to learn its system prompt, guardrail boundaries, and underlying model behavior before attempting anything more direct. | Rate limiting and anomaly detection on query patterns — flagging the systematic, exploratory querying that precedes a targeted attack, rather than treating each query in isolation. |
| Initial access (Prompt Injection) | Malicious instructions arrive embedded in a document, email, or webpage the model processes — not typed by the user at all. We cover this attack path in depth in Indirect Prompt Injection: The Document That Attacks Your Assistant. | Deterministic input scanning that inspects and sanitizes retrieved content before it ever reaches the model's context window, rather than relying on the model to recognize an embedded instruction as untrustworthy. |
| ML Model Access (Jailbreak) | An adversary crafts a prompt designed to make the model bypass its own trained-in constraints and act outside its intended role. We go deep on this failure mode in Jailbreak Defense That Survives the Next Clever Prompt. | Layered guardrails that sit outside the model itself, so a successful jailbreak of the model's own alignment still has to pass an independent policy check before any action is taken or any output is returned. |
| Exfiltration | The model is manipulated into revealing training data, its own system prompt, or sensitive content it retrieved on the user's behalf — data the user asking the question was never supposed to see. | Output scanning paired with permission-aware retrieval, so the retrieval layer never fetches data the requesting user isn't entitled to in the first place, and outputs are checked before they leave the system. |
| Impact | The attack achieves its actual goal: a fraudulent transaction gets authorized, disinformation is generated under the bank's name, or regulated customer data is breached. | A full, tamper-evident audit ledger that lets the incident response team reconstruct exactly what the model saw, decided, and returned, at every step, after the fact. |
ATLAS doesn't replace red-teaming — it gives red-teaming a structured checklist instead of ad-hoc creativity. See Red-Teaming Your Own AI: An Enterprise Playbook for how to run that exercise. Without a framework, a red team tests whatever the tester happened to think of that week. With ATLAS, a red team works through a documented list of tactics and techniques, tests for each one methodically, and can show an examiner exactly which parts of the taxonomy were covered — and which weren't, yet.
Why examiners respond to a named framework
There's a real, practical difference between telling an examiner "we do AI security stuff" and telling them "we test our LLM deployment against MITRE ATLAS tactics, and here is our current coverage." The first is a claim the examiner has to take on faith, evaluated against nothing. The second is independently documented, maintained by a third party with no commercial stake in the bank's vendor choices, and versioned publicly — an examiner can go look at the ATLAS matrix themselves and check your mapping against it. It also plugs directly into security programs banks already run. Most regulated institutions have spent years building ATT&CK-based threat modeling into their traditional cyber programs, complete with coverage matrices, control mappings, and reporting templates. Because ATLAS mirrors that same tactics-and-techniques structure, a bank's existing threat-modeling machinery extends to AI systems rather than requiring a parallel process built from scratch. That's not a small thing for a risk team that's already stretched across a growing list of frameworks — it's one more row in a spreadsheet they already know how to fill out, not a new discipline to stand up.
Where ATLAS falls short for a regulated deployment
It's worth being direct about what ATLAS is not. ATLAS is a threat taxonomy, not a compliance framework. It tells you what attacks against AI systems look like and how they're typically executed — it says nothing about what a regulator requires you to document, how you should govern a model's lifecycle, or what your board needs to sign off on before a deployment goes live. That's the territory covered by SR 11-7's model risk management expectations, or by the EU AI Act's obligations for high-risk systems, and neither of those is a substitute for the other. Mapping your deployment against ATLAS is a strong input into a model risk management program; it isn't the program itself.
ATLAS is also, by design, generic across AI system types. Its tactics and techniques were built to describe attacks against machine learning systems broadly — computer vision models, recommendation engines, and LLMs all show up in its technique library. That breadth is exactly what makes it durable and industry-recognized, but it also means ATLAS alone won't tell you anything about how permissioned retrieval should work in a core banking data environment, or what a compliant audit trail needs to capture under your specific regulator's expectations. It needs to be paired with domain-specific controls built for banking, not treated as a complete answer on its own.
Frequently asked questions
MITRE ATLAS won't do the threat modeling for you, and it isn't a checkbox you tick once and forget. What it gives a bank's security and risk team is a shared, examiner-recognizable vocabulary for a category of risk that used to get described in ad-hoc, vendor-specific terms — and a structure disciplined enough to make sure red-teaming, control design, and audit evidence are all pointed at the same set of adversary tactics. If you're building out that threat model for a real deployment, our team can walk through the mapping with you. Talk to a Sphere AI Engineer.