LES POINTS ESSENTIELS
À retenir
- Traiter les instructions présentes dans les sources comme des données.
- Limiter les outils et appliquer les droits côté serveur.
- Séparer proposition, validation humaine et exécution.
Reconnaître le changement de rôle d’un texte
Un document fourni pour être résumé peut contenir une phrase qui demande d’ignorer les consignes ou d’utiliser un outil. Ce texte appartient aux données analysées. Lui permettre de modifier la tâche revient à confondre la matière de travail avec les instructions de l’application.
L’attaque peut être directe dans la demande d’un utilisateur ou indirecte dans une source consultée. OWASP identifie l’injection de prompt parmi les risques des applications de modèles de langage. La question concerne l’architecture qui entoure le modèle, notamment lorsqu’une réponse peut conduire à une action ou à un accès supplémentaire.
Référence : OWASP — Sécurité des applications d’IA générative
Réduire ce que le système peut faire
Listez les outils nécessaires et leurs permissions. Un assistant qui prépare une réponse n’a pas forcément besoin d’envoyer des messages. Un outil de recherche documentaire n’a pas besoin d’un accès général à tous les fichiers de l’entreprise.
Limitez chaque opération côté serveur, avec des paramètres et des ressources autorisés. Une interdiction écrite dans un prompt ne remplace pas ces contrôles. Le modèle peut proposer une action ; l’application doit encore vérifier qu’elle correspond aux droits et au périmètre de l’utilisateur avant de l’exécuter.
Éviter les secrets dans le contexte inutile
Ne fournissez pas au modèle une information dont la tâche n’a pas besoin. Séparez les secrets techniques, les données accessibles à l’utilisateur et les textes publics. Une fois un contenu sensible introduit dans une génération, il devient plus difficile de garantir comment il influencera la réponse.
Appliquez les filtres d’accès avant la recherche ou la transmission des passages. Vérifiez aussi les journaux et les outils de suivi, qui peuvent conserver des informations reçues. La minimisation doit concerner le parcours entier, pas seulement le texte visible à l’écran.
Demander une validation compréhensible
Pour une action ayant un effet réel, montrez ce qui va changer : destinataire, contenu, dossier ou montant selon le cas. L’utilisateur doit pouvoir examiner et corriger la proposition. Une approbation vague ne permet pas de repérer une instruction parasite intégrée au résultat.
Gardez le contrôle côté application. Le simple fait que le modèle écrive « validé » ne doit pas satisfaire l’étape de confirmation. Distinguez le brouillon, la décision humaine et l’exécution technique. Cette séparation facilite aussi l’audit d’une opération et la reprise après erreur.
Tester les sources hostiles et les limites
Ajoutez des documents d’essai contenant des demandes contradictoires, des liens inattendus et des tentatives de faire utiliser un outil hors périmètre. Vérifiez le comportement obtenu avec les permissions effectives, et pas seulement le texte de réponse.
Ces essais ne prouvent pas que toutes les attaques possibles ont été couvertes. Ils permettent de corriger des chemins concrets et de suivre les régressions lors d’une évolution. Pour un premier projet, privilégiez un périmètre réduit avec des actions limitées et une supervision adaptée. La sécurité vient d’un ensemble de contrôles, pas d’une formule secrète ajoutée au prompt.
Sources et ressources
Les références soutiennent les faits ou méthodes cités ; les analyses et recommandations sont celles du journal Site en Or.