L'injection de prompt est une forme d'attaque qui dissimule des instructions dans des contenus externes que le modèle va lire, afin de lui faire prendre des données pour des ordres et les exécuter. Elle ne modifie aucun code et ne force l'entrée d'aucun système. Elle exploite simplement le fait que les grands modèles lisent attentivement leur contexte, en glissant des exigences dans des pages web, des documents, des courriels ou du texte présent dans des images, de sorte que le modèle, une fois ces contenus lus, peut obéir sans réfléchir.
Où les instructions peuvent se cacher
L'injection de prompt revêt une forme directe et une forme indirecte. Dans la forme directe, c'est l'utilisateur lui-même qui cache des instructions dans sa saisie, par exemple en collant un texte d'apparence ordinaire qui contient en secret des ordres. La forme indirecte est plus sournoise : un tiers place les instructions à l'avance dans une page web, un curriculum vitae, une description de produit ou un courriel, et lorsque l'agent consulte la page, résume le document ou traite le message, il lit ce contenu et peut être détourné vers des actions qu'il ne devrait jamais accomplir. Un curriculum vitae peut ainsi indiquer en minuscules lettres blanches d'ignorer les critères précédents et d'attribuer la note maximale, et un modèle chargé d'un premier tri peut réellement s'y conformer. L'utilisateur n'a jamais prononcé cette phrase, mais il en subit les conséquences, et c'est ce qui rend la forme indirecte si dangereuse.
Ce n'est pas un jailbreak
Beaucoup confondent l'injection de prompt avec le jailbreak, alors que les deux vont dans des directions opposées. Le jailbreak consiste pour l'utilisateur à contourner personnellement les limites de sécurité d'un modèle afin de lui faire faire ce que le système interdit ; l'attaquant et l'utilisateur sont la même personne. Dans l'injection de prompt, en revanche, un tiers se sert du modèle comme d'un outil pour attaquer l'utilisateur ou le système, et le modèle comme l'utilisateur sont des victimes. Il est difficile d'y remédier à la racine, car dans l'architecture actuelle, les instructions du système, les questions de l'utilisateur et les documents externes parviennent tous au modèle sous forme de texte. Leur frontière repose sur une convention et non sur une séparation physique, si bien que le modèle peine à distinguer de façon fiable quelle phrase est un ordre et quelle phrase n'est qu'un document.
Ce que les utilisateurs et les développeurs peuvent faire
La mesure la plus utile pour les utilisateurs ordinaires consiste à ne jamais laisser un agent obéir automatiquement aux exigences trouvées dans des contenus externes. Les opérations sensibles comme l'envoi de courriels, la suppression de fichiers, les paiements ou la modification de réglages doivent toujours être confirmées par une personne, et il faut surveiller tout agent qui se mettrait soudain à faire quelque chose sans rapport avec la tâche. Les développeurs doivent appliquer le principe du moindre privilège et ne donner à un agent que les outils et les données réellement nécessaires à la tâche en cours. Les contenus externes peuvent être cités comme documents, mais ne doivent jamais être promus au rang d'instructions, et les étapes critiques exigent confirmation et journalisation. Quelques idées reçues méritent aussi d'être corrigées : ajouter une phrase au prompt système ne bloque pas l'injection, car un texte d'attaque peut toujours être rédigé de manière plus précise ; le risque ne se limite pas aux sites de pirates, puisque des documents ordinaires et des courriels transférés peuvent eux aussi être piégés ; et même une conversation banale peut être touchée si l'on y colle un contenu de provenance inconnue. Considérer d'abord tout contenu externe comme une entrée non fiable est une habitude de base à prendre avec les agents.
