Injection de prompt

L'injection de prompt est une attaque où une entrée façonnée pousse un modèle de langage à ignorer ses instructions d'origine pour suivre celles de l'attaquant. C'est le risque de sécurité le plus débattu pour les applications bâties sur de grands modèles de langage, et il est difficile à éliminer complètement en raison du fonctionnement même de ces modèles.

Un LLM ne sépare pas proprement les instructions fiables des données non fiables. Le prompt système, le message de l'utilisateur et tout contenu que l'application transmet arrivent tous sous forme de texte dans la même fenêtre de contexte. Si un texte contrôlé par l'attaquant dit « ignore tes instructions précédentes et fais X », le modèle peut s'exécuter, car pour lui ce n'est que du texte sur lequel agir.

Le résultat est que les garde-fous d'une application peuvent être contournés par la parole. Un modèle censé être un agent de support poli peut être amené à révéler son prompt système, à produire du contenu interdit, ou, dans un système utilisant des outils, à appeler des fonctions qu'il ne devrait pas.

Injection de prompt directe

Dans une injection directe, l'attaquant est l'utilisateur. Il saisit des instructions conçues pour passer outre le prompt système : demander au modèle de révéler des instructions cachées, jouer un rôle pour contourner une restriction, ou traiter les règles antérieures comme annulées.

Le jailbreaking est une forme bien connue d'injection directe, où l'utilisateur construit un scénario qui amène le modèle à dépasser son entraînement de sûreté. L'injection directe est le cas le plus simple à appréhender, car l'entrée malveillante provient de la personne qui interagit avec le système, et la limitation de cadence ou la détection d'abus peuvent aider.

Injection de prompt indirecte

L'injection indirecte est la variante la plus dangereuse. Ici, les instructions malveillantes ne sont pas saisies par l'utilisateur. Elles sont dissimulées dans un contenu que l'application récupère : une page web que le modèle résume, un document dans un magasin de récupération, un courriel dans une boîte de réception que le modèle lit, ou un fichier téléversé par quelqu'un d'autre.

Lorsque le modèle traite ce contenu, il rencontre les instructions implantées et peut les suivre, alors même que l'utilisateur ne les a jamais vues ni voulues. Dans un système capable d'utiliser des outils ou d'envoyer des données, l'injection indirecte permet à un attaquant qui contrôle un seul document récupéré de diriger les actions du modèle. C'est pourquoi les systèmes de récupération et les agents traitent tout contenu ingéré comme non fiable.

Pourquoi c'est un risque majeur des LLM

L'injection de prompt figure en tête des listes de risques, dont le Top 10 de l'OWASP pour les applications LLM, pour plusieurs raisons.

C'est fondamental, pas un bogue. L'absence de frontière stricte entre instructions et données est inhérente à la façon dont les modèles actuels lisent un prompt. Aucun correctif ne la referme complètement.

Cela croît avec la capacité. À mesure que les applications donnent aux modèles l'accès à des outils, à des données privées et à la capacité d'agir, une injection réussie passe d'une sortie embarrassante à une exfiltration de données ou à des actions non autorisées.

C'est difficile à tester de façon exhaustive. Les attaquants peuvent formuler la même intention d'innombrables manières, y compris dans d'autres langues ou sous des formes encodées, donc un filtre qui bloque une formulation en bloque rarement toutes.

Mesures d'atténuation

Il n'existe pas de remède unique, donc les défenses sont en couches.

Séparez et étiquetez les niveaux de confiance. Gardez distincts les instructions système, l'entrée utilisateur et le contenu récupéré, et indiquez clairement au modèle lequel fait autorité. Certains frameworks utilisent des rôles de message structurés pour le renforcer.

Limitez ce que le modèle peut faire. La défense la plus forte est de réduire l'impact. Limitez les autorisations d'outils, exigez une approbation humaine pour les actions lourdes de conséquences, et ne laissez jamais la sortie du modèle déclencher directement une opération irréversible sans vérification.

Validez les entrées et les sorties. Filtrez les schémas d'injection connus, et vérifiez la sortie du modèle et tout appel d'outil avant d'agir. Traitez par défaut le contenu récupéré et le contenu utilisateur comme non fiables.

Isolez et placez en bac à sable. Exécutez les actions d'outils avec le moindre privilège, afin qu'un modèle détourné ne puisse toujours pas atteindre de systèmes sensibles. Assainissez le contenu avant qu'il n'entre dans la fenêtre de contexte lorsque c'est possible.

Testez de façon contradictoire. Soumettez l'application à des exercices d'équipe rouge avec des tentatives d'injection, y compris indirectes implantées dans des documents et des pages, et suivez dans le temps quelles formulations passent.

Aucune combinaison n'est parfaite, donc l'objectif réaliste est de rendre l'injection plus difficile et de limiter les dégâts lorsqu'elle réussit.

Pertinence pour la gouvernance

L'injection de prompt est le point de rencontre de la sécurité et de la gouvernance. Au titre du règlement européen sur l'IA (EU AI Act), les systèmes à haut risque doivent résister aux tentatives de manipulation, ce qui implique directement l'injection. La norme ISO 42001 et le cadre de gestion des risques de l'IA du NIST attendent que de telles menaces soient identifiées, testées et atténuées dans le cadre d'une gestion continue des risques.

Pour les équipes de gouvernance, les attentes concrètes sont claires. Documentez que l'injection de prompt figure dans votre modèle de menaces. Apportez la preuve de tests contradictoires. Consignez les contrôles qui limitent ce qu'un modèle compromis peut faire, et reliez les incidents d'injection à votre processus de réponse aux incidents d'IA. Le but n'est pas de prétendre à l'immunité, que personne ne peut garantir, mais de démontrer que le risque est compris et contenu.

FAQ

Quelle est la différence entre injection de prompt directe et indirecte ?

Dans l'injection directe, l'utilisateur saisit des instructions qui passent outre le prompt système. Dans l'injection indirecte, les instructions malveillantes sont dissimulées dans un contenu que le modèle ingère, comme une page web, un document ou un courriel, de sorte que l'utilisateur ne les a jamais saisies et peut ignorer leur présence. L'injection indirecte est plus dangereuse, car elle peut détourner les systèmes utilisant des outils et la récupération via une seule source implantée.

L'injection de prompt peut-elle être entièrement empêchée ?

Non. Les modèles actuels n'imposent pas de frontière stricte entre instructions et données, donc l'injection ne peut être refermée complètement. Les défenses réduisent la fréquence des réussites et limitent les dégâts lorsqu'elle aboutit, principalement en contraignant les autorisations du modèle et en validant ses actions. Traitez-la comme un risque géré, et non résolu.

En quoi l'injection de prompt diffère-t-elle du jailbreaking ?

Le jailbreaking est un type d'injection directe visant à faire dépasser au modèle ses restrictions de sûreté, par exemple produire du contenu interdit. L'injection de prompt est la catégorie plus large, qui inclut aussi le contournement des instructions de l'application et, sous forme indirecte, l'implantation de commandes dans du contenu externe pour détourner le comportement ou l'usage des outils.

Pourquoi l'injection de prompt indirecte est-elle un problème pour le RAG et les agents ?

Ces systèmes transmettent du contenu externe au modèle : documents récupérés dans le RAG, résultats d'outils et pages chargées dans les agents. Si l'un de ces contenus porte des instructions cachées, le modèle peut les suivre et, dans un agent, faire un usage abusif de ses outils. Comme le contenu arrive par la récupération ou les outils plutôt que par l'utilisateur, il contourne les vérifications d'entrée visant l'utilisateur.

Quelle est la défense la plus efficace à elle seule ?

Limiter les capacités du modèle. Si un modèle compromis ne peut atteindre de données sensibles, dépenser de l'argent ou entreprendre des actions irréversibles sans approbation humaine, une injection réussie produit une mauvaise sortie plutôt qu'un véritable dommage. Le filtrage des entrées et l'étiquetage de confiance aident, mais c'est la limitation de l'impact qui tient lorsque le filtrage échoue.

Comment l'injection de prompt se rattache-t-elle à la conformité ?

Des cadres comme le règlement européen sur l'IA exigent que les systèmes à haut risque résistent à la manipulation, et des normes comme ISO 42001 et le NIST AI RMF attendent que les menaces soient identifiées, testées et atténuées. Pour un auditeur, vous voudrez montrer que l'injection figure dans votre modèle de menaces, que vous menez des exercices d'équipe rouge à son sujet et que des contrôles limitent l'impact d'une attaque réussie.

Résumé

L'injection de prompt est une attaque qui pousse un modèle de langage à suivre des instructions fournies par l'attaquant au lieu des siennes, en exploitant le fait que les modèles ne séparent pas les instructions fiables des données non fiables. L'injection directe vient de l'utilisateur, tandis que l'injection indirecte dissimule des instructions dans un contenu que le modèle ingère et constitue la variante la plus dangereuse pour les systèmes de récupération et les agents. Elle ne peut être entièrement éliminée, donc la réponse est en couches : séparer les niveaux de confiance, contraindre les autorisations du modèle, valider les entrées et les actions, isoler les outils et tester de façon contradictoire. Pour la gouvernance, l'attente est de montrer que le risque figure dans votre modèle de menaces, qu'il est testé et contenu, et non de prétendre à l'immunité.