Un document peut donner des ordres à une IA : comprendre l’injection de consignes

Vous demandez à une IA de résumer une page ou un document. Le contenu peut comporter un passage qui tente de lui imposer une autre tâche : ignorer la demande, révéler une information ou lancer une action. C’est un risque d’injection de consignes, notamment lorsque l’outil traite des sources externes. Pour le réduire, il faut examiner les permissions et les étapes de validation, pas seulement demander au modèle d’être prudent.

Distinguer la source de la consigne légitime

Un document contient des informations à analyser ; il n’a pas automatiquement autorité pour modifier la tâche. Une page peut pourtant inclure un texte qui ressemble à une instruction adressée à l’assistant. Le passage peut être visible, dissimulé dans une mise en page ou présent dans un élément récupéré par l’outil. Il faut comprendre ce que le système lit réellement.

Le projet OWASP consacré à la sécurité de l’IA générative décrit ce type de risque. La capacité à produire un texte plausible ne signifie pas que le modèle sépare toujours correctement les instructions et les données. Une règle écrite dans la demande peut aider, mais ne doit pas être présentée comme une protection suffisante à elle seule.

Réduire les conséquences avec des permissions limitées

Une IA chargée de résumer un document n’a pas forcément besoin d’envoyer des courriels, de modifier un CRM ou de consulter tous les dossiers. Donnez seulement les permissions utiles au scénario. Si le système dispose d’outils d’action, examinez leurs paramètres et les données qu’ils peuvent transmettre. La gravité d’une erreur dépend fortement de ce que l’assistant a le droit de faire.

Séparez les étapes lorsque c’est possible : lecture, proposition puis validation. Une suggestion de réponse peut être relue avant l’envoi ; une modification de dossier peut être comparée aux valeurs initiales. Ces contrôles doivent porter sur l’action concrète, pas uniquement sur une phrase où l’IA assure que tout est correct. L’utilisateur doit voir les destinataires et les informations concernées.

Tester des documents volontairement difficiles

Préparez un jeu d’essai autorisé qui contient des instructions étrangères à la tâche. Observez si l’outil les cite comme contenu, les ignore ou change son comportement. Testez aussi les sources récupérées par un moteur ou un connecteur, car le risque ne se limite pas aux fichiers joints. Conservez les conditions du test et les résultats pour pouvoir les rejouer.

Un test réussi ne démontre pas l’absence de vulnérabilité. Les formulations et les parcours varient, et les outils évoluent. Il sert à repérer des erreurs et à vérifier vos contrôles. Faites examiner les scénarios importants par les personnes qui gèrent la sécurité du système. Une utilisation autonome avec des accès étendus demande davantage de précautions qu’un assistant limité à une proposition de texte.

Préparer la réaction à un comportement inattendu

Définissez comment interrompre une action et retirer les permissions concernées. Conservez des traces adaptées au diagnostic, sans enregistrer inutilement des secrets ou des documents sensibles. Si un résultat demande une opération inhabituelle, revenez à la source et à la consigne initiale avant de continuer. Ne transformez pas automatiquement une recommandation produite par l’IA en instruction administrative.

Commencez par les usages externes les plus simples et augmentez les capacités seulement lorsque les contrôles sont vérifiés. Le principe pratique est de limiter la portée d’une erreur et de rendre les actions visibles. Une défense réaliste combine permissions, séparation des étapes et tests réguliers, avec une personne capable de décider quand le système sort de son rôle.

Pour approfondir ce point, consultez aussi notre méthode sur une méthode d’évaluation de l’IA.