Tous les articles

Référentiels

MITRE ATLAS : la carte des attaques sur l'IA que votre SOC ne sait pas encore lire

Publié le
Whondy Drouode

Whondy Drouode

Consultant GRC IA

MITRE ATLAS est la base de connaissances publique des attaques contre les systèmes d'IA, construite sur le modèle d'ATT&CK. Elle décrit ce qu'un attaquant cherche à obtenir, comment il s'y prend, et quels incidents réels le prouvent. Pour un SOC, c'est la grille qui manque entre « nous avons un chatbot » et « nous savons ce qu'il faut surveiller ».

La version publiée le 15 septembre 2026 compte 16 tactiques, 120 techniques, 88 sous-techniques, 40 mesures d'atténuation et 73 études de cas. Je vous montre ici comment la lire en vingt minutes, et surtout comment en tirer un plan de test au lieu d'un poster de plus.

ATLAS, c'est ATT&CK prolongé jusqu'au modèle

Votre équipe sécurité connaît déjà la logique. Sur les 16 tactiques d'ATLAS, 14 reprennent une tactique d'ATT&CK sous le même nom : reconnaissance, accès initial, exécution, persistance, exfiltration, impact. Un analyste qui sait lire une chaîne d'attaque classique, de la reconnaissance jusqu'à l'impact, lit donc déjà les trois quarts de la matrice sans formation supplémentaire.

Deux tactiques sont propres à l'IA, et ce sont elles qui changent la donne :

  • AI Model Access (AML.TA0000) : obtenir un accès au modèle, par son API, par le produit qui l'embarque, ou par son environnement physique ;
  • AI Attack Adaptation (AML.TA0001) : préparer l'attaque contre ce modèle précis, par exemple en entraînant un modèle de substitution pour tester des entrées piégées hors de vue.

Le lien avec ATT&CK est aussi fait au niveau le plus fin : 44 techniques d'ATLAS renvoient explicitement à leur équivalent ATT&CK. L'attaque contre une IA commence presque toujours par une attaque informatique ordinaire.

208
Techniques et sous-techniques recensées dans ATLAS v2026.09, dont 139 étiquetées « Agentic AI »

Lire la matrice : trois niveaux et deux filtres

La lecture se fait de haut en bas. La tactique dit le but de l'attaquant, la technique dit le moyen, la sous-technique précise la variante. Prenez LLM Prompt Injection (AML.T0051) : elle se décline en trois sous-techniques, directe, indirecte et déclenchée. Chacune appelle un test différent. Trois tests, pas un.

Deux champs de chaque fiche vous évitent de tout lire. Je m'en sers systématiquement pour trier :

  • la maturité : Realized (utilisée dans un incident réel, 101 entrées), Demonstrated (prouvée en recherche, 83 entrées) ou Feasible (théoriquement possible, 24 entrées) ;
  • la plateforme : Agentic AI (139 entrées), Generative AI (106), Enterprise (85) et Predictive AI (82). Une même technique peut porter plusieurs étiquettes.

Le poids des agents saute aux yeux. Deux entrées sur trois concernent désormais les systèmes qui appellent des outils, gardent une mémoire ou agissent seuls. ATLAS a suivi l'usage réel plus vite que la plupart des référentiels.

Pourquoi votre SOC ne sait pas encore la lire

Le problème n'est pas la matrice, c'est la télémétrie. Rien ne clignote. Une injection indirecte cachée dans un document indexé ne déclenche aucune alerte réseau. Quant à l'appel à l'outil qui exfiltre les données, c'est un appel légitime, authentifié, émis par votre propre agent avec les droits que vous lui avez donnés, donc invisible pour une règle qui cherche un intrus.

Trois techniques illustrent cet angle mort, toutes classées Realized ou Demonstrated :

  • RAG Poisoning (AML.T0070) : un contenu piégé placé dans la base documentaire que le modèle consulte ;
  • AI Agent Context Poisoning (AML.T0080) : une instruction glissée dans la mémoire de l'agent, qui survit à la session ;
  • Exfiltration via AI Agent Tool Invocation (AML.T0086) : l'agent envoie lui-même les données dehors, par un outil autorisé.

La méthode : d'ATLAS à un plan de test

Je ne commence jamais par la matrice. Jamais. Je commence par votre architecture, puis j'utilise ATLAS comme un filtre. L'objectif est une liste courte de scénarios, chacun relié à une mesure et à une règle de détection.

La démarche tient en cinq étapes :

1Inventorier les composantsModèle, base RAG, outils de l'agent, mémoire, interfaces exposées2Filtrer la matricePlateformes concernées, maturité Realized en premier3Écrire un scénario par techniqueEntrée piégée, comportement attendu, critère d'échec4Relier à une mesure AML.MCe qui doit bloquer l'attaque, et la preuve qu'il est en place5Vérifier la détectionLe SOC voit-il le test ? Sinon, la règle manque
Cinq étapes pour transformer la matrice en plan de test vérifiable.

Le résultat ? Une table de correspondance. Voici à quoi elle ressemble pour un exemple fictif, un assistant interne adossé à un RAG et à deux outils :

Technique ATLASStatutMesure attendue (ATLAS)
LLM Prompt Injection, indirecte (AML.T0051.001)PartielRestreindre l'invocation d'outils sur des données non fiables (AML.M0030)
RAG Poisoning (AML.T0070)À produireTraçabilité de la provenance des données (AML.M0025)
AI Agent Context Poisoning (AML.T0080)À produireDurcissement de la mémoire (AML.M0031)
Exfiltration via AI Agent Tool Invocation (AML.T0086)PartielValidation humaine des actions de l'agent (AML.M0029)
LLM Jailbreak (AML.T0054)CouvertGarde-fous de l'IA générative (AML.M0020)
Exemple de lecture : chaque ligne devient un test, et chaque statut « à produire » une action de la feuille de route.

Les deux premières colonnes viennent d'ATLAS, le statut vient du test. C'est exactement ce que je déroule dans un audit de sécurité et de conformité IA. Pour la défense contre l'injection elle-même, j'ai détaillé les contrôles qui tiennent dans cet article sur l'injection de prompt.

ATLAS, OWASP et l'AI Act : qui dit quoi

Ces référentiels ne se concurrencent pas, ils répondent à trois questions distinctes. L'OWASP LLM Top 10, dans sa version 2026, classe les faiblesses d'une application. ATLAS décrit le comportement de l'attaquant qui les exploite. L'AI Act fixe l'obligation qui vous oblige à prouver que vous y avez pensé.

L'article 15 de l'AI Act impose aux systèmes à haut risque des mesures contre l'empoisonnement des données, l'empoisonnement de modèle, les exemples adverses et les attaques contre la confidentialité. Pour les systèmes de l'Annexe III, ces obligations s'appliquent au 2 décembre 2027, après le report du Digital Omnibus. Rien ne presse au point de paniquer, mais un plan de test fondé sur ATLAS constitue déjà une preuve présentable.

Questions fréquentes

ATLAS remplace-t-il ATT&CK dans mon SOC ?

Non. Il le complète, et c'est tout son intérêt pour une équipe qui maîtrise déjà ATT&CK au quotidien. Les tactiques communes gardent les mêmes noms, et 44 techniques renvoient directement à ATT&CK. Vos règles de détection existantes restent valables, ATLAS vous montre ce qu'elles ne voient pas au niveau du modèle.

Faut-il tester les 208 techniques et sous-techniques ?

Non. Filtrez par plateforme, puis commencez par les entrées Realized, celles qui ont déjà servi dans un incident. Pour un assistant avec RAG et outils, je vise d'abord une quinzaine de scénarios, puis j'élargis si les premiers tests révèlent des failles.

À quelle fréquence la matrice change-t-elle ?

Souvent. MITRE a publié cinq versions entre fin mai et mi-septembre 2026. Datez votre plan de test avec la version utilisée, relisez les nouvelles études de cas à chaque revue, et ajoutez un scénario dès qu'une technique qui touche votre architecture passe au statut Realized. La chaîne d'approvisionnement y occupe une place croissante, comme le montrait déjà l'incident Hugging Face.

Cet article expose une méthode, il ne constitue pas un conseil juridique. Si vous voulez savoir quelles techniques ATLAS touchent réellement votre système, parlons-en trente minutes, ou consultez le détail de l'audit de sécurité et de conformité IA.

Partager

Où en êtes-vous, vous ?

Trente minutes pour situer votre exposition réelle et vos priorités. Sans engagement.