La taxonomie d'injection de prompt de CrowdStrike dépasse 200 techniques
Le 7 juillet 2026, CrowdStrike a ajouté 18 entrées à sa taxonomie d'injection de prompt — désormais plus de 200 techniques. Cinq nouvelles classes montrent comment les attaques se cachent dans des déclencheurs différés, des jetons de contrôle falsifiés et des données de contexte de confiance.
De quoi s’agit-il ?
Le 7 juillet 2026, l’équipe de recherche en sécurité IA de CrowdStrike a publié une mise à jour de ce qu’elle présente comme la plus grande taxonomie d’injection de prompt du secteur. Cette mise à jour ajoute 18 nouvelles entrées, portant le catalogue à plus de 200 techniques distinctes, et le billet en détaille cinq. Il s’agit d’un artefact défensif, non d’une publication d’attaque : un vocabulaire commun qui permet aux équipes red team, aux ingénieurs de détection et aux responsables de modélisation des menaces de décrire le comportement réel des attaques par injection, au lieu de tout réduire à l’étiquette « injection de prompt ».
Ce cadrage est important, car la surface d’attaque s’est déplacée. À mesure que les déploiements passent des chatbots aux agents capables de parcourir des pages web, de lire des systèmes de fichiers, d’interroger des bases de données et d’écrire des commandes shell, l’injection indirecte — des instructions malveillantes dissimulées dans les données consommées par un agent — est devenue la préoccupation dominante. Les cinq nouvelles classes valent moins par la nouveauté d’un procédé isolé que par la systématisation de schémas d’évasion que les défenseurs observent régulièrement. Cet article résume la taxonomie publique ; il ne reproduit aucun payload exploitable.
Comment ça fonctionne
Les cinq techniques mises en avant visent chacune une hypothèse différente que le modèle formule sur son entrée.
L’ajout de règle activé par déclencheur dépose une instruction qui reste dormante jusqu’à ce qu’un mot-clé, un événement ou une condition survienne. À la relecture, le texte injecté paraît inerte — c’est précisément l’objectif : le comportement malveillant ne se manifeste qu’une fois le déclencheur présent, ce qui déjoue l’inspection ponctuelle.
La suppression de jetons cognitifs n’impose pas directement l’obéissance. Elle décourage plutôt le modèle de produire les jetons associés au refus — formules d’excuse, langage de politique, mises en garde de sécurité — orientant ses choix linguistiques loin des schémas de refus établis, vers des sorties plus risquées.
La décomposition algorithmique du payload fragmente une instruction malveillante en morceaux — mots éparpillés dans une liste, caractères, variables ou étapes — et demande au modèle de la reconstituer puis d’agir. Chaque fragment semble anodin à un scanner ; c’est le modèle qui réalise la synthèse dangereuse.
L’injection de jetons spéciaux imite les marqueurs structurels que les modèles utilisent pour séparer instructions système, entrée utilisateur et sortie d’outil — identifiants de rôle, délimiteurs, format d’appel d’outil. En falsifiant ces frontières, l’attaquant tente d’élever un contenu non fiable au rang de directive système ou de nouveau bloc d’instructions.
L’injection de données de contexte à l’insu de l’utilisateur exploite l’écart entre contexte de confiance et instruction exécutable. Le prompt de la victime est inoffensif ; le payload voyage dans les données environnantes qu’elle introduit sans le savoir — une note collée, une pièce jointe téléversée, un e-mail transféré, une fiche CRM, ou un contenu inséré par une extension ou un utilitaire de synchronisation compromis. Le modèle traite ensuite l’instruction cachée dans l’environnement authentifié de l’utilisateur.
Le fil conducteur : aucune de ces techniques ne repose sur le classique « ignore les instructions précédentes ». Elles opèrent par activation différée, contrainte sémantique, usurpation de frontière, fragmentation et procédure implicite — et elles se combinent, si bien qu’un même incident peut en cumuler plusieurs.
Pourquoi c’est important
Une étiquette « injection de prompt » unique masque la chaîne d’attaque et prive l’ingénierie de détection du détail dont elle a besoin. Si un incident est en réalité une injection indirecte portant une frontière d’appel d’outil falsifiée et un payload décomposé, le désigner d’un seul terme ne dit rien du contrôle qui a échoué. Une taxonomie structurée fournit une carte : elle nomme la technique, indique où elle entre dans le pipeline et rend les attaques composites descriptibles.
L’exposition est large, car le contexte du modèle provient désormais de nombreuses sources — prompts, fichiers, corpus RAG, mémoire d’agent, API, sorties d’outils, contenu de navigateur, e-mails, données SaaS. Chacune est un vecteur d’injection potentiel, et les techniques à déclenchement différé ou par données de contexte déjouent spécifiquement l’intuition selon laquelle relire le prompt de l’utilisateur suffit.
Défenses
Traitez toute source de contexte du modèle comme une entrée non fiable, pas seulement le prompt utilisateur. Fichiers, documents récupérés, entrées de mémoire, sorties d’outils et données tierces doivent tous entrer dans le modèle de menace, car c’est là que résident l’injection indirecte et l’injection par données de contexte.
Faites évoluer le red teaming au-delà de « ignore les instructions précédentes ». Testez l’usurpation de frontière, l’activation différée, la décomposition algorithmique, les substitutions de caractères ou de synonymes inhabituelles, et les instructions implicites plutôt qu’explicites. Une suite de tests limitée aux jailbreaks manifestes manquera les classes ci-dessus.
Concevez la détection pour les attaques composites. Journalisez prompts et réponses avec assez de structure pour reconstituer une chaîne, et évitez d’étiqueter les incidents d’un simple « injection de prompt » générique — capturez les techniques constitutives pour pouvoir affiner les contrôles.
Durcissez les frontières structurelles. N’autorisez pas un texte fourni par l’utilisateur ou un outil à réintroduire les délimiteurs, balises de rôle ou marqueurs d’appel d’outil utilisés en interne par votre framework ; supprimez-les ou échappez-les, et vérifiez qu’un contenu non fiable ne peut être promu au rôle système.
Ajoutez une visibilité à l’exécution sur le trafic IA. Savoir qui invoque quels modèles et agents, et si les prompts ou réponses transportent des instructions dangereuses ou des données sensibles, est ce qui transforme la taxonomie d’un document de référence en un contrôle opérationnel.
Statut
| Élément | Détail |
|---|---|
| Publication | Blog CrowdStrike, 7 juillet 2026 (mis à jour le 8 juillet 2026) |
| Auteur | David Keller, recherche en sécurité IA de CrowdStrike |
| Changement | 18 nouvelles entrées ; catalogue désormais à plus de 200 techniques |
| Nouvelles classes détaillées | Trigger-Activated Rule Addition (PT0201) ; Cognitive Token Suppression (PT0197) ; Algorithmic Payload Decomposition (PT0200) ; Special Token Injection (PT0198) ; Unwitting User Context-Data Injection (IM0018) |
| Nature | Taxonomie défensive / référence red team et détection — pas de CVE, pas de publication d’exploit |