Injection de prompt dans la nature

Un tracker des techniques d'injection de prompt signalées publiquement sur environ les deux dernières années, maintenu par Rachel James (cybershujin).

Chaque technique est décomposée en trois éléments d'une injection de prompt :

1. Méthode de livraison — comment les instructions injectées atteignent le modèle (un résultat d'appel d'outil, un site web externe, une connexion MCP, un document, un e-mail, une image, etc.).
2. Encodage — l'obfuscation appliquée à la charge utile, le cas échéant (Base64, leetspeak, caractères de balise Unicode invisibles, homoglyphes, …). Vide lorsque la charge utile est en texte brut ou que le rapport ne le précise pas.
3. Comportement de propagation — si l'injection est conçue pour se propager ou persister (diffusée à quiconque se connecte à un serveur MCP empoisonné, persistée dans la mémoire à long terme/de projet d'un agent, transportée le long d'une chaîne d'appels d'outils, amenée à émettre un e-mail portant d'autres instructions, …). Vide lorsqu'il n'y a pas de propagation.

Chaque entrée enregistre également les modèles contre lesquels elle a été confirmée fonctionner (le cas échéant), un lien vers la source du signalement, et — lorsque connu — la source de l'attaque (le chercheur, l'équipe rouge ou l'acteur en conditions réelles dont elle provient).

Tableau de bord en direct : https://cybershujin.github.io/Prompt-Injection-in-the-Wild/

---

Périmètre et méthodologie

• Dans le périmètre : les techniques d'injection d'instructions adverses dans un LLM ou un agent propulsé par LLM qui ont été signalées publiquement — par des chercheurs en sécurité, des équipes rouges, des fournisseurs, ou telles qu'observées en conditions réelles. L'injection de prompt directe et indirecte (portée par les données) sont incluses.
• Hors périmètre : les listes génériques de jailbreak sans mécanisme de livraison/propagation, les simples plaintes sur l'alignement des modèles, et le marketing sans substance technique.
• Jamais deviné. Chaque cellule non vide est tirée d'une déclaration explicite dans la source citée. Si un rapport ne précise pas l'encodage, le comportement de propagation, les modèles confirmés ou la source de l'attaque, cette cellule est laissée vide — une cellule vide signifie « non précisé », jamais un « aucun » inféré.
• Vérification. Chaque entrée est marquée Confirmed ou Not fully vetted. « Not fully vetted » signale une entrée dont la source est vague, non confirmée, ou dont le mécanisme est flou — elle est exposée plutôt qu'écartée, afin qu'un relecteur puisse en juger.
• Classe de preuve — en conditions réelles vs. recherche. Chaque entrée est étiquetée In-the-wild (abus réel observé ou incident de production réel), Research / red-team (démonstration de chercheur en sécurité ou d'équipe rouge / divulgation responsable — une technique réelle et fonctionnelle, mais non observée comme exploitée par un attaquant), Vendor advisory, ou Unclear. Il s'agit d'un axe distinct de la vérification : une technique peut être Confirmed (vérifiée et fonctionnelle) tout en n'ayant jamais été démontrée qu'en laboratoire. À noter : une véritable injection de prompt malveillante en conditions réelles est encore rarement documentée publiquement, donc la grande majorité des entrées ici sont des divulgations de recherche / d'équipe rouge — au moment du remplissage initial, 29 sur 32 étaient de la recherche/équipe rouge et seulement 3 étaient en conditions réelles. Utilisez le filtre Evidence du tableau de bord pour isoler les cas réels.
• Mises à jour. Les nouveaux signalements sont balayés mensuellement (Perplexity sonar-deep-research, large filet) et proposés sous forme de pull request en brouillon pour examen par le mainteneur. Rien n'est fusionné automatiquement. Voir le tracker frère Threat-Actors-use-of-Artifical-Intelligence pour le même flux de travail appliqué à l'usage de l'IA par les acteurs de menace.

Comment les données sont construites

Les données résident uniquement dans le tableau ci-dessous (ce fichier est la source unique de vérité). Un générateur déterministe et sans dépendances (tools/build_exports.py) les compile à chaque commit en :

• index.html — le tableau de bord interactif (servi via GitHub Pages),
• tracker.json — données normalisées lisibles par machine,
• stix/prompt-injection-stix2.1.json — un bundle STIX 2.1 (chaque technique comme attack-pattern, étiquetée avec son ID MITRE ATLAS et une correspondance Not fully vetted → faible confiance).

Ne modifiez pas ces trois fichiers à la main ; modifiez le tableau et laissez la CI les reconstruire.

---

Techniques