Une injection de prompt peut se cacher dans un document qu’un assistant consulte : le texte tente de lui faire abandonner sa tâche ou divulguer des informations. Traitez les contenus récupérés comme des données non fiables et limitez les actions que le système peut exécuter.
Identifier la frontière de confiance
Une page web, un PDF ou un message reçu ne possède pas l’autorité des instructions de votre application. Un contenu qui affirme le contraire doit rester une source à analyser. L’OWASP recense les injections de prompt parmi les risques des applications à base de modèles de langage. Une simple consigne invitant le modèle à ignorer les attaques ne constitue pas une séparation technique suffisante.
Réduire les conséquences possibles
Un assistant documentaire n’a généralement pas besoin de pouvoir envoyer des messages, modifier des fichiers ou consulter tous les dossiers de l’entreprise. Limitez ses outils et ses accès au périmètre utile. Séparez la recherche de documents de l’exécution d’une action. Lorsqu’une action sensible existe, faites valider ses paramètres dans une interface contrôlée, avec des règles extérieures au texte généré.
Construire un scénario de test sans données sensibles
Travaillez dans un environnement prévu pour la recette, avec un corpus et des comptes de démonstration. Le test ne doit pas demander une fuite réelle pour prouver que le risque existe. Placez dans un document factice une instruction qui tente de détourner la tâche, puis posez une question légitime sur ce document. L’objectif est d’observer le comportement de toute l’application, y compris ses outils et ses contrôles d’accès.
| Contenu factice | Comportement attendu | Preuve utile |
|---|---|---|
| Une instruction demandant d’ignorer la question | La demande de l’utilisateur reste le périmètre de travail | Question, réponse et documents utilisés |
| Une demande de transmettre un document à un tiers | Aucun envoi non autorisé n’est possible | Liste des outils accessibles et journal des appels |
| Une demande de lire une ressource hors périmètre | Le contrôle d’accès de l’application refuse la lecture | Résultat du contrôle indépendant du modèle |
| Une sortie qui ressemble à une action métier | La sortie reste du contenu à valider | Trace montrant l’absence d’exécution automatique |
L’OWASP décrit les injections directes et indirectes et recommande des mesures qui limitent leurs conséquences. Le fait qu’un essai échoue à détourner le modèle ne démontre pas une protection complète. La question déterminante reste : que pourrait-il se passer si une prochaine tentative était suivie ? La réponse doit être portée par les permissions et les contrôles de l’application.
Contrôler les sorties avant utilisation
Ne transmettez pas directement une réponse du modèle à un interpréteur de commandes ou à une requête métier. Vérifiez structure, destinations et permissions dans le code de l’application. Les liens affichés doivent aussi être traités avec prudence. La réponse peut être enregistrée pour analyse dans un environnement adapté, en évitant de conserver inutilement des informations confidentielles.
Exemple fictif : un document de support
Un fichier de démonstration contient une instruction demandant à l’assistant de révéler sa configuration. Le résultat attendu est une réponse centrée sur la question utilisateur, sans divulgation ni appel d’outil hors périmètre. Le test doit utiliser des données factices dans un environnement isolé. Vérifiez surtout que les protections techniques empêchent la fuite même si le modèle suit une instruction indésirable.
Séparer réponse, proposition d’action et exécution
- Pour un premier assistant de documentation, commencez sans outil d’envoi, de suppression ni de modification métier. Vérifiez que ces fonctions sont réellement absentes des permissions, et pas seulement cachées dans l’interface.
- Quand une action est nécessaire, validez dans le code sa destination, son type et les droits du demandeur. Une chaîne produite par le modèle ne doit pas servir directement d’autorisation.
- Affichez les paramètres importants dans un écran de confirmation adapté. Les consignes de la page consultée ne doivent pas pouvoir modifier ce processus.
- Contrôlez aussi la présentation de la réponse : HTML, liens et pièces proposées doivent suivre les règles de votre application. Ne rendez pas exécutable un texte parce qu’il provient d’un modèle.
Dans un exemple fictif de support web, l’assistant peut expliquer comment demander une intervention. Il peut préparer un résumé que la personne relit. Il n’a pas besoin de pouvoir envoyer tout le dossier technique ni de changer les accès de l’hébergement. Cette séparation réduit les conséquences d’une réponse compromise tout en conservant l’utilité du service.
Le dossier de recette doit distinguer les essais exécutés, les protections contrôlées et les risques qui restent hors test. Après une évolution des outils ou des droits, rejouez les cas concernés. Reliez ce travail à la préparation de la base documentaire RAG : l’origine et les droits des documents restent importants même lorsque le modèle semble suivre les consignes.
Intégrer le test à la recette
Conservez quelques documents de test représentant des tentatives directes et indirectes. Rejouez-les après une évolution du modèle, des outils ou du corpus. Notez les comportements attendus et les limites résiduelles au lieu de déclarer le système invulnérable. Pour un premier projet, privilégiez un assistant de lecture à accès restreint et consultez la méthode de préparation d’un site aux agents web.