Prévention de l'injection de prompt : les 4 couches de défense de l'IA

TL;DR

La prévention de l'injection de prompt, c'est la défense en profondeur, pas un correctif. La cause profonde est architecturale : un modèle de langage ne peut pas séparer les instructions du développeur des données de l'utilisateur quand les deux vivent dans le même flux de tokens. La stratégie qui fonctionne empile quatre couches, garde-fous d'entrée, durcissement du prompt système, entraînement d'alignement et garde-fous de sortie, puis limite le rayon de souffle avec le moindre privilège, la journalisation et l'approbation humaine pour les actions risquées. Chaque couche a un contournement documenté, donc aucune ne peut être sautée.

Ceci est la partie 3 d'une série en trois volets, et elle tient debout toute seule. Vous n'avez pas besoin d'avoir lu la partie 1 : les fondations ni la partie 2 : le manuel d'attaque pour la suivre, même si elles aiguiseront tout ce qui suit. Si vous êtes concepteur, ceci est votre plan d'architecte. Si vous êtes chasseur de bug bounty, comprendre les défenses rend vos attaques plus tranchantes.

Chaque entreprise d'IA affirme que son chatbot est sûr. Chacune d'elles a tort, au moins un peu. J'ai vu des entreprises greffer un filtre de mots-clés sur leur IA, annoncer qu'elles sont « à l'épreuve de l'injection de prompt », et perdre ce filtre en moins de vingt minutes de test. Cet article est la moitié défenseur de l'histoire, et il est honnête sur ce qui fonctionne, ce qui ne fonctionne pas, et pourquoi.

Pourquoi la prévention est une défense en profondeur, pas un correctif

Pour comprendre pourquoi l'injection de prompt ne peut pas être simplement corrigée, vous devez vous rappeler ce qu'est un grand modèle de langage. Dépouillez-le du marketing et un LLM est un moteur de prédiction statistique, le même genre de devineur de token suivant que la saisie automatique de votre téléphone, mis à l'échelle pour prédire des paragraphes à partir de motifs appris sur la majeure partie d'Internet.

Dans le logiciel traditionnel, le code et les données sont tenus séparés. SQL a un langage de requête et des paramètres d'entrée séparés, et les données ne peuvent pas s'exécuter comme du code quand le système est bien conçu. Les grands modèles de langage n'ont pas une telle muraille. Le prompt système du développeur, le message de l'utilisateur et tout contenu externe que le modèle lit sont tous fondus dans une seule séquence continue de tokens. Si un morceau d'entrée utilisateur ressemble à une instruction, le modèle peut la suivre. Non pas parce qu'il s'est fait berner. Parce qu'il n'a aucun mécanisme pour faire la différence.

Ce simple fait explique pourquoi l'injection de prompt occupe la première place du Top 10 OWASP pour les applications LLM, pourquoi les taux de réussite rapportés des attaques vont de 50 à 84 pour cent, et pourquoi les modèles de pointe restent vulnérables après leurs meilleures défenses. Ce n'est pas un bug en attente d'un correctif. C'est l'architecture. Alors les défenseurs arrêtent d'essayer de retirer le défaut et commencent à construire des couches autour de lui.

Les 4 couches de défense de l'IA

La plupart des applications d'IA ont quatre couches défensives, chacune protégeant contre différents types d'attaque. Pensez à la sécurité d'un aéroport. La couche 1 est le détecteur de métaux à l'entrée, le garde-fou d'entrée. La couche 2 est la carte d'embarquement qui définit où vous êtes autorisé à aller, le prompt système. La couche 3 est la formation du pilote qui empêche les manœuvres dangereuses, l'alignement intégré au modèle. La couche 4 est l'agent de sûreté en vol qui guette les problèmes une fois que vous êtes déjà dans l'avion, le garde-fou de sortie.

Couche 1 : garde-fous d'entrée

Les garde-fous d'entrée inspectent le prompt de l'utilisateur avant qu'il n'atteigne le modèle. La validation fondée sur les caractères utilise une regex pour mettre sur liste blanche les caractères autorisés, ce qui marche pour une calculatrice mais est inutile pour un chatbot généraliste. La validation fondée sur le contenu filtre sur le sens plutôt que sur les caractères, souvent à l'aide d'un modèle classifieur plus petit qui juge si l'intention derrière un message est malveillante. Cela attrape bien plus, mais cela coûte de la latence et de l'argent à chaque requête.

Le compromis fondamental est inévitable : les filtres de mots-clés stricts sont triviaux à contourner par encodage ou paraphrase, tandis que les filtres sémantiques sont plus difficiles à tromper mais plus lents et sujets aux faux positifs. C'est pourquoi tant de systèmes en production sont livrés avec des filtres faibles, et pourquoi un attaquant essayant le Base64, l'insertion d'Unicode ou une autre langue trouvera généralement une faille. Un garde-fou d'entrée est un ralentisseur, pas un mur.

Couche 2 : durcissement du prompt système

Le prompt système est le levier le plus direct du développeur, et trois techniques le durcissent contre les données non fiables qui circulent dans le même flux. La délimitation marque la frontière entre les instructions de confiance et l'entrée non fiable à l'aide de symboles spéciaux, en disant au modèle de ne jamais obéir aux instructions trouvées entre eux. Le marquage de données va plus loin, en intercalant un caractère spécial entre chaque mot de l'entrée non fiable pour qu'elle soit syntaxiquement distincte des instructions. L'encodage prend l'entrée non fiable et l'encode, typiquement en Base64, en demandant au modèle de décoder et de résumer mais jamais de traiter le texte décodé comme de nouvelles instructions.

Aucune de ces techniques n'est infaillible. Un payload suffisamment créatif peut encore fonctionner à l'intérieur des délimiteurs, et on peut convaincre un modèle d'ignorer le marquage de données. Mais chacune augmente le coût d'une attaque réussie, et augmenter le coût est tout l'intérêt. La recherche de Microsoft sur ces techniques de mise en lumière (spotlighting) est l'exposé le plus clair de jusqu'où le durcissement du prompt système peut et ne peut pas vous mener.

Couche 3 : entraînement d'alignement et affinage

C'est la défense intégrée aux poids du modèle plutôt qu'au code applicatif qui l'entoure. L'affinage entraîne davantage un modèle généraliste sur des données spécifiques à un domaine, de sorte qu'un modèle de support affiné uniquement sur des tickets de support résiste naturellement à un détournement, simplement parce que sa distribution d'entraînement ne couvre pas le mésusage. Plus l'affinage est étroit, plus la surface est petite.

L'entraînement adverse aux prompts est l'une des atténuations les plus efficaces disponibles aujourd'hui. Le modèle est entraîné sur des payloads connus d'injection de prompt et de jailbreak comme exemples négatifs, à la manière d'un vaccin qui entraîne un système immunitaire sur un pathogène affaibli. La limite est évidente une fois énoncée : l'entraînement adverse ne protège que contre les motifs que le modèle a déjà vus, donc les payloads inédits passent au travers. C'est pourquoi le red teaming régulier n'est pas optionnel, c'est le seul moyen de maintenir à jour les défenses du modèle. L'ingénierie de prompt comme défense, dire simplement au modèle « ne révèle jamais de secrets », est l'atténuation la plus courante et aussi la plus faible, trivialement contournée par le jeu de rôle ou l'encodage. Elle a sa place dans la pile, jamais comme seule couche.

Couche 4 : garde-fous de sortie

Les garde-fous de sortie scrutent la réponse du modèle avant qu'elle n'atteigne l'utilisateur. Si la réponse contient un prompt système, une clé d'API, des données personnelles ou un contenu nuisible, elle est bloquée. Le contournement est élégant dans sa simplicité : demandez au modèle d'encoder sa propre sortie, et un garde-fou qui scrute des secrets en clair voit une chaîne de Base64 et la laisse passer, tandis que l'attaquant décode le résultat de son côté.

Les garde-fous plus sophistiqués utilisent une classification fondée sur l'IA, le schéma « LLM as a judge », où un second modèle évalue si l'entrée ou la sortie du modèle principal est malveillante. Cela ajoute une vraie protection, mais cela double le coût de calcul et introduit une nouvelle surface d'attaque. Si le modèle juge est lui-même vulnérable à l'injection de prompt, un attaquant peut le convaincre d'approuver un contenu malveillant. La défense contre les attaques d'IA est une autre IA qui peut elle aussi être attaquée. C'est l'état actuel du domaine, et il vaut la peine de s'y arrêter un instant.

Une check-list de défense pour les concepteurs

Si vous construisez quoi que ce soit avec un LLM dans la boucle, voici la pile minimale, écrite en prose parce que chaque élément dépend des autres. Commencez par un filtrage d'entrée qui associe un classifieur sémantique à une liste de blocage de mots-clés, en sachant que l'encodage peut encore le contourner. Ajoutez le durcissement du prompt système via la délimitation ou le marquage de données, en sachant que le cadrage créatif peut encore passer. Imposez le moindre privilège pour que le modèle ne puisse toucher que les outils et les données dont il a strictement besoin, ce qui n'arrête pas une attaque mais limite le rayon de souffle quand elle réussit, le même principe que celui derrière le zero trust.

Ajoutez ensuite un filtrage de sortie avec un scanner fondé sur l'IA plus une détection de données personnelles, en sachant que la sortie encodée peut se faufiler. Appliquez une limitation de débit par utilisateur et par fenêtre, en sachant que les attaques lentes et distribuées la contournent. Journalisez chaque prompt et chaque réponse, parce que la journalisation est la différence entre attraper une attaque en quelques minutes plutôt qu'en quelques mois. Exigez un humain dans la boucle pour les actions à haut risque comme les remboursements, en sachant qu'un attaquant peut aussi tenter de manipuler le relecteur par ingénierie sociale. Et faites du red teaming sur un calendrier récurrent, parce que de nouvelles techniques émergent constamment. Aucun élément isolé ne suffit. Mettez-les tous en œuvre, et budgétez le fait que même tous ensemble ils ne seront pas parfaits.

La surface d'attaque au-delà de la zone de chat

La plupart des gens se représentent l'injection de prompt comme quelque chose qui se passe à l'intérieur d'une fenêtre de chat. La vraie surface d'attaque est bien plus vaste, et la majeure partie n'a rien à voir avec une zone de chat. J'y pense comme à sept couches, et la zone de chat n'est qu'un petit morceau de l'une d'elles.

La couche d'interface, ce sont les runtimes LLM locaux comme Ollama, Llama.cpp et LM Studio, souvent exposés sur HTTP sans authentification et repérables via de simples dorks de recherche. La couche d'agent et d'orchestration, ce sont les moteurs de workflow et les interfaces de chat comme n8n, Flowise, Open WebUI et LibreChat, qui peuvent faire fuiter l'historique de conversation ou être amenés à pratiquer une falsification de requête côté serveur. La couche de données et de mémoire, ce sont les bases vectorielles comme Chroma, Weaviate et Qdrant, où une collection ouverte peut être empoisonnée pour influencer ce qu'une IA récupère et croit. La couche d'ingénierie ML, ce sont les tableaux de bord comme Ray, MLflow et ClearML, fréquemment déployés sans authentification. La couche de passerelle et de télémétrie, ce sont les passerelles LLM comme LiteLLM et Langfuse qui se placent devant tout le trafic des modèles. La couche d'artefacts et de plugins, ce sont les hubs de modèles et les serveurs MCP, où un seul plugin compromis peut empoisonner chaque agent qui s'y connecte. Et la couche d'identité, ce sont les clés d'API exposées des grands fournisseurs, chacune avec un motif distinct et facilement repérable. Sept couches, et la zone de chat n'en est que la pointe visible.

Les Top 10 OWASP : le cadre qui compte

Trois listes Top 10 OWASP distinctes couvrent désormais la sécurité de l'IA, et comprendre les trois vous donne un modèle de menace complet. Le Top 10 LLM est l'original : l'injection de prompt en numéro un, suivie de la divulgation d'informations sensibles, des attaques de chaîne d'approvisionnement, de l'empoisonnement des données et du modèle, de la mauvaise gestion des sorties, de l'agentivité excessive, de la fuite du prompt système, des faiblesses des vecteurs et des embeddings, de la désinformation et de la consommation non bornée.

Le Top 10 MCP couvre l'écosystème du Model Context Protocol : la mauvaise gestion des tokens, l'escalade de privilèges par dérive de portée, l'empoisonnement d'outils, les attaques de chaîne d'approvisionnement, l'injection de commandes, l'injection de prompt contextuelle, l'authentification insuffisante, l'absence de journalisation d'audit, les serveurs MCP fantômes et le surpartage de contexte. Le Top 10 agentique couvre les agents autonomes : le détournement d'objectif, le mésusage d'outils, l'abus d'identité et de privilèges, la compromission de la chaîne d'approvisionnement, l'exécution de code inattendue, l'empoisonnement de la mémoire et du contexte, la communication inter-agents non sécurisée, les défaillances en cascade, l'exploitation de la confiance humaine et les agents malveillants. Il existe aussi un Top 10 ML dédié en dessous pour les risques classiques de l'apprentissage automatique comme l'empoisonnement de données, l'inversion de modèle, l'inférence d'appartenance et le vol de modèle. Si vous êtes testeur, rattachez chaque constat à l'une de ces catégories. Si vous êtes concepteur, traitez les quatre listes comme votre modèle de menace, pas seulement la première.

La défense la plus solide n'est pas un filtre astucieux. C'est une décision architecturale : ne jamais donner à un même système des données privées, du contenu non fiable et un canal externe en même temps.

L'IA agentique : la prochaine frontière

Tout ce qui précède s'applique à un simple chatbot qui répond à des questions. L'industrie évolue vite vers l'IA agentique, et les enjeux montent d'un ordre de grandeur. Les systèmes agentiques ne sont pas que des chatbots. Ils naviguent sur le web, envoient des e-mails, exécutent du code, modifient des fichiers, font des appels d'API et parlent à d'autres agents. Combinez cette portée avec une injection de prompt et l'impact passe de « le modèle a dit quelque chose d'embarrassant » à « le modèle a supprimé des données de production » ou « le modèle a envoyé par e-mail des secrets d'entreprise à une adresse externe ».

C'est là que la triade létale devient essentielle pour les défenseurs, pas seulement pour les attaquants. Tout système agentique qui a simultanément l'accès à des données privées, qui est exposé à du contenu non fiable et qui peut communiquer vers l'extérieur est trivialement exploitable. Le correctif n'est pas un filtre astucieux, c'est de retirer une jambe du triangle.

Les attaques indirectes à plusieurs sauts, où un payload traverse plusieurs agents avant de se déclencher, montent vite, et des vers IA qui se propagent d'eux-mêmes à travers des systèmes connectés ont déjà été démontrés en recherche contrôlée. L'exemple public le plus clair de risque agentique à ce jour est l'opération GTG-1002, que j'ai décortiquée dans comment les hackers utilisent l'IA : des attaquants ont branché un agent sur une machine Kali Linux, exposé des outils offensifs via MCP, et l'ont laissé mener reconnaissance, exploitation et mouvement latéral en grande partie seul. Le danger a augmenté avec l'autonomie, pas avec la puissance brute du modèle. Pour les chasseurs de bug bounty, c'est là que vivent les vrais paiements. Une injection de prompt qui fait fuiter un prompt système est informative. Une qui fait émettre à un agent un remboursement non autorisé ou supprimer une base de données est critique. Même compétence sous-jacente, enjeux dramatiquement plus élevés.

Une check-list de test pour les chasseurs

Si vous testez une application d'IA pour l'injection de prompt, déroulez cet ordre et documentez tout, en vous rappelant que le même payload peut ne pas fonctionner deux fois, donc réessayez chaque technique trois fois et peaufinez la formulation. Commencez par la reconnaissance : identifiez le modèle et son architecture, ce pour quoi il est affiné, les outils qu'il peut appeler, et chaque canal d'entrée, y compris le texte, les fichiers, les images et les URL. Passez à l'injection directe : extrayez le prompt système via des techniques directes et indirectes, testez les contournements par encodage en Base64, ROT13, hexadécimal et l33t speak, testez le changement de langue, testez le jeu de rôle et le détournement de persona, et testez l'escalade multi-tours sur cinq tours ou plus.

Testez ensuite l'injection indirecte via du texte caché dans des PDF, des commentaires HTML et du texte blanc sur blanc, et testez les contournements par encodage de sortie en demandant au modèle d'encoder ses réponses. Enfin, escaladez : testez l'abus d'outils et d'actions, y compris les actions malveillantes et la falsification de requête côté serveur, testez l'injection markdown via des balises d'image pour l'exfiltration de données, et enchaînez trois techniques ou plus dans un seul payload pour un impact maximal. Tout le détail offensif de chacune de ces étapes vit dans la partie 2 : le manuel d'attaque. Documentez tout, capturez tout en image, et rapportez avec des étapes de reproduction claires et un impact démontré.

Voici la vérité que personne ne vous dit

Nous courons pour déployer des agents autonomes qui entreprennent des actions dans le monde réel par-dessus une fondation que tout le monde dans le domaine sait défaillante. Le défaut architectural qui rend l'injection de prompt possible n'a pas été résolu, et il n'a même pas été partiellement résolu. Chaque défense de cet article est un pansement sur cette plaie, et la surface d'attaque grandit plus vite que les pansements ne peuvent être appliqués.

Cela ne veut pas dire que la défense est inutile. La défense en profondeur fonctionne réellement : elle rend les attaques plus lentes, plus difficiles et bien plus détectables, et contre la plupart des attaquants cela suffit à l'emporter. Ce domaine ne s'essouffle pas, il s'étend. Le nombre d'applications intégrant de l'IA croît de façon exponentielle, et le nombre de gens qui savent les tester ou les défendre ne suit pas le rythme. Cet écart est l'opportunité, quel que soit le côté de la table où vous êtes assis.

Conclusion

L'injection de prompt est la vulnérabilité déterminante de l'ère de l'IA, de la même façon que l'injection SQL a défini l'ère des applications web. Contrairement à l'injection SQL, il n'existe pas d'équivalent de la requête préparée, parce que la cause profonde est l'absence d'une frontière entre les instructions et les données à l'intérieur du modèle lui-même. Le mieux que l'on puisse faire est d'empiler des couches, de surveiller agressivement, de restreindre ce que les agents peuvent toucher, et de garder une longueur d'avance sur des attaquants qui n'ont besoin que d'une seule faille.

Si cela paraît décourageant, retournez-le. Chaque système précipité en production aujourd'hui est une future cible de test, un futur bug bounty, un futur article de recherche. Les équipes qui comprennent l'échafaudage, et décident délibérément où un humain doit rester dans la boucle, sont celles qui gardent le contrôle à mesure que les agents prennent en charge une part croissante du travail. C'est exactement l'état d'esprit que nous bâtissons dans le bootcamp cybersécurité d'Unihackers. Allez tester. Allez construire. Allez rendre les systèmes d'IA plus sûrs que ceux que vous avez trouvés.

Continuez à chasser. Restez curieux.