Une instruction cachée dans un document peut détourner une IA : comprendre les injections de prompt

Un assistant reçoit un document pour en faire la synthèse. Au milieu du texte, une phrase lui demande de modifier ses règles et d’exécuter une autre tâche. Pour un lecteur humain, elle ne mérite aucune autorité particulière. Pour un système d’IA mal encadré, elle peut influencer la réponse, voire les actions disponibles. C’est le problème de l’injection de prompt : une donnée fournie au système tente de devenir une consigne.

Une attaque peut venir d’une pièce que vous avez demandé de lire

L’injection directe est introduite dans l’échange avec l’assistant. L’injection indirecte arrive par une ressource consultée : pièce jointe, page web, document indexé ou résultat d’un outil. Dans ce second cas, l’utilisateur peut formuler une demande parfaitement normale. La tentative de détournement se situe dans le contenu transmis au modèle.

OWASP distingue ces formes dans sa description du risque d’injection de prompt. L’organisation rappelle aussi qu’une protection unique ne fournit pas de garantie absolue. Le problème dépasse donc le choix d’une formulation plus ferme dans le message initial. Il faut examiner les données reçues et les pouvoirs accordés au système.

Le mot « cachée » ne signifie pas nécessairement invisible à l’écran. L’instruction peut se trouver dans un passage que personne ne lit attentivement, une section secondaire ou un élément récupéré par l’extraction. Son efficacité dépend du chemin réel des données, pas uniquement de l’apparence du document ouvert dans une application.

Une citation malveillante reste une citation. Le système doit pouvoir expliquer son contenu sans lui obéir. Cette distinction paraît simple ; elle devient plus difficile lorsque des instructions légitimes et des pièces externes sont assemblées dans le même contexte, puis envoyées à un modèle chargé de choisir sa prochaine action.

Prenons un scénario fictif. Une équipe utilise un assistant pour préparer un récapitulatif de demandes d’achat. Une pièce contient une instruction demandant d’envoyer le récapitulatif à un destinataire différent. Le document peut décrire une demande, mais il ne doit pas déterminer à lui seul les droits d’envoi ni remplacer le destinataire validé par l’application.

Ce scénario ne décrit pas un incident observé ni un test réalisé sur un produit. Il sert à identifier la frontière à protéger : la capacité à lire une information ne doit pas devenir la capacité à autoriser une opération.

Dessiner le parcours des données avant de choisir un filtre

Listez les entrées réellement consommées. Le document d’origine ne suffit pas : extraction de texte, découpage en fragments, indexation, recherche et réponses des outils peuvent ajouter ou transformer des informations. Une vérification appliquée au fichier initial ne couvre pas automatiquement tout ce parcours.

Indiquez l’origine de chaque bloc présenté au modèle. Une consigne de l’application, une question utilisateur et une citation documentaire ont des fonctions distinctes. Une séparation explicite aide à les traiter correctement ; elle n’assure pas, seule, que le modèle respectera toujours leur niveau d’autorité.

Demandez ce qui se passe lorsqu’une pièce est modifiée après son indexation. L’application doit savoir quelle version elle utilise et comment elle répercute les retraits. Une suppression dans le dossier partagé ne garantit pas qu’une copie indexée, un cache ou un résumé antérieur disparaît au même moment.

Dans ses recommandations consacrées aux architectures RAG, OWASP insiste notamment sur la provenance, les permissions et les contrôles des sorties. Ces principes concernent la chaîne documentaire complète. Une réponse enrichie par la recherche n’est pas intrinsèquement sûre du seul fait qu’elle contient des références.

Le tableau suivant est une grille de revue proposée pour une petite application documentaire. Il ne remplace pas l’analyse technique de son architecture.

Le filtre de sécurité doit s’appuyer sur des identités et des autorisations vérifiées. Une mention figurant dans un document, même présentée comme une règle interne urgente, ne suffit pas pour accorder un nouveau droit. Le modèle ne devrait pas pouvoir élargir son propre périmètre d’accès en reformulant cette mention.

Réduire les conséquences possibles d’une réponse détournée

Commencez par les pouvoirs de l’assistant. Un outil qui résume seulement des documents ne présente pas le même risque qu’un agent capable d’envoyer des messages, de modifier des données ou de lancer une commande. Le contrôle doit correspondre à ce qu’une mauvaise réponse permet concrètement de faire.

Accordez les accès nécessaires à la tâche, sur le périmètre nécessaire. Un assistant utilisé pour préparer une note sur un projet n’a pas besoin, par défaut, de consulter l’ensemble des dossiers de l’organisation. Cette réduction des privilèges limite les conséquences d’une erreur sans résoudre à elle seule l’injection.

Pour les actions, prévoyez des paramètres vérifiés par le logiciel. Les destinataires autorisés, les ressources accessibles et les montants admissibles doivent être contrôlés en dehors de la réponse du modèle. Si l’application accepte n’importe quel paramètre proposé dans un texte, une phrase hostile peut devenir un problème opérationnel.

Une validation humaine peut compléter ces contrôles, à condition d’afficher ce qui va réellement se passer. « Autoriser la suite » ne renseigne pas suffisamment. Présentez l’opération, les données concernées et sa destination. Une personne qui valide un résumé ne valide pas implicitement son envoi à une autre entreprise.

Pour les changements sensibles, séparez la préparation de l’exécution. L’assistant propose une modification ; une étape distincte vérifie sa conformité et obtient l’autorisation nécessaire. Cette séparation peut être simple dans un petit projet, mais elle doit rester effective lorsque plusieurs outils sont connectés.

Le traitement des sorties mérite la même attention. Un texte généré destiné à l’affichage ne doit pas être interprété automatiquement comme du code exécutable. Un lien proposé ne doit pas entraîner une transmission silencieuse de documents. Chaque passage vers une autre fonction crée une nouvelle décision de sécurité.

Les filtres de formulation ont des limites. Chercher quelques expressions suspectes peut aider à signaler certains contenus, mais une instruction peut être reformulée. À l’inverse, un article expliquant les attaques peut contenir ces expressions sans être lui-même une attaque à exécuter. Le contexte et les contrôles d’action restent indispensables.

Construire un essai défensif dont le résultat est mesurable

Ne testez pas uniquement une question provocatrice dans la fenêtre de chat. Reproduisez les entrées ordinaires de votre application : documents, extraits de recherche et pièces jointes. Le but est de vérifier qu’une ressource externe ne modifie ni l’autorité de la demande ni les permissions disponibles.

Travaillez dans un environnement d’essai avec des données fictives et des actions simulées. Les destinataires et comptes de démonstration doivent éviter toute divulgation réelle. Un test visant à découvrir une faiblesse ne devrait pas avoir besoin d’envoyer des informations de production à une adresse extérieure.

Définissez une série de situations : pièce normale, citation d’une consigne dangereuse, instruction contradictoire, demande de changement de destinataire et ressource prétendant venir d’un administrateur. La diversité des formulations renseigne davantage que la répétition d’une même phrase avec quelques mots modifiés.

Fixez le résultat attendu pour chaque cas. L’assistant peut décrire la phrase trouvée dans la pièce, mais ne doit pas l’exécuter. L’application peut enregistrer une proposition, mais doit bloquer une opération hors périmètre. Ces attentes distinctes permettent de localiser un défaut au niveau du modèle ou au niveau des contrôles.

Gardez les traces utiles : version du document, réponse produite, opération demandée et décision du contrôle. Il n’est pas toujours nécessaire de conserver toutes les données de conversation. Définissez ce qui facilite l’analyse, qui peut le consulter et combien de temps il doit être gardé.

Notre méthode pour évaluer une IA sur des tâches vérifiables aide à préparer cette grille. La sécurité ajoute des critères bloquants : une réponse correcte sur neuf documents ne compense pas une action interdite sur le dixième.

Si dix cas de test sont correctement traités, vous avez validé ces dix cas dans ces conditions. Vous n’avez pas démontré l’impossibilité de toutes les injections futures. Documentez le périmètre testé, puis ajoutez progressivement les cas issus de changements techniques et de défauts observés.

Examiner aussi ce qui ne ressemble pas à une attaque

Une pièce peut contenir des instructions légitimes pour un lecteur humain : une procédure de remboursement ou un guide administratif, par exemple. L’assistant doit pouvoir les résumer. Cela ne l’autorise pas à les appliquer sans vérifier que l’utilisateur lui demande cette action et dispose des droits correspondants.

Les instructions provenant d’un auteur réputé ne deviennent pas automatiquement fiables pour votre contexte. Un document public peut décrire une procédure utile à une autre organisation. La provenance aide à évaluer l’information ; elle ne remplace pas les règles de votre application.

Un système qui refuse tout document comportant un impératif peut perdre une grande partie de son intérêt. Le contrôle doit éviter de confondre lecture, interprétation et exécution. Cette distinction permet de traiter un manuel technique sans laisser son contenu modifier les permissions du lecteur automatisé.

Les résultats de recherche peuvent également contenir des erreurs ordinaires, sans intention malveillante. Une adresse obsolète ou un document mal classé peut produire un effet proche d’une attaque dans une chaîne trop permissive. Les contrôles d’autorisation protègent aussi contre ces problèmes de qualité documentaire.

Quand une pièce semble suspecte, préservez-la selon la procédure de l’organisation et évitez de la diffuser largement pour demander un avis. Le signalement doit permettre une analyse par les personnes autorisées. Copier l’ensemble du dossier dans plusieurs outils multiplie les lieux de conservation sans nécessairement améliorer le diagnostic.

Préparer une réaction qui limite l’incident

Si vous soupçonnez un détournement, commencez par suspendre les capacités d’action concernées et conservez les traces nécessaires. Examinez les opérations réellement exécutées. Une réponse inquiétante ne prouve pas qu’un envoi ou une modification a eu lieu ; inversement, l’absence d’un message visible ne garantit pas qu’aucun outil n’a été appelé.

Vérifiez les documents consultés, les ressources accessibles et les destinataires impliqués. Traitez les secrets potentiellement exposés selon les procédures applicables : rotation, révocation ou restriction. Ne vous contentez pas de corriger le prompt si le problème vient d’un outil acceptant des paramètres non autorisés.

Cherchez la cause reproductible dans un environnement contrôlé. Le correctif peut concerner les droits, l’étape de confirmation, la recherche documentaire ou la validation des sorties. Réduire temporairement le périmètre permet parfois de poursuivre une fonction de lecture pendant que les capacités d’action restent désactivées.

Après correction, rejouez le scénario initial et d’autres situations proches. Contrôlez aussi les tâches normales pour éviter qu’un blocage trop large rende l’application inutilisable. La décision de remise en service doit préciser ce qui a été corrigé, les limites restantes et les conditions de surveillance.

Une équipe peut conserver une fiche de sécurité concise : sources acceptées, actions disponibles, règles de confirmation et responsable en cas d’alerte. Cette fiche doit suivre les changements d’intégration. Ajouter un outil d’envoi à un assistant documentaire transforme son exposition, même si son interface semble identique.

L’injection de prompt rappelle une règle de conception simple : une information peut influencer une réponse, mais ne doit pas décider seule de l’autorisation d’une action. La fiabilité se construit dans cette séparation, avec des permissions limitées, des contrôles vérifiables et des essais réguliers. Le texte de protection fait partie du dispositif ; il ne doit pas en être la totalité.

Dans une revue de projet, demandez une démonstration du refus côté application : une opération non autorisée doit être rejetée même lorsque le modèle la propose avec assurance. Vérifiez ensuite le journal et le message présenté à l’utilisateur. Le contrôle est plus facile à maintenir lorsque son résultat est explicite, au lieu de dépendre d’une interprétation discrète du texte.

Attribuez également un responsable aux documents indexés. Qui retire une ancienne procédure ? Qui valide l’arrivée d’une nouvelle source ? Ces questions de gestion courante réduisent les angles morts. Sans propriétaire identifié, un index peut conserver pendant longtemps des contenus que personne ne considère encore comme utilisables.