Le contenu consulté peut informer la réponse. Il ne doit pas pouvoir élargir le mandat de l’agent ni les droits de ses outils.
Nous avons appris à distinguer une donnée d’une commande. Avec les applications qui s’appuient sur un modèle de langage, cette frontière redevient un sujet de conception : du texte reçu pour être analysé peut chercher à influencer la manière dont le système agit.
Le mécanisme à comprendre
L’OWASP distingue l’injection directe de l’injection indirecte. La seconde passe par une source extérieure que le modèle consulte : fichier, page ou autre contenu. Elle peut tenter de modifier la réponse ou d’amener l’application à utiliser ses fonctions d’une manière non prévue. L’ajout d’une recherche documentaire de type RAG ne supprime pas ce risque.
Les mesures proposées combinent séparation des contenus non fiables, validation des sorties, droits minimaux et contrôle des actions sensibles. L’OWASP ne présente pas ces mesures comme une garantie absolue. L’objectif est de réduire la probabilité de réussite et les conséquences possibles.
Un scénario de conception, sans sophistication apparente
Imaginons un assistant qui prépare une synthèse à partir de documents transmis à une collectivité. L’un des documents contient un passage formulé comme une consigne pour l’assistant, alors qu’il doit être traité comme une pièce à analyser. La question de sécurité est simple : ce passage peut-il conduire à une action qui n’a jamais été demandée par l’utilisateur ?
On peut travailler ce scénario sans données réelles. Un corpus fictif, des outils simulés et des destinations de test permettent d’observer le comportement attendu : le contenu est identifié comme une donnée, l’action non autorisée est refusée et le travail demandé peut se poursuivre lorsque c’est possible.
Ma lecture : tester une frontière, pas une phrase magique
Je m’intéresserais moins à la longueur du prompt de protection qu’aux preuves fournies par l’application. Une consigne peut annoncer une limite ; le système doit la faire respecter.
- Le connecteur permet-il réellement uniquement les opérations nécessaires ?
- Une destination de sortie peut-elle être choisie à partir d’un document non fiable ?
- Une action refusée laisse-t-elle une trace compréhensible ?
- Le test est-il rejoué après une modification du modèle, des outils ou du corpus ?
La sécurité de l’agent se joue dans cet ensemble. Un modèle prudent aide. Une architecture qui réduit les conséquences de ses erreurs reste essentielle.
Lire la version en mots simples
Vous demandez à une IA de résumer un document. Dans ce document, quelqu’un a glissé un passage qui cherche à donner des ordres à l’IA. Le risque apparaît si elle suit ce passage au lieu de le traiter comme du texte à lire.
Une consigne cachée dans ce qu’on lui fait lire
C’est ce que l’on appelle une « injection de consignes », ou prompt injection. L’OWASP décrit notamment le cas où l’instruction arrive par un contenu extérieur : une page, un fichier ou un courriel. Ajouter une recherche dans des documents ne fait pas disparaître ce risque.
On peut le comparer à un courrier reçu par un service : ce courrier peut contenir une demande, mais il ne décide pas à lui seul des règles du service ni des autorisations de la personne qui le traite. C’est une image pour comprendre la frontière à préserver.
Pourquoi cela compte davantage quand l’IA peut agir
Si l’IA se contente de rédiger, le risque peut concerner le contenu de la réponse. Si elle dispose d’outils pour transmettre des informations ou modifier des fichiers, une mauvaise consigne peut avoir des effets plus concrets. Il faut donc regarder ce que l’application peut réellement faire.
Les questions à poser à l’équipe qui conçoit le service
- L’IA peut-elle uniquement consulter les informations utiles à sa mission ?
- Un document reçu peut-il lui faire choisir une nouvelle destination pour envoyer des données ?
- Les actions importantes sont-elles contrôlées en dehors de la réponse de l’IA ?
- Le service a-t-il été essayé avec de faux documents contenant des consignes contradictoires ?
Ces essais doivent utiliser des données et des outils de test. Le but est de vérifier que l’application continue de respecter la mission confiée par l’utilisateur.
Il n’existe pas de petite phrase qui rende toute application invulnérable. Ce que je veux vérifier, c’est que les limites annoncées correspondent à des limites réelles dans les outils et leurs autorisations.
