MITRE ATLAS : comprendre la matrice des menaces IA en 2026

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) est la base de connaissances publique et gratuite qui décrit, sous forme de matrice, comment des adversaires attaquent les systèmes d'intelligence artificielle : empoisonnement de données, extraction de modèle, injection de prompt, détournement d'agents et de leurs outils. Conçue par la MITRE Corporation sur le modèle de MITRE ATT&CK, elle fournit un vocabulaire commun aux équipes de sécurité, aux data scientists et aux auditeurs. En 2026, la matrice compte 16 tactiques et plus d'une centaine de techniques, avec une mise à jour mensuelle centrée sur l'IA générative et agentique. Ce guide explique sa structure, les techniques à surveiller en priorité, ses différences avec ATT&CK, l'OWASP Top 10 pour les LLM ou le guide de l'ANSSI, puis la manière de l'utiliser concrètement pour modéliser les menaces, cadrer un red teaming et alimenter la détection. Il complète notre guide pilier sur le red teaming IA, le jailbreak et l'injection de prompt.

MITRE ATLAS : définition, origine et périmètre du référentiel

Le sigle ATLAS signifie Adversarial Threat Landscape for Artificial-Intelligence Systems, soit le paysage des menaces adverses visant les systèmes d'intelligence artificielle. Le projet descend de l'Adversarial ML Threat Matrix, publiée en octobre 2020 par MITRE et Microsoft, puis rebaptisée ATLAS en 2021. Sa philosophie reprend celle d'ATT&CK : documenter ce que font réellement les attaquants, étape par étape, plutôt que dresser une liste abstraite de vulnérabilités.

Le périmètre s'est élargi avec le temps. Les premières versions traitaient surtout l'apprentissage automatique dit prédictif : classifieurs, détection de logiciels malveillants, reconnaissance faciale. À partir de 2023, les grands modèles de langage (LLM), les architectures de génération augmentée par récupération (RAG) puis, en 2025, les agents autonomes ont pris une place croissante. En 2026, la description officielle couvre aussi l'abus des capacités d'IA et les comportements autonomes nuisibles rendus possibles par l'IA.

Qu'on la cherche sous le nom « MITRE ATLAS » ou « atlas mitre », il s'agit de la même ressource, consultable gratuitement sur le site officiel atlas.mitre.org et distribuée sous forme de fichiers YAML et STIX dans le dépôt public mitre-atlas/atlas-data. Les données reposent sur des attaques observées en conditions réelles et sur des démonstrations réalistes menées par des équipes de red teaming IA et des chercheurs en sécurité.

Qui alimente la matrice ?

MITRE pilote ATLAS avec une communauté de contributeurs industriels. Le projet Secure AI du Center for Threat-Informed Defense, lancé en juin 2024 avec plus de quinze entreprises, a accéléré l'ajout de techniques liées à l'IA générative. En octobre 2024, MITRE a ouvert une initiative de partage d'incidents liés à l'IA qui permet de signaler, de manière anonymisée, des attaques ou accidents impliquant des systèmes d'IA.

Cette gouvernance communautaire explique la vitesse d'évolution de la matrice : chaque version mensuelle crédite des contributeurs, éditeurs de sécurité, grands groupes ou chercheurs, qui apportent une étude de cas ou une nouvelle technique. Pour une équipe de défense, c'est un atout, car les comportements réellement observés entrent vite dans le référentiel. C'est aussi une contrainte, car identifiants et intitulés doivent être revus régulièrement dans les outils internes.

Pourquoi les systèmes d'IA exigent un référentiel de menaces dédié

Un système d'IA hérite de toutes les faiblesses d'un système d'information classique, mais il ajoute des actifs que les contrôles traditionnels ne voient pas. Un antivirus ne détecte pas un jeu de données empoisonné, un pare-feu applicatif ne comprend pas une instruction cachée dans un document indexé, et un scanner de vulnérabilités ignore qu'un modèle peut révéler des données d'entraînement par simple interrogation.

L'Agence nationale de la sécurité des systèmes d'information (ANSSI) le souligne dans ses recommandations de sécurité pour un système d'IA générative, publiées en avril 2024 : l'intégration de ces outils crée des menaces nouvelles pour la confidentialité des données traitées et pour l'intégrité des systèmes auxquels ils sont connectés. Le guide couvre le cycle de vie complet, de la conception et de l'entraînement jusqu'à la production.

Les actifs propres à l'IA qu'un référentiel comme ATLAS aide à protéger sont les suivants :

• les jeux de données d'entraînement, d'ajustement fin (fine-tuning) et d'évaluation ;
• les poids et artefacts de modèle, y compris les fichiers téléchargés depuis des hubs publics ;
• l'API d'inférence, ses quotas et la richesse des réponses qu'elle renvoie ;
• le prompt système, l'historique de conversation et la mémoire persistante des assistants ;
• les index vectoriels et les sources documentaires d'une architecture de génération augmentée par récupération (RAG) ;
• les agents, leurs outils, leurs identifiants et les serveurs MCP (Model Context Protocol) qu'ils appellent.

Sans vocabulaire commun, chaque équipe décrit ces risques à sa manière : le data scientist parle de robustesse, le pentesteur de contournement, le juriste de fuite de données. ATLAS fournit une grille unique et des identifiants qui permettent de relier une hypothèse de menace, un test, une mesure de protection et une règle de détection, quelle que soit l'équipe qui les porte.

Structure de la matrice ATLAS : tactiques, techniques, mitigations et études de cas

La matrice MITRE ATLAS organise quatre types d'objets reliés entre eux. Les tactiques (identifiants AML.TAxxxx) décrivent l'objectif de l'attaquant, le « pourquoi ». Les techniques et sous-techniques (AML.Txxxx et AML.Txxxx.xxx) décrivent le « comment ». Les mitigations (AML.Mxxxx) indiquent les mesures qui réduisent l'efficacité d'une technique. Les études de cas (AML.CSxxxx) racontent des incidents ou exercices réels sous forme de chaînes de techniques.

Les 16 tactiques, de la reconnaissance à l'impact

Présentées dans l'ordre logique d'une attaque, les seize tactiques de la version de contenu 2026.09 sont les suivantes :

1. Reconnaissance (AML.TA0002) ;
2. Développement de ressources (AML.TA0003) ;
3. Accès initial (AML.TA0004) ;
4. Accès au modèle d'IA (AML.TA0000), tactique propre à l'IA ;
5. Exécution (AML.TA0005) ;
6. Persistance (AML.TA0006) ;
7. Élévation de privilèges (AML.TA0012) ;
8. Évasion des défenses (AML.TA0007) ;
9. Accès aux identifiants (AML.TA0013) ;
10. Découverte (AML.TA0008) ;
11. Mouvement latéral (AML.TA0015) ;
12. Collecte (AML.TA0009) ;
13. Adaptation de l'attaque IA (AML.TA0001), tactique propre à l'IA, anciennement « AI Attack Staging » ;
14. Commande et contrôle (AML.TA0014) ;
15. Exfiltration (AML.TA0010) ;
16. Impact (AML.TA0011).

Les tactiques adaptées d'ATT&CK y renvoient explicitement dans les données publiées ; la reconnaissance d'ATLAS pointe par exemple vers la tactique TA0043 d'ATT&CK. Les deux tactiques spécifiques sont l'accès au modèle, qui décrit le niveau d'accès obtenu (API d'inférence, poids complets, environnement physique des capteurs), et l'adaptation de l'attaque, qui regroupe la préparation hors ligne : modèle de substitution, données adverses, vérification de l'attaque.

Maturité, plateformes, mitigations et études de cas ATLAS

Au-delà des tactiques, la matrice ATLAS enrichit chaque technique de métadonnées qui servent directement à la priorisation, et la relie à des mesures de protection ainsi qu'à des attaques documentées. Ces quatre éléments transforment un simple catalogue en outil d'aide à la décision pour les équipes de sécurité qui doivent arbitrer entre des dizaines de scénarios possibles.

Maturité et plateformes des techniques

Depuis la version de données 5.0.0 de septembre 2025, chaque technique porte un niveau de maturité : faisable (démontrée en recherche), démontrée (efficace lors d'un exercice de red team sur un système réaliste) ou réalisée (employée par un acteur malveillant lors d'un incident réel). Ce champ aide à distinguer la menace théorique de la menace opérationnelle et à hiérarchiser les efforts de protection.

Depuis la version de contenu 2026.05, chaque technique est aussi rattachée à une ou plusieurs plateformes : IA prédictive, IA générative, IA agentique et entreprise. Un filtrage combinant plateforme et maturité constitue le moyen le plus rapide de réduire une matrice de plus de cent techniques aux quelques dizaines réellement pertinentes pour un système donné.

Mitigations et études de cas

Les mitigations décrivent des mesures techniques ou organisationnelles : limiter la diffusion d'informations sur la pile d'IA (AML.M0000), restreindre le volume de requêtes, vérifier l'intégrité cryptographique des artefacts (AML.M0014), journaliser la télémétrie IA (AML.M0024), segmenter les composants d'un agent ou exiger une validation humaine avant certaines actions. Elles ne s'accompagnent pas de procédures de test : c'est à l'organisation de définir comment prouver leur efficacité.

Les études de cas constituent la partie la plus pédagogique. Elles relatent des incidents ou exercices publics, comme le détournement de clusters Ray exposés (ShadowRay), l'exfiltration de données via Microsoft 365 Copilot par injection sans clic (EchoLeak) ou des attaques de la chaîne d'approvisionnement de modèles. Chaque étape est rattachée à une technique, ce qui fournit des scénarios prêts à rejouer en atelier de modélisation des menaces.

Les techniques MITRE ATLAS à surveiller en priorité en 2026

Toutes les techniques ne pèsent pas le même poids pour une entreprise qui consomme des modèles hébergés, construit un assistant de génération augmentée par récupération (RAG) ou déploie des agents. Les familles ci-dessous concentrent l'essentiel des scénarios rencontrés en audit et en red teaming de systèmes d'IA générative, avec leurs identifiants ATLAS pour faciliter le référencement dans les rapports et les outils.

Injection de prompt et jailbreak (AML.T0051, AML.T0054)

L'injection de prompt (AML.T0051) se décline en sous-techniques directe, indirecte et déclenchée. La variante indirecte est la plus préoccupante : une instruction cachée dans un courriel, une page web ou un document indexé devient un canal de commande dès que le modèle la lit. Le jailbreak (AML.T0054) vise plutôt à contourner l'alignement de sécurité du modèle, par exemple au moyen de suffixes adverses comme ceux décrits dans notre analyse de l'attaque GCG par suffixe adverse.

Empoisonnement et manipulation du modèle (AML.T0020, AML.T0018)

L'empoisonnement des données d'entraînement (AML.T0020, intitulé Training Data Poisoning depuis 2026) est classé au niveau de maturité « réalisé », donc observé lors d'incidents réels. La manipulation du modèle (AML.T0018) couvre l'insertion d'une porte dérobée dans les poids ou la modification de l'architecture. Ces techniques concernent surtout les organisations qui entraînent ou ajustent leurs propres modèles, ou qui récupèrent des modèles et jeux de données tiers sans contrôle d'intégrité.

Accès au modèle, évasion et extraction (AML.T0040, AML.T0015, AML.T0024)

L'accès à l'API d'inférence (AML.T0040) est souvent le point de départ des attaques contre l'IA prédictive. L'adversaire interroge le modèle pour entraîner une copie de substitution, fabrique hors ligne des entrées adverses qui trompent le modèle (évasion, AML.T0015), puis vérifie l'attaque avec quelques requêtes. L'exfiltration via l'API d'inférence (AML.T0024) regroupe l'inférence d'appartenance aux données d'entraînement, l'inversion et l'extraction du modèle.

Pour le défenseur, ces attaques laissent peu de traces visibles : une rafale de requêtes qui ressemble à un trafic légitime. C'est pourquoi la journalisation des appels d'inférence, avec identité, volume et distribution des entrées, constitue un prérequis à toute détection. La mitigation qui limite le volume et le débit des requêtes réduit le rendement d'une extraction sans l'empêcher totalement.

Agents IA et chaîne d'approvisionnement : les techniques en plus forte croissance

Les agents d'IA, capables d'appeler des outils, de lire des données et d'agir au nom d'un utilisateur, concentrent la majorité des techniques ajoutées à la matrice depuis 2025. La chaîne d'approvisionnement des modèles et des outils d'agents suit la même trajectoire. Ces deux familles méritent une attention particulière, car elles relient directement une manipulation du modèle à un impact concret sur le système d'information.

Invocation d'outils et empoisonnement du contexte (AML.T0053)

L'invocation d'outils d'agent (AML.T0053) décrit l'abus des capacités connectées à un agent : appels d'API, accès aux sources de données, exécution de code. Combinée à une injection indirecte, elle transforme un document piégé en action réelle. Les ajouts de 2025 et 2026 couvrent l'empoisonnement du contexte et de la mémoire d'un agent, la modification de sa configuration, l'empoisonnement des définitions d'outils et l'exfiltration par invocation d'outil. Notre guide sur le sandboxing et les guardrails des agents IA détaille les contre-mesures d'architecture.

Compromission de la chaîne d'approvisionnement IA (AML.T0010)

La compromission de la chaîne d'approvisionnement IA (AML.T0010) vise les bibliothèques, les registres de conteneurs, les hubs de modèles et désormais les outils d'agents. Les études de cas récentes décrivent des serveurs MCP (Model Context Protocol) piégés, des modèles malveillants publiés sur des plateformes publiques ou la réutilisation d'un espace de noms de modèle abandonné. La vérification des artefacts, la nomenclature IA (AI BOM) et le contrôle des dépendances deviennent des mesures de base.

MITRE ATLAS et MITRE ATT&CK : différences et complémentarité

MITRE ATT&CK décrit les comportements adverses sur les environnements d'entreprise, mobiles et industriels : postes, serveurs, annuaires, cloud. ATLAS reprend sa structure et ses conventions, mais se concentre sur ce qui est propre à l'IA. Les deux référentiels ne sont pas concurrents : une attaque réelle contre un assistant d'entreprise commence souvent par un vol d'identifiants ou un hameçonnage décrits dans ATT&CK, puis se poursuit par une injection de prompt décrite dans ATLAS.

Plusieurs techniques ATLAS sont d'ailleurs adaptées d'ATT&CK et en conservent la référence, ce qui facilite les correspondances. Depuis la version 2026.07, les publications de données incluent un fichier au format d'échange STIX combinant ATLAS et ATT&CK Enterprise, et l'outil ATLAS Navigator, dérivé d'ATT&CK Navigator, permet d'annoter la matrice comme une couche de couverture classique. Un centre opérationnel de sécurité peut donc gérer les deux référentiels dans les mêmes outils.

La différence majeure tient aux tactiques propres à l'IA et à la nature des preuves. Dans ATT&CK, une technique se détecte souvent par un artefact système : processus, clé de registre, connexion réseau. Dans ATLAS, le signal se trouve plutôt dans le contenu échangé avec le modèle, les métadonnées d'inférence ou l'intégrité d'un artefact. Cette différence impose d'étendre la télémétrie collectée, et pas seulement d'ajouter des règles de corrélation.

ATLAS, OWASP, NIST et ANSSI : quel référentiel pour quel usage ?

Les équipes confrontées à la sécurité de l'IA disposent de plusieurs référentiels complémentaires. Le Top 10 OWASP pour les grands modèles de langage (LLM) et l'IA générative, édition 2025, classe les risques applicatifs, de l'injection de prompt (LLM01) à la consommation non bornée (LLM10). Le rapport NIST AI 100-2 E2025, publié en mars 2025, propose une taxonomie et une terminologie de l'apprentissage automatique adverse.

Des correspondances indicatives aident à passer d'un référentiel à l'autre : LLM01 (injection de prompt) renvoie à AML.T0051, LLM04 (empoisonnement des données et du modèle) à AML.T0020 et AML.T0018, LLM03 (chaîne d'approvisionnement) à AML.T0010, LLM06 (agentivité excessive) à l'invocation d'outils d'agent, et LLM10 (consommation non bornée) au déni de service IA et à la récolte de coûts. Ces liens restent à valider dans chaque contexte d'usage.

Le guide de l'ANSSI, lui, se lit comme un ensemble de mesures d'architecture : cloisonnement, maîtrise des flux, journalisation, gestion des droits. Croisé avec ATLAS, il permet de répondre à une question simple pour chaque technique retenue : quelle recommandation réduit ce risque dans notre architecture, et comment le vérifier ? Ce croisement est particulièrement utile lors d'un dossier d'homologation.

Évolutions 2025-2026 : l'IA agentique au cœur de la matrice

La croissance de la matrice reflète la diffusion rapide des agents. En septembre 2025, une mise à jour réalisée avec l'éditeur Zenity a introduit l'empoisonnement du contexte d'agent (mémoire et fil de conversation), la collecte d'identifiants depuis la configuration d'agents ou des bases documentaires RAG et l'exfiltration par invocation d'outils. En novembre 2025, la version 5.1.0 a ajouté la tactique de mouvement latéral, des techniques liées aux deepfakes et six mitigations dédiées aux agents.

L'année 2026 a prolongé ce mouvement : empoisonnement d'outils d'agents et « rug pull » dans la chaîne d'approvisionnement, études de cas sur des serveurs MCP (Model Context Protocol) malveillants, récolte de coûts par consommation agentique. En août 2026, la tactique « AI Attack Staging » est devenue « AI Attack Adaptation » et des techniques autonomes sont apparues, comme la reconnaissance ou l'orchestration d'attaques par des agents. En septembre 2026, une mitigation consacrée aux leurres IA (AI Honeypots) a été ajoutée.

Le mode de publication a lui aussi changé. Depuis mai 2026, le contenu suit un versionnage mensuel de type AAAA.MM, distinct du format de données (désormais en version 6.0.0), et chaque technique est étiquetée par plateforme. En juin 2026, MITRE a publié un agent conversationnel open source pour explorer la base de connaissances. Pour une équipe de sécurité, ces évolutions imposent une veille mensuelle et une gestion de version des correspondances internes.

Modéliser les menaces d'un système d'IA avec MITRE ATLAS

La modélisation des menaces est l'usage le plus rentable de la matrice. Elle consiste à partir d'une architecture concrète, à identifier les techniques plausibles, puis à vérifier pour chacune l'existence d'une protection et d'une détection. Le processus ci-dessous, applicable à un assistant de génération augmentée par récupération (RAG) comme à un agent métier, s'intègre dans une analyse de risques EBIOS Risk Manager existante, au niveau des scénarios opérationnels.

Pour les modèles déployés en interne, l'inventaire doit inclure l'infrastructure de service (serveurs d'inférence, orchestrateurs, stockage des poids), souvent négligée au profit du seul prompt. La méthodologie décrite dans notre article sur le red teaming de LLM on-premise montre comment intégrer ces composants dans le périmètre d'évaluation et dans la cartographie initiale.

Cadrer un red teaming IA à partir de la matrice ATLAS

ATLAS sert de langage commun entre le commanditaire et l'équipe de test. Le périmètre d'un red teaming IA peut être exprimé en tactiques et techniques visées, la maturité aide à justifier les priorités, et les études de cas fournissent des scénarios réalistes. En fin de mission, chaque constat référencé par un identifiant AML.T peut être relié à une mitigation et suivi dans le temps, ce qui rend les campagnes successives comparables.

MITRE publie également Arsenal, une extension de la plateforme d'émulation d'adversaires CALDERA dédiée aux systèmes intégrant de l'IA, ainsi que des outils de navigation dans la matrice. Pour structurer une campagne complète sur des modèles de langage, notre guide Red Teaming IA 2026 : tester les LLM en entreprise détaille les étapes, et l'article consacré au red teaming de la cyberdéfense agentique traite des systèmes multi-agents.

Retour terrain : Cas typique rencontré en mission — un commanditaire demande de « tester l'assistant IA » sans autre précision. Projeter l'architecture sur ATLAS montre que le risque principal est l'injection indirecte via la base documentaire RAG, alimentée par des contributeurs externes, bien avant l'extraction du modèle. Les scénarios sont priorisés en conséquence, et la restitution au comité de direction relie chaque constat à sa technique ATLAS, à son impact métier et à sa mitigation.

Détection et réponse : intégrer ATLAS dans le SOC

La mitigation de journalisation de la télémétrie IA (AML.M0024) est la condition de toute détection. Sans journalisation des prompts, du contexte assemblé, des réponses et des appels d'outils, la plupart des techniques ATLAS restent invisibles pour le centre opérationnel de sécurité (SOC). Les journaux doivent associer chaque requête à une identité, à un horodatage et à la version du modèle, tout en respectant les règles de protection des données personnelles.

Une fois cette télémétrie disponible, plusieurs signaux exploitables se rattachent directement à des techniques ATLAS :

• volume ou distribution anormale de requêtes d'inférence par identité, indice d'extraction de modèle ou de préparation d'attaque ;
• contenu de type instruction dans un document récupéré par la chaîne de génération augmentée par récupération (RAG), suivi d'un appel d'outil dans la même session ;
• appel d'outil d'agent inhabituel par sa destination, sa fréquence ou ses paramètres ;
• modification de la configuration ou de la mémoire d'un agent hors processus de changement ;
• empreinte cryptographique d'un modèle ou d'un jeu de données différente de la valeur enregistrée.

Le référentiel peut aussi servir de colonne vertébrale à un registre de couverture. L'exemple suivant, volontairement simple, charge la dernière version des données ATLAS, affiche les volumes publiés et relie quelques techniques retenues à une mitigation, à un contrôle et à une détection. Les champs du registre sont propres à l'organisation ; seuls les identifiants proviennent d'ATLAS.

import yaml

with open("atlas-data/dist/ATLAS-latest.yaml", encoding="utf-8") as f:
    atlas = yaml.safe_load(f)

print("Version ATLAS :", atlas["collection"]["version"])
for cle in ("tactics", "techniques", "mitigations", "case-studies"):
    print(cle, len(atlas.get(cle, {})))

registre = {
    "AML.T0051": {"mitigation": "AML.M0020", "controle": "filtrage du contexte RAG",
                  "detection": "instruction dans un document suivie d'un appel d'outil"},
    "AML.T0053": {"mitigation": "AML.M0029", "controle": "validation humaine des actions sensibles",
                  "detection": "appel d'outil vers une destination non autorisée"},
    "AML.T0024": {"mitigation": "AML.M0024", "controle": "quotas par identité",
                  "detection": "rafale de requêtes d'inférence"},
}

for tid, entree in registre.items():
    nom = atlas["techniques"].get(tid, {}).get("name", "absent : vérifier les renommages")
    print(tid, nom, "->", entree["detection"])

Côté réponse à incident, l'identifiant ATLAS facilite la qualification : un analyste qui rattache une alerte à AML.T0051.001 (injection indirecte) sait immédiatement quelles études de cas consulter, quelles mitigations vérifier et quelles données conserver, notamment le contexte complet transmis au modèle. Sans ce contexte, il est presque impossible de prouver a posteriori qu'une action d'agent résulte d'une instruction injectée.

Gouvernance et conformité : ce qu'ATLAS apporte et ce qu'il n'apporte pas

MITRE ATLAS n'est ni une norme ni un référentiel d'exigences. Il ne contient pas de procédure d'évaluation, et un auditeur ne peut pas y cocher « conforme » ou « non conforme ». En revanche, il constitue une excellente source pour documenter l'analyse de menaces exigée par les cadres de gouvernance, comme un système de management de l'IA selon ISO/IEC 42001 ou une analyse de risques EBIOS RM.

Le règlement européen sur l'intelligence artificielle (AI Act, règlement (UE) 2024/1689) impose aux systèmes à haut risque, dans son article 15, un niveau approprié d'exactitude, de robustesse et de cybersécurité, avec des mesures contre l'empoisonnement des données ou du modèle, les exemples adverses et les attaques contre la confidentialité. Le texte dit « omnibus numérique » adopté en 2026 a reporté au 2 décembre 2027 l'application des obligations visant les systèmes de l'annexe III.

Dans ce contexte, ATLAS joue le rôle de dictionnaire des menaces : il permet de démontrer que l'analyse a considéré les attaques connues, référencées et datées. Il doit être complété par des exigences mesurables issues des normes, des recommandations de l'ANSSI et des politiques internes, ainsi que par des preuves de tests. Citer ATLAS dans une documentation de conformité ne remplace jamais la preuve que les mesures fonctionnent.

Limites de MITRE ATLAS et erreurs fréquentes

La première limite tient à la nature du référentiel : il décrit des comportements adverses connus et publiés. Les attaques inédites ou propres à une architecture particulière n'y figurent pas encore, et la classification des techniques récentes peut évoluer. La seconde tient au rythme : avec des versions mensuelles et des renommages fréquents, les correspondances internes vieillissent vite si personne n'en assume la responsabilité.

Les erreurs les plus fréquentes lors de l'adoption de la matrice sont les suivantes :

• traiter ATLAS comme une liste de contrôle d'audit au lieu d'un catalogue de menaces ;
• vouloir couvrir toutes les techniques sans filtrer par plateforme ni par maturité ;
• oublier la partie « système d'information classique » de l'attaque, décrite dans ATT&CK ;
• conserver des identifiants ou des intitulés obsolètes après une nouvelle version ;
• compter uniquement sur les garde-fous du modèle, sans journalisation ni limitation des droits des agents.

Pour les agents autonomes, une dernière limite mérite attention : la matrice décrit les techniques, mais pas l'architecture de confiance à mettre en place entre un agent, ses outils et les données qu'il manipule. Cette conception relève de l'ingénierie de sécurité, que nous abordons dans notre méthodologie de red teaming des agents autonomes.

Retour terrain : Cas typique rencontré en mission — la cartographie ATLAS est réalisée par l'équipe sécurité seule, sur le modèle principal, sans les équipes data. Elle ignore alors les API de modèles tiers, les connecteurs et les agents déployés par les métiers, où se concentre pourtant l'exposition. La correction consiste à partir d'un inventaire des systèmes d'IA, puis à associer chaque technique retenue à un propriétaire et à un test ou une détection vérifiable.

À lire aussi : la sécurité de l'index vectoriel HNSW ; les risques de la fusion de modèles (SLERP).

Questions fréquentes

Conclusion

MITRE ATLAS s'est imposé comme le langage de référence pour décrire les attaques contre l'IA. Sa force tient à sa structure héritée d'ATT&CK, à ses identifiants stables et à ses études de cas tirées d'incidents réels. Sa croissance rapide en 2025 et 2026, portée par l'IA agentique, en fait un outil vivant qui exige une veille mensuelle et une appropriation par les équipes de sécurité comme par les équipes data.

Pour en tirer parti, partez d'une cartographie précise de vos systèmes d'IA, filtrez la matrice par plateforme et par maturité, construisez quelques scénarios réalistes, testez-les dans un cadre autorisé et vérifiez que chaque technique retenue dispose d'une détection. Pour approfondir les tests offensifs encadrés, consultez notre dossier complet sur le red teaming IA, le jailbreak et l'injection de prompt.