Réduisez les risques d’injection de prompt dans votre assistant IA : droits limités, contrôle des actions, documents externes et tests avant déploiement.
Un assistant qui lit un e-mail ou un document peut y rencontrer du texte cherchant à modifier son comportement. Cette instruction ne provient pas forcément de la personne qui utilise l’outil. Elle peut être cachée dans une source que l’assistant consulte pour effectuer une tâche légitime.
OWASP décrit l’injection de prompt et sa forme indirecte, lorsque des instructions malveillantes arrivent à travers un contenu externe. Pour une PME, la question pratique est de savoir ce que l’assistant pourra consulter, transmettre ou modifier s’il suit une instruction indésirable.
Partir des actions autorisées
Listez les outils accessibles à l’assistant avec leurs effets. Lire une procédure, créer un brouillon et envoyer un message sont des opérations différentes. Le périmètre technique doit correspondre aux actions nécessaires au service rendu.
Un assistant chargé de retrouver une procédure n’a pas besoin d’un droit de modification sur tout l’espace documentaire. Un outil de préparation de réponse peut enregistrer un brouillon sans disposer du droit d’envoyer un e-mail. Faites vérifier ces droits sur les comptes réellement utilisés en production.
La fiche OWASP sur la sécurité des agents recommande notamment de limiter les permissions des outils et de contrôler les actions sensibles. Pour votre intégration, traduisez cette orientation en opérations autorisées et en refus testables côté application.
Maintenir les autorisations dans le logiciel
Le modèle peut proposer une action. Le serveur qui l’exécute doit contrôler l’utilisateur concerné, le dossier visé et les paramètres reçus. Une réponse du modèle affirmant qu’un accès est autorisé ne doit pas suffire à l’obtenir.
Exemple fictif : l’assistant prépare une réponse pour un dossier client. Le serveur récupère le destinataire depuis la fiche validée du dossier. Une adresse présente dans une pièce jointe ne remplace pas automatiquement ce destinataire. Si un changement est nécessaire, il suit le parcours métier prévu et reste visible au responsable.
Conservez ces contrôles lorsque l’interface évolue. L’ajout d’un nouvel outil peut élargir les conséquences possibles d’une mauvaise instruction, même si le texte du prompt principal reste inchangé. Révisez les permissions avec chaque changement de capacité.
Identifier les contenus qui viennent de l’extérieur
Dans votre architecture, gardez la provenance des documents et des résultats récupérés. Un passage issu d’un site web, d’une pièce jointe ou d’un commentaire client doit être traité comme un contenu à analyser. Il ne reçoit pas l’autorité des règles de votre application.
Le prompt peut expliquer cette distinction, mais il ne garantit pas à lui seul que le modèle la respectera. Prévoyez aussi une validation des sorties et des limites techniques sur les opérations disponibles. Les filtres de texte peuvent aider à détecter certains cas ; leur absence d’alerte ne prouve pas qu’un document est sûr.
Pour un assistant RAG documentaire, contrôlez les personnes autorisées à publier dans les sources indexées. Une source interne peut contenir du texte importé de l’extérieur. Son emplacement dans un dossier partagé ne suffit pas à établir sa fiabilité.
Montrer précisément ce que l’utilisateur approuve
Pour une action soumise à validation, présentez le destinataire, les données envoyées et l’effet attendu. Un bouton « continuer » sans ce contexte ne permet pas de repérer une modification inattendue.
Associez l’approbation à une version précise de l’action. Si le modèle régénère le message ou si un paramètre change après la validation, demandez une nouvelle décision. Prévoyez également une expiration lorsque le contexte métier peut évoluer pendant l’attente.
La relecture doit être proportionnée à la charge. Si des centaines de demandes identiques arrivent sans information permettant de distinguer les cas, les utilisateurs risquent de valider mécaniquement. Réduisez le périmètre automatisé ou améliorez l’écran avant d’en faire un contrôle central.
Construire une recette avec des données fictives
Testez l’assistant dans un environnement isolé, avec des documents et des destinataires de test. Un scénario peut vérifier qu’une instruction insérée dans une pièce jointe ne change pas le destinataire d’un brouillon. Un autre contrôle qu’un texte prétendant accorder des droits n’ouvre pas un document interdit.
Évaluez le résultat dans les applications connectées. Un message de refus dans la conversation ne suffit pas si une action a été exécutée en arrière-plan. Consultez les journaux des outils et vérifiez les objets créés ou modifiés.
Ajoutez des cas dans les langues utilisées par votre entreprise et sur les formats réellement acceptés. Gardez des tests ordinaires à côté de ces scénarios : des protections trop larges peuvent bloquer des documents légitimes et pousser l’équipe à contourner le processus.
Préparer la suspension et l’analyse d’un incident
Désignez la personne capable de désactiver un outil ou un flux. Elle doit pouvoir arrêter les actions externes sans attendre une modification du modèle. Définissez le traitement des demandes en cours et le message présenté aux utilisateurs.
Conservez les références nécessaires pour reconstituer la chaîne : demande, sources consultées, proposition d’action et résultat de l’outil. Limitez l’accès à ces traces et évitez d’y ajouter des secrets. Après correction, rejouez le cas qui a déclenché l’incident ainsi que les opérations normales concernées.
Ces mesures réduisent l’exposition sans supprimer tout risque. Pour cadrer une automatisation IA en entreprise, préparez la liste des sources et des actions envisagées. Elle permettra de définir les contrôles d’accès, les validations et la procédure de reprise avant d’ouvrir le service aux utilisateurs.