Injection de prompt

Directe ou indirecte

L'injection directe vient de l'utilisateur : il écrit une instruction qui contredit le cadre prévu, par exemple pour obtenir une information réservée ou faire changer de rôle l'assistant. L'injection indirecte est plus retorse : l'instruction est cachée dans un contenu que le modèle doit lire, courriel, page web, pièce jointe, réponse d'API. L'utilisateur ne voit rien ; le modèle, lui, traite ce texte comme une consigne. La frontière entre les deux n'est pas technique mais organisationnelle : dans un cas l'utilisateur est complice, dans l'autre il est victime.

Le risque grandit avec les pouvoirs de l'agent. Un assistant qui se contente de répondre subit au pire une réponse erronée. Un agent qui lit la boîte de réception, consulte un site et envoie des courriels peut être amené à transmettre un document interne vers une adresse externe, ou à exécuter une action non demandée. Plus les outils sont nombreux, plus l'effet d'une instruction glissée peut être concret. Un agent limité à la lecture circonscrit les dégâts à une fuite d'information, grave mais réparable.

Pourquoi c'est difficile à filtrer

Le modèle ne distingue pas naturellement les instructions du contenu. Tout arrive dans la même fenêtre de contexte, sous forme de texte. Séparer les rôles par des balises aide, mais ne garantit rien : un texte malveillant peut imiter ces balises. Les filtres par mots-clés se contournent par reformulation, traduction, encodage ou simple changement de ton. Aucune parade connue ne supprime le risque à elle seule. Le modèle obéit à ce qui ressemble le plus à une consigne, et rien ne l'incite à douter d'un texte bien rédigé.

Le terrain évolue vite. Les attaques décrites par la recherche sont reprises et adaptées, souvent sous des formes anodines : une note de bas de page, un commentaire invisible, une consigne formulée comme une politesse. Un dispositif testé une fois ne reste pas sûr. La veille et les tests répétés font partie de l'hygiène du système, au même titre que les mises à jour logicielles. Un filtre trop large dégrade l'usage normal, et l'équipe le désactive : le remède devient alors plus coûteux que le mal.

Ce qu'on peut opposer

La première défense est le moindre privilège. Un agent doit accéder aux seules ressources dont il a besoin, avec un compte dédié, et non avec les droits d'un administrateur. Les actions sensibles, envoi, suppression, paiement, modification, passent par une confirmation humaine. Les outils appelables se limitent à une liste fermée, et les destinations autorisées à un périmètre connu. Une liste courte, revue régulièrement, réduit la surface d'attaque plus sûrement qu'un filtre ajouté après coup.

La seconde consiste à traiter tout contenu externe comme non fiable, au même titre qu'une pièce jointe suspecte. Cela implique de limiter ce qui est lu automatiquement, de journaliser les appels et leurs paramètres, et de relire les actions inhabituelles. Des tests d'intrusion ciblés, menés par une équipe interne ou un prestataire, révèlent les chemins les plus évidents. Prévoir quoi faire en cas d'incident complète le dispositif. La procédure précise qui coupe les accès, qui prévient les clients et qui conserve les journaux.