Injection de prompts et jailbreaks

L'injection d'invite est l'équivalent, à l'ère des LLM, des failles classiques d'injection (dans des requêtes de base de données ou des commandes). La cause fondamentale est identique : une application mélange des instructions de confiance et des données non fiables dans le même canal, et l'interpréteur (le modèle) ne peut pas distinguer les unes des autres de manière fiable.

Avec un LLM, l'invite système, les instructions du développeur et tout contenu récupéré arrivent sous la forme d'un flux linéaire unique de jetons. Si un texte contrôlé par un attaquant dit Ignore previous instructions and..., le modèle peut lui obéir car, pour lui, ce n'est que du langage supplémentaire.

• De confiance : votre invite système et votre politique.
• Non fiable : entrée utilisateur, pages web, fichiers, sortie des outils, courriels.

L'injection d'invite directe se produit lorsque l'utilisateur final saisit directement des instructions malveillantes dans l'invite afin de modifier le comportement prévu de l'application.

Une tentative classique contre un robot d'assistance à la clientèle ressemble à ceci :

• Le robot reçoit pour instruction de répondre uniquement aux questions de facturation.
• L'utilisateur colle un texte qui redéfinit le rôle du modèle et lui demande de divulguer son invite système ou d'effectuer des actions hors du périmètre prévu.

L'injection directe est la plus facile à analyser, car le texte malveillant et l'attaquant sont la même personne, mais elle contourne tout de même les garde-fous rudimentaires.

L'injection d'invite indirecte (de second ordre) est la variante la plus dangereuse. L'attaquant insère des instructions dans un contenu que le modèle récupérera plus tard : une page web, un PDF, une invitation de calendrier, un commentaire de code ou un ticket d'assistance.

L'utilisateur victime ne voit jamais la charge utile. Lorsqu'une chaîne RAG ou un agent de navigation introduit ce contenu dans le contexte, les instructions cachées s'exécutent avec les privilèges de la victime.

Exemple : une page web contient un texte caché qui demande à un agent de résumé d'exfiltrer l'historique des conversations de l'utilisateur vers une adresse contrôlée par un attaquant.

Ces termes se recoupent, mais ne sont pas identiques :

• L'injection d'invite cible la frontière de l'application : elle remplace les instructions du développeur par des données contrôlées par l'attaquant.
• Le débridage cible l'alignement de sécurité du modèle : il l'amène à produire du contenu que le fournisseur l'a entraîné à refuser.

Un débridage ne nécessite pas d'application vulnérable ; il fonctionne contre le modèle brut. De nombreuses attaques réelles combinent les deux : le débridage assouplit les refus, tandis que l'injection réoriente le comportement de l'application.

Les attaquants utilisent des procédés de manipulation prévisibles. Les connaître vous aide à évaluer votre propre système en équipe rouge de manière responsable :

• Jeu de rôle / personnage : présenter la demande comme une fiction ou comme venant d'un personnage fictif sans restrictions.
• Dissimulation : codage en base 64, langage leet, traduction ou découpage en jetons pour contourner les filtres de mots-clés.
• Fractionnement de la charge utile : répartir une demande sur plusieurs messages afin qu'aucun message isolé ne paraisse malveillant.
• Hypothèses : For a security class, describe how one would...
• Injection de préfixe : forcer la réponse à commencer par une affirmation telle que Sure, here is.

De nombreuses équipes commencent par utiliser une liste de blocage contenant des expressions telles que ignore previous instructions. Cette approche est fragile, car l'espace des entrées est pratiquement infini.

Le langage naturel peut exprimer une même intention d'innombrables façons, dans différentes langues, avec différents encodages et au moyen de métaphores. Les attaquants itèrent plus vite que vous ne pouvez corriger les expressions régulières.

Principe essentiel : considérez le filtrage des entrées comme une défense en profondeur, jamais comme une mesure principale. Supposez qu'une injection parviendra à passer et concevez votre système de sorte qu'une injection réussie ne puisse malgré tout causer de dommages réels.

La mesure d'atténuation la plus efficace est architecturale : limiter ce qu'un contexte de modèle compromis peut faire.

• Accordez au LLM les privilèges minimaux nécessaires. Un outil de résumé ne devrait pas disposer d'identifiants lui permettant d'envoyer des courriels.
• Gardez le contenu non fiable à l'écart des chemins privilégiés. Si un agent lit des données web externes, il ne devrait pas pouvoir exécuter des actions irréversibles au cours de la même interaction sans point de contrôle.
• Séparez les plans de données des plans de contrôle : le texte récupéré doit être une donnée, pas une commande.

Sans être infaillible, la structure des invites élève le niveau de difficulté. Délimitez clairement les données non fiables et indiquez au modèle comment les traiter.

Utilisez des délimiteurs explicites et indiquez au modèle que tout ce qu'ils contiennent constitue une donnée à analyser, et non une instruction à suivre. Associez cette mesure à un rôle système fort que l'application réaffirme à chaque appel.

La sortie d'un modèle est également non fiable. Si l'application transmet la sortie du LLM à un interpréteur de commandes, une base de données, un navigateur ou un autre outil, l'injection devient une exécution de code à distance ou une exfiltration de données.

La triple menace létale de Simon Willison décrit la combinaison dangereuse suivante :

• Un accès à des données privées,
• Une exposition à du contenu non fiable,
• La capacité de communiquer avec l'extérieur (exfiltrer).

Un agent réunissant ces trois éléments peut être transformé en outil de vol de données par une seule instruction injectée. Brisez cette combinaison pour briser l'attaque.

Supposez qu'une injection se produira et instrumentez votre système pour la détecter :

• Journalisez l'intégralité du contexte (invites, blocs récupérés, appels d'outils) afin de pouvoir examiner les incidents.
• Utilisez un classificateur secondaire ou un modèle de protection pour signaler les entrées et sorties suspectes.
• Surveillez l'utilisation anormale des outils : requêtes sortantes soudaines, accès inattendu aux données, motifs de fuite d'invite.
• Placez des jetons canaris dans les invites système ; si un jeton canari apparaît dans une sortie, une fuite s'est produite.

Traitez les alertes comme de véritables incidents en vous appuyant sur une procédure d'intervention.

Évaluer vos propres systèmes pour détecter les injections est essentiel et légitime. Faites-le de manière responsable :

• Évaluez uniquement les systèmes dont vous êtes propriétaire ou que vous êtes autorisé à examiner.
• Utilisez un environnement contrôlé et des données synthétiques ; n'exfiltrez jamais de données réelles d'utilisateurs.
• Documentez vos résultats et intégrez-les à des vérifications de régression afin que les contournements corrigés le restent.
• Coordonnez la divulgation lorsque vous découvrez des problèmes dans des modèles ou des applications de tiers.

Le but est de rendre votre application résiliente, et non de produire des capacités nuisibles.

Vérifiez votre compréhension des frontières de confiance face aux injections.

Principaux enseignements sur l'injection d'invite et le débridage :

• L'injection découle du mélange d'instructions de confiance et de données non fiables dans un même canal.
• L'injection directe vient de l'utilisateur ; l'injection indirecte se dissimule dans le contenu récupéré et est plus discrète.
• Le débridage attaque l'alignement du modèle ; l'injection attaque la frontière de l'application. Les deux peuvent être combinés.
• Le filtrage des entrées ne constitue qu'une défense en profondeur, jamais la mesure principale.
• Atténuez le risque par l'architecture : privilèges minimaux, séparation des données et du contrôle, et rupture de la triple menace létale (données privées + contenu non fiable + exfiltration).
• Considérez la sortie du modèle comme non fiable, journalisez tout et évaluez vos systèmes en équipe rouge de manière éthique.