MITRE ATLAS
ATLAS describes what an adversary does to poison training data, copy the model, get around its guardrails and make the system hand over what it should not. It is the vocabulary missing from most AI security assessments sold today, which end in a report about the web application that serves the model.
MITRE ATLAS is the knowledge base that describes attacks aimed at artificial intelligence systems, maintained by MITRE. DM11 assesses your AI systems against the techniques in the catalogue, tests the model and the data pipeline alongside the application that exposes them, and delivers the result with proof of what was actually possible. Where the goal also includes a document to send a customer or a regulator, the route is ISO/IEC 42001 certification, and the evidence produced here carries into that project intact.
Who runs the assessment
CEH, Certified Ethical Hacker from EC-Council
SYCP and SYES, offensive certifications from Solyd
CISA, information systems auditing
17 years of governance, risk and compliance
WHAT IT IS
ATLAS stands for Adversarial Threat Landscape for AI Systems, the openly maintained MITRE knowledge base of adversary behaviour against artificial intelligence. It reuses the structure of MITRE ATT&CK, the catalogue of adversary tactics and techniques the same organisation maintains for enterprise systems, and applies it to what ATT&CK leaves out: the model, the data that trained it, and the pipeline connecting the two. In the June 2026 distribution there are 16 tactics, 103 top-level techniques plus a further 70 sub-techniques, 35 mitigations and 63 case studies.
Poisoning training data so the model learns the wrong thing on purpose. Publishing an already contaminated dataset or model for someone else to download. Extracting the model through repeated queries until a usable copy has been rebuilt. Inferring whether a specific record was in the training set, which in a health or credit dataset is a personal data leak with no file ever leaving. Manipulating the input until the model classifies wrongly, which is how a detector is bypassed. None of these show up in an infrastructure test, because none of them depend on an infrastructure flaw.
Alongside the tactics inherited from ATT&CK, ATLAS has two of its own: AI model access and AI attack staging. The first recognises that the degree of access changes everything, ranging from knowing only the application to holding the model file, with query access in between, which is where most cases sit. The second describes the work an adversary does before attacking, such as training an approximate model to rehearse against and arriving at the target with the attack already calibrated. That rehearsal is invisible to anyone watching only the application traffic.
There are 63 of them, and that is what separates ATLAS from a list of imagined threats. Documented there, with the target and who carried it out, are cases of evading machine learning malware detectors, poisoning a public chatbot, replicating a language model through queries, indirect instruction injection into a corporate assistant with access to email and documents, bypassing video identity verification with synthetic footage, and extracting a model embedded in a mobile app. The catalogue is updated on a near-monthly cadence, which makes it closer to a threat bulletin than to a standard.
Worth settling the expectation early, because it shapes the plan. What the assessment produces is a coverage map, technique by technique, stating what was attempted, what worked, and with what evidence. MITRE publishes the catalogue and accredits no assessor, so there is no ATLAS seal to issue and no body to check yours. Where your customer or your regulator needs a document signed by a third party, ISO/IEC 42001 certification is what answers that, and the result of this assessment goes in as the technical evidence the auditor will ask for.
WHO USUALLY NEEDS IT
All three arrive the same way: there is AI in production, some security testing has been done, and nobody can say whether the model itself has ever been tested at all.
The company commissioned a penetration test on the AI application and received a competent report on authentication, sessions, permissions and server configuration. None of that answers whether the model can be extracted through queries, whether the next training cycle can be poisoned, or whether the system can be made to reveal the instruction governing it. Different questions, different method, and almost no standard pentest scope includes them.
The assistant stopped merely answering and started querying the internal knowledge base, opening tickets, reading inboxes and taking action in systems. From that point on, an instruction hidden in a document a third party sent becomes an execution path, and content entering the model's context carries the same security weight as user input. It is the fastest-growing category of incident in ATLAS's own case studies.
The ISO/IEC 42001 project moved forward, or the NIST AI RMF, the AI risk management framework from the American standards institute, was adopted as the method, and the time came to say which concrete threats each system faces. Without a catalogue of techniques behind it, that part becomes a spreadsheet of generic risks nobody can test or close. ATLAS is the list that turns a declared risk into a verifiable threat.
STORIES
We change our clients' names with the same confidentiality that will protect your company later. The names change; the pattern of the problems repeats. Where a client agrees, we give named references in a conversation.
Private healthcare
An internal assistant answered the service team's questions by consulting the insurer's document base, and that base received files uploaded by external providers. The security test carried out six months earlier had covered the portal, authentication and infrastructure, and came back clean. Nobody had looked at what happens when the text inside a document reaches the model.
We reproduced the ATLAS indirect instruction injection technique: inside an ordinary document we placed a passage addressed to the model rather than to the human reader. Then we followed the path to the end, testing what the assistant could retrieve and return from there, and where the answer left the company.
The assistant followed the hidden instruction and pulled passages from other providers' documents into the same conversation. The whole fix landed outside the server: separating third-party content from trusted content, restricting what the assistant may retrieve per session, and logging every retrieval so the next attempt leaves a trail.
Technology and software
A software company exposed, inside its product, a classification model trained on years of proprietary data. It was the main asset of the business. Access was authenticated and metered, and the perception was that this sufficed, because every query had an owner and there was a per-minute request limit.
We applied the ATLAS model extraction technique from a legitimate customer account: queries built to maximise information per call, within the contracted limit, over a period of days. We trained an approximate model on the answers and measured how far it agreed with the original.
The approximate model reproduced the original's decision in most cases, with a query volume that fitted comfortably inside the contracted plan. The per-minute limit was never touched, because this attack works through patience and needs no volume. The defence moved to watching query patterns over time, and the board began treating the model as intellectual property with access control rather than as a product feature.
Telecommunications
A ticket prioritisation model was periodically retrained on case history, including free text written by whoever opened the ticket and the category the customer selected. The cycle was automatic and nobody reviewed what went in. The company's entire AI security conversation was concentrated on the application serving the model.
We mapped the data pipeline from the entry point to training and tested poisoning at source, with a small volume of records built to shift the model's decision in one specific band. We then measured the effect in a test environment, using the same retraining procedure that runs in production.
A small fraction of the cycle's records was already enough to change the priority of an entire ticket category, and nothing in that process raised an alert. In came validation and an influence cap per source, sampled review of what enters training, and a comparison of the new model against the previous one before release, which became the step that holds the cycle when something shifts.
HOW WE RUN IT
The assessment is worth what it can demonstrate. An ATLAS technique here is marked attempted, successful or not applicable, with the evidence attached and the path reproducible, because looking insecure and being demonstrably insecure lead to different investment decisions.
We establish which AI systems exist, official and unofficial, what each of them decides or automates, where the data that trains them or feeds their answers comes from, and what they can reach once they have answered. Without that picture, any test becomes an exercise about the screen.
An inventory of AI systems and use cases, with an owner per item
The origin of training data and of content retrieved in production
Tools, integrations and permissions the model can invoke
The degree of access available for testing, agreed with the board
Delivery milestoneThe pipeline drawn from source data through to the action the system takes.
Not every technique in the catalogue makes sense for every design, and testing all of them is the most expensive way to find that out. We select the techniques relevant to your type of model, your exposure and the access a realistic adversary would have, and put the list to you for approval before anything is executed.
Threat modelling per system, mapped to the ATLAS tactics
The list of selected techniques, with reasons for inclusion and exclusion
Rules of engagement, execution window and stop criteria
Formal authorisation, including what the model provider's contract permits
Delivery milestoneScope approved, with every selected technique traced to its catalogue identifier.
We test the model, the content that reaches it, the point where training data enters and the tools it invokes, alongside the application and the infrastructure around it. This is the stage where the difference between this work and an application test shows in full.
Attempts at evasion, extraction, inference about the training set and guardrail bypass
Instruction injection through third-party content, through to the action the model takes
Poisoning tested at the data entry point, in a controlled environment
Reproducible proof for every successful technique
Delivery milestoneEvery technique executed with its result recorded and its path reproducible.
The technical map on its own does not carry an investment decision. We link each finding to the matching mitigation in the catalogue and to the governance control your company already uses, so the subject reaches the board in the vocabulary it follows. Once the fixes are in, we repeat the same techniques with the same method.
Findings linked to the ATLAS mitigations and to ISO/IEC 42001 controls
An executive report in business language, with risk and effort kept separate
A remediation plan with an owner and a date per finding
A retest of the successful techniques, comparable to the initial run
Delivery milestoneFixes demonstrated by repeating the techniques that had worked.
HOW LONG IT TAKES
We do not publish a standard timeline, because a published timeline turns into a promise. The inventory is usually the short part where somebody already knows what exists, and the long part where nobody does. These are the three factors that move the clock most, and the first conversation already shows which one your company is in.
A company with an inventory of AI uses starts threat modelling in the first week. A company without one spends the start discovering what is already in production, and that discovery almost always includes uses the technology function never approved.
Testing through the application alone, as an outsider would, is faster and sees less. Access to the model, to the training set and to the release pipeline covers the poisoning and supply chain techniques, which are the most expensive ones to discover later. That is a scope and budget decision, and it is taken with you before anything starts.
With your own model, almost the whole catalogue applies. With a third-party model consumed through an application programming interface, much of the test concentrates on the context, the tools and the guardrails you control, and what can be tested on the model itself depends on what the provider's contract allows. Reading that contract starts early, because it tends to be the slowest part.
FREQUENTLY ASKED
The questions that come up in almost every first meeting, answered straight.
No. MITRE publishes and maintains the catalogue in the open, and accredits no assessor and issues no seal, to any company. Anyone offering an ATLAS certificate is selling something else. What exists is the assessment report, with the coverage map per technique and the evidence behind it, and it is accepted as technical evidence inside an ISO/IEC 42001 project, which is the AI standard that yields a certificate issued by a third party.
We start with an inventory of what is already in production and a selection of the ATLAS techniques that make sense for your design. The result is a map of what was attempted, what worked and what to do first, in the language the board follows.