Prompt injection : comprendre le risque et protéger un agent IA

La prompt injection survient lorsqu’un contenu non fiable tente d’influencer le comportement d’un modèle ou d’un agent au-delà de la tâche prévue. Le risque n’est pas seulement qu’un chatbot réponde de manière étrange : si l’agent peut lire des données, appeler des outils ou agir sur un système tiers, une instruction cachée dans une page, un email ou un fichier peut l’inciter à faire une action non désirée.

Il n’existe pas de filtre magique qui rende toute injection impossible. La protection la plus solide combine des permissions minimales, une séparation claire entre instructions et données, des outils étroits, des validations indépendantes et une revue humaine des actions à impact.

Ce que vous allez apprendre

Vous allez identifier les surfaces où une injection peut apparaître, définir un contrat de confiance pour un agent, limiter les effets possibles d’une instruction hostile, ajouter des validations et tester les refus. Les exemples restent défensifs : ils montrent une demande hors périmètre sans fournir de technique d’évasion ou d’exploitation.

Prérequis

• Une description de la tâche de l’agent et de ses outils.
• Un inventaire des données qu’il lit : web, documents, emails, tickets ou bases.
• Une liste des actions qu’il peut réellement déclencher.
• Un environnement de test sans secret de production ni accès irréversible.
• Une personne responsable des validations d’actions sensibles.

Traitez les sources externes comme des données, même lorsqu’elles semblent fiables ou utiles. Leur contenu peut être modifié, malveillant ou simplement incompatible avec votre objectif.

1. Reconnaître les frontières de confiance

Un agent reçoit souvent plusieurs catégories d’information : des règles établies par l’équipe, une demande utilisateur, des documents à analyser et des résultats d’outils. Ces catégories ne doivent pas avoir la même autorité. Les règles d’exécution et les permissions sont définies par l’environnement ; un paragraphe dans un PDF ou le contenu d’un site ne peut pas les changer.

Une injection peut être directe, par exemple un texte qui demande à l’agent d’ignorer son objectif, ou indirecte, lorsqu’elle est cachée dans une source que l’agent consulte pour accomplir la tâche. Le contenu peut être accidentellement ambigu sans être malveillant. Dans les deux cas, la réponse défensive est la même : conserver l’objectif, limiter les outils et signaler l’anomalie.

Vérification : pour chaque source lue par l’agent, indiquez son origine, son niveau de confiance et les actions qu’elle ne doit jamais pouvoir autoriser.

2. Définir un contrat d’action

Écrivez ce que l’agent peut lire, les outils disponibles, les destinations réseau autorisées, le répertoire de sortie et les actions interdites. Une tâche comme « résumer des retours clients » ne justifie pas l’accès à une boîte mail entière, à un shell général ou à un compte de déploiement. La capacité d’action doit être plus petite que la capacité de raisonnement : l’agent peut analyser largement un corpus autorisé, mais il ne peut agir que par des interfaces limitées.

Ajoutez une règle de confirmation pour les actions irréversibles ou externes : supprimer, publier, acheter, modifier une permission, envoyer un message ou transmettre une donnée. L’agent peut préparer une proposition structurée ; une personne ou un système de validation indépendant confirme l’exécution.

Vérification : prenez une action sensible et cherchez quelle permission concrète l’autorise. Si une source de texte suffit à l’activer, l’interface est trop large.

3. Isoler données et outils

Évitez de donner à un agent un outil capable de tout faire quand une fonction ciblée suffit. Une recherche dans un corpus approuvé, une lecture de fichier sous un chemin précis ou une requête API en lecture sont plus faciles à contrôler qu’un accès total au système. Les sorties d’outils restent également des données non fiables : elles doivent respecter la même frontière que les documents entrants.

Séparez les secrets et les identités de service. Une tâche de résumé n’a pas besoin d’une clé qui modifie une base ou accède aux comptes utilisateurs. Les clés temporaires, scopes limités, quotas et expirations réduisent l’effet d’un appel imprévu. Un conteneur ou une sandbox peut aider, à condition de vérifier les volumes, réseau et permissions réellement accordés.

Vérification : essayez, dans un environnement de test, une demande qui vise un fichier hors périmètre ou une action d’écriture. L’outil doit refuser indépendamment de la formulation exacte de la demande.

4. Valider les sorties et actions

Ne laissez pas un texte généré devenir directement une commande, une requête de base ou une publication. Utilisez un format structuré, des schémas, des allowlists de paramètres et une validation métier avant l’exécution. Si l’agent propose un destinataire, une URL ou un identifiant, vérifiez qu’il appartient à la liste attendue plutôt que de faire confiance à une valeur présente dans le contexte.

Pour une action à forte conséquence, ajoutez une étape humaine ou un second système qui ne partage pas la même instruction. Cette validation doit examiner la demande, les paramètres et l’effet prévu, pas seulement un message « confirmé » généré par le modèle.

Vérification : créez un test où la sortie contient une destination non autorisée. Le validateur doit bloquer l’action même si la réponse de l’agent paraît convaincante.

5. Journaliser et répondre à une anomalie

Conservez des traces minimales : identifiant de tâche, source consultée, outils demandés, décisions de validation et action finale. Évitez de conserver des prompts complets ou des secrets sans nécessité. L’objectif est de comprendre pourquoi une action a été refusée ou exécutée, pas de créer un nouvel entrepôt de contenu sensible.

Lorsqu’une source semble demander une action hors contrat, arrêtez l’exécution sensible, isolez l’entrée pour examen et vérifiez les actions déjà réalisées. Si un secret ou une donnée a pu être exposé, appliquez votre procédure de révocation et d’incident. Ne réessayez pas automatiquement avec un prompt « plus fort » : cela ne change pas les permissions accordées.

Vérification : faites remonter une anomalie de test jusqu’au canal prévu, puis vérifiez qu’aucune action externe n’a été déclenchée pendant l’exercice.

Exemple défensif

Imaginez un agent chargé de résumer une documentation. L’un des documents contient une phrase demandant de rechercher un fichier de configuration ou d’envoyer son contenu à une adresse externe. L’agent correctement configuré continue le résumé ou signale le texte suspect ; son outil de lecture ne peut accéder qu’au corpus fourni et son outil réseau n’autorise pas la destination. La défense ne dépend donc pas de la reconnaissance parfaite de chaque phrase, mais de l’impossibilité technique d’étendre l’action.

Problèmes fréquents et solutions

On cherche un mot-clé interdit dans le prompt. Un filtre de mots seuls est contournable et peut bloquer du contenu légitime. Gardez-le éventuellement comme signal, mais fondez la sécurité sur les permissions et validations.

L’agent peut appeler un shell pour être flexible. Remplacez-le par des outils ciblés ou un environnement jetable. La flexibilité générale augmente fortement la surface d’action.

Une action est automatiquement déclenchée après une réponse. Ajoutez un schéma, une allowlist et une confirmation indépendante avant l’effet externe.

Les tests ne couvrent que les réponses attendues. Ajoutez des cas négatifs : source ambiguë, destination inconnue, demande d’élévation de privilège et donnée non autorisée.

FAQ

Peut-on éliminer toute prompt injection ?

Non. Il faut réduire l’impact potentiel avec des permissions minimales, des validations et une surveillance plutôt que promettre une détection parfaite.

Un prompt système suffit-il ?

Non. Les règles textuelles ne remplacent pas les contrôles techniques d’outils, de fichiers, de réseau et de secrets.

Les documents internes sont-ils fiables ?

Ils peuvent contenir une erreur, une donnée compromise ou une instruction inadaptée. Conservez la même frontière d’autorité pour tout contenu lu par l’agent.

Faut-il désactiver tous les outils ?

Non. Donnez les outils nécessaires, mais avec des interfaces, paramètres et identités les plus étroits possibles.

Que faire après une tentative suspecte ?

Arrêtez les actions sensibles, conservez les éléments nécessaires à l’analyse, vérifiez les effets, puis révoquez les accès potentiellement exposés selon votre procédure d’incident.

Conclusion

Comprendre la prompt injection, c’est accepter qu’un modèle puisse lire du contenu qui cherche à influencer sa tâche. La bonne défense ne repose pas sur une phrase parfaite : elle limite les permissions, valide les actions et prouve par des tests négatifs qu’un contenu non fiable ne peut pas étendre le périmètre de l’agent.

Sources et limites

Sources primaires : OWASP LLM01 Prompt Injection, OWASP Agentic AI Threats and Mitigations et NIST AI RMF. Les protections doivent être évaluées sur vos outils et données. Ce guide ne fournit pas de garantie d’absence d’injection ni une procédure de réponse à incident exhaustive.