Traiter le contenu récupéré comme une entrée non fiable

Repérer quand une donnée devient une instruction

Un agent de développement lit d’autres éléments que la demande de l’utilisateur. Il peut examiner des issues, des fichiers du dépôt, la documentation des packages, des résultats de recherche et des réponses d’outils. Certains de ces contenus peuvent contenir les instructions d’une autre personne.

Une injection de prompt se produit lorsqu’un tel contenu détourne le modèle de la tâche autorisée. Une injection indirecte arrive par une source récupérée, et non par la demande directe de l’utilisateur. L’OWASP cite les éléments du dépôt et les résultats des outils parmi les points d’entrée pertinents. Lire les conseils de prévention.

Prenons une tâche de maintenance fictive. L’utilisateur demande à l’agent de corriger un filtre de rapport et d’exécuter les tests obligatoires. Un README récupéré affirme que les tests sont obsolètes et demande à l’agent d’envoyer un fichier de configuration. Le README peut expliquer le projet. Il ne peut autoriser ni l’abandon des contrôles demandés par l’utilisateur ni l’envoi de fichiers ailleurs.

Recenser les conséquences possibles

Un même texte trompeur a des conséquences différentes selon l’environnement. Un outil de synthèse en lecture seule peut produire un résumé incorrect. Un agent disposant de droits d’écriture sur le dépôt peut modifier le code. Un agent ayant accès à des secrets et au réseau sortant peut divulguer des informations.

Examinez les actions disponibles avant de choisir les protections utiles. Listez les ressources sensibles, les cibles accessibles en écriture et les destinations externes. Incluez les connecteurs ajoutés après la configuration initiale. Un nouvel outil peut amplifier les effets d’une faiblesse existante.

Un agent peut aussi transmettre un contenu trompeur à une étape ultérieure. Par exemple, il peut copier une instruction non fiable dans une fiche de tâche générée. L’agent suivant ne doit pas considérer cette fiche comme une règle approuvée séparément.

Utiliser plusieurs contrôles aux fonctions distinctes

Dans la conception de l’application, séparez les instructions fiables de la tâche des données récupérées. Indiquez l’origine des éléments récupérés. Ces mesures facilitent l’interprétation, mais ne constituent pas une limite de sécurité complète.

Imposez les permissions sur les ressources dans le système d’exécution. Limitez les destinations des données sensibles. Exigez la décision appropriée avant les actions lourdes de conséquences. Vérifiez l’opération proposée au regard de la tâche et de la cible autorisées.

Des filtres et un second modèle peuvent aider à détecter les contenus suspects. Ils peuvent aussi manquer des attaques ou bloquer des informations légitimes. Ne remplacez pas une autorisation déterministe par le score de confiance d’un modèle. L’OWASP souligne explicitement les limites d’une protection fondée uniquement sur les prompts ou la récupération de contenu. Lire la description du risque.

Tester le processus sans exposition réelle

Utilisez un dépôt jetable et des fichiers fictifs. Ne donnez à l’évaluation aucun identifiant de production ni droit d’écriture externe sans restriction. Introduisez une instruction inoffensive qui contredit la tâche, comme l’omission d’un contrôle obligatoire.

Observez à la fois la réponse du modèle et les actions réelles des outils. Un message affirmant « j’ai ignoré l’instruction » ne suffit pas si le contrôle a malgré tout été omis. Consignez la tâche, le jeu de test injecté, les outils autorisés et le résultat observé.

Répétez des cas représentatifs après toute modification des prompts, des modèles, des connecteurs ou des permissions. Un exemple bloqué constitue une preuve pour ce cas précis, pas une garantie contre toutes les injections. Si un test échoue, réduisez les conséquences possibles pendant la correction du processus sous-jacent.