Comment protéger son IA des attaques par prompt injection ?
L'IA générative, un colosse aux pieds d'argile ? L'injection de prompt, ou prompt injection en anglais, reste en 2024 la principale faiblesse des modèles génératifs, notamment les grands modèles de langage. Vecteurs, mesures préventives… On vous explique tout ce qu'il faut savoir pour limiter les risques sur un système déployé en entreprise.
Qu'est-ce qu'une prompt injection ?
L'expression "prompt injection" est directement dérivée du jargon cyber, où l'on utilisait le terme de "SQL injection" pour évoquer une vulnérabilité de sécurité dans les applications web, où un attaquant pouvait insérer ou manipuler des requêtes SQL en introduisant un code malveillant dans les inputs de l'application (formulaire, url, cookies…). De la même manière, l'injection de prompt consiste à introduire des commandes malveillantes ou trompeuses dans les entrées d'un système d'IA générative. L'objectif est de manipuler le modèle pour qu'il produise des résultats non désirés, potentiellement dangereux ou contraires à son fonctionnement normal.
Les vecteurs d'attaque sont nombreux. Parmi les techniques courantes, on trouve l'insertion de directives cachées dans des textes en apparence anodins, l'utilisation de caractères spéciaux ou invisibles pour tromper les filtres, ou encore l'exploitation des biais linguistiques du modèle. Les attaquants peuvent également jouer sur l'ambiguïté sémantique, en formulant des phrases qui ont un double sens pour l'IA mais pas pour un lecteur humain. Plus insidieux encore, certains exploitent la capacité de l'IA à comprendre des contextes complexes en construisant des scénarios élaborés qui amènent progressivement le modèle à outrepasser ses garde-fous sécuritaires.
Avec le développement des nouvelles modalités au sein des LLM (images, sons, vidéos), les vecteurs d'attaque s'élargissent encore. Les attaquants peuvent désormais exploiter des images contenant des éléments subliminaux, des messages audios inaudibles pour l'humain mais détectables par l'IA, ou encore des séquences vidéo conçues pour exploiter les biais de perception du modèle.
Des conséquences parfois désastreuses
Bien que la majorité du temps, l'injection de prompt résulte sur un comportement inattendu du modèle sur une tâche donnée, certains s'avèrent plus critiques pour les entreprises victimes. "On distingue principalement deux types : les effets directs et indirects. L'injection directe se produit lorsque vous envoyez un prompt malveillant qui a une conséquence immédiate sur la réponse du modèle de langage (LLM). Le résultat indésirable apparaît directement dans la réponse générée. L'injection indirecte, quant à elle, est devenue plus préoccupante depuis que nous avons commencé à accorder aux modèles le droit d'utiliser des outils et d'effectuer des actions. Dans ce cas, le comportement non souhaité se manifeste dans l'utilisation de ces fonctionnalités supplémentaires", explique Nicolas Cavallo, head of generative AI chez OCTO Technology.
Très concrètement, une prompt injection peut conduire à une fuite de données dans le cas d'un agent connecté au web (via une messagerie ou un crawler web par exemple), ou plus classiquement du prompt system, d'une importance plus relative. Le risque de fuite de données grandit de jour en jour en raison de l'accès toujours plus important des LLM aux données de l'entreprise, notamment en configuration RAG.
"Un exemple concret est l'accès aux e-mails. Si un modèle a le droit de lire et d'écrire des e-mails, cela ouvre la porte à de nombreuses problématiques. On pourrait, par exemple, envoyer un e-mail contenant une injection de prompt, que le modèle lirait puis exécuterait, potentiellement en envoyant des informations sensibles", illustre le spécialiste.
Comment se protéger des prompts injections ?
La première étape pour se protéger consiste à configurer les permissions d'accès du système de RAG pour éviter que le LLM n'ait accès à des données trop sensibles. L'autre mesure régulièrement conseillée reste de configurer des instructions spécifiques dans le prompt system en indiquant clairement au modèle ce qu'il a le droit de faire ou non et les potentiels pièges dans lesquels il pourrait tomber. Mais ces deux précautions ne suffisent pas. Les attaquants parviennent aujourd'hui à bypasser assez facilement les instructions initiales en développant continuellement de nouvelles méthodes.
La technique ultime de prévention consiste à contrôler systématiquement les entrées envoyées au modèle et les sorties générées. Deux méthodes existent : l'utilisation de filtre sécurité ou le recours à un modèle évaluateur. La première consiste à utiliser les principaux filtres de sécurité mis à disposition par les éditeurs (OpenAI, Microsoft, Google, Amazon). Ces derniers permettent de filtrer de manière plutôt efficace la majorité des tentatives d'injection. Enfin l'utilisation d'un modèle tiers ou modèle évaluateur permet de faire contrôler par un modèle plus petit la nature des données adressées et générées par le LLM. Son coût est en revanche plus élevé.
Pour éviter des actions non désirées déclenchées par le LLM, Nicolas Cavallo préconise également l'ajout d'un module complémentaire pour valider humainement l'action du modèle, si le cas d'usage le permet. "Dans le contexte actuel des agents IA capables d'exécuter du code, nous demandons souvent à l'utilisateur de vérifier le code avant son exécution. Ce n'est pas toujours simple, mais c'est une précaution nécessaire. Cette étape de validation est essentielle pour les actions importantes, comme l'envoi de messages par exemple", détaille-t-il.
Pour une sécurité encore plus accrue, il est possible, sur un modèle open source, de procéder à un RLHF (apprentissage par renforcement à partir de rétroaction humaine). "Le RLHF peut être envisageable pour établir des garde-fous, en indiquant au modèle quelles réponses sont acceptables ou non. Cela fait partie de ce qu'on appelle l'alignement. C'est là qu'on définit ce que le modèle ne doit pas faire, notamment en termes de modération. L'alignement permet également de gérer les réponses du modèle à des demandes inappropriées ou dangereuses", rappelle Nicolas Cavallo. Le RLHF est notamment utile pour aligner les modèles et les configurer de manière à ce qu'ils refusent automatiquement les requêtes suspectes au sein d'un système d'agent.
De manière plus générale il est cohérent de mener des tests avant la phase de déploiement et en production pour corriger les éventuelles failles relevées par la ou les équipes de red teaming. Mais là encore, "il faut trouver un équilibre entre la fréquence et le coût des tests, car tester des modèles d'IA peut rapidement devenir onéreux. C'est pourquoi on utilise souvent une approche pyramidale des tests, avec des tests moins coûteux effectués plus fréquemment."