Qu’est-ce qu’une attaque par injection de prompt ?
Une attaque par injection de prompt se produit lorsqu’un attaquant envoie une entrée malveillante à un grand modèle de langage (LLM) afin de l’amener à répondre ou à se comporter d’une manière non prévue. Cette entrée contient souvent des commandes visant à contourner les consignes de sécurité et les instructions système du modèle. Les attaquants peuvent transmettre l’entrée malveillante directement (au moyen d’un prompt) ou indirectement (en intégrant des commandes dans des contenus traités par le modèle).
Comment fonctionne l’injection de prompt
L’injection de prompts exploite le fonctionnement même des grands modèles de langage (LLM). Ces modèles ont été conçus pour permettre aux développeurs de leur fournir des instructions en langage naturel afin d’accomplir des tâches. Cette capacité implique également qu’ils ne peuvent pas distinguer de manière fiable les instructions des autres entrées utilisateur lorsque celles-ci leur sont présentées ensemble. Un attaquant peut donc intégrer des commandes malveillantes dans un texte traité par le modèle et, en l’absence de mesures de protection appropriées, celui-ci peut suivre ces instructions malveillantes.
Injection directe ou indirecte de prompts
Les attaquants peuvent mener des attaques par injection de prompt directe ou injection de prompt indirecte. Bien que ces deux tactiques consistent à manipuler des modèles, elles diffèrent par la manière dont les commandes malveillantes sont transmises au modèle.
Dans le cas d’une injection de prompt directe, l’attaquant insère des commandes dans le prompt d’un modèle. Par exemple, il peut utiliser l’interface utilisateur d’un chatbot ou d’un moteur de recherche basé sur l’IA et saisir simplement des commandes destinées au modèle en langage naturel. Pour dissimuler ces instructions, l’attaquant peut recourir à un jeu de rôle (en demandant au modèle d’adopter un personnage qui n’est pas soumis aux règles de sécurité) ou présenter des scénarios hypothétiques (pour donner l’impression que l’interaction n’aura aucune conséquence dans le monde réel).
Si la tentative réussit, l’impact est immédiat. Les actions ou les résultats recherchés par l’attaquant se produisent dès que le prompt est envoyé.
On parle d’injection de prompt indirecte lorsqu’un attaquant intègre des commandes ou du contenu dans des éléments qui seront ingérés par un modèle d’IA. Il peut s’agir de pages web, de documents PDF importés, d’e-mails ou de fichiers stockés dans une base de données. L’attaquant peut dissimuler la charge utile dans du texte invisible (blanc sur blanc), des commentaires HTML ou des métadonnées. Lorsque le modèle ou l’agent ingère ces éléments, il ne distingue pas les données légitimes des commandes et exécute ces dernières.
Contrairement à l’injection de prompt directe, les effets des attaques indirectes sont différés et conditionnels. L’impact ne se fait sentir que lorsqu’un utilisateur ou un processus autonome amène le modèle ou l’agent à ingérer les données. Par exemple, un attaquant peut modifier un fichier stocké dans une base de données vectorielle utilisée pour la génération augmentée par récupération (RAG). Les commandes ne sont exécutées que lorsqu’un utilisateur saisit un prompt qui déclenche le processus de récupération.
Types d’attaques courants
Les attaquants peuvent recourir à diverses techniques d’injection de prompts en fonction de leurs objectifs et des types de systèmes d’IA auxquels ils sont confrontés. Voici trois des types d’attaques les plus courants :
Contournement des restrictions : une attaque visant à convaincre le modèle d’IA d’ignorer ses règles de sécurité. L’attaquant peut utiliser des scénarios fictifs ou demander au modèle d’adopter un personnage qui n’est pas soumis aux politiques en vigueur. Pour contourner les restrictions, les attaquants saisissent généralement leurs instructions directement dans les prompts du modèle. Leurs objectifs peuvent aller de la génération de réponses erronées à la divulgation d’informations sensibles.
Fuite de prompt : Tentative visant à révéler des informations confidentielles accessibles au système d’IA, telles que les prompts des développeurs, la logique opérationnelle, la propriété intellectuelle ou des identifiants exposés de manière inappropriée. Dans un prompt, l’attaquant peut demander au modèle d’afficher les instructions système ou d’inclure du texte traité avant la conversation en cours.
Contrebande de jetons : tentative de faire passer des commandes malveillantes à travers le filtre de sécurité initial d’une application d’IA. Les applications d’IA analysent souvent les données saisies afin d’y détecter des mots-clés ou une intention. Elles transmettent ensuite ces données à un système backend, qui décompose le texte en jetons envoyés au modèle. Dans le cadre de la contrebande de jetons, l’attaquant crée des invites qui passent le filtre de sécurité, mais qui sont ensuite converties en commandes lorsqu’elles parviennent au modèle.
Risques pour les entreprises
Les attaques par injection de prompts présentent un large éventail de risques graves pour les entreprises, en particulier à mesure que celles-ci intègrent davantage les systèmes d’IA à leurs processus critiques. Examinons quatre risques potentiels :
Exécution non autorisée d’outils ou d’API : Si un attaquant parvient à transmettre des commandes à un modèle, il pourrait être en mesure de manipuler non seulement le modèle, mais aussi les API et les systèmes qui y sont connectés. Par exemple, il pourrait amener une API à supprimer des enregistrements d’une base de données, à modifier les informations de clients dans un système de gestion de la relation client (CRM) ou à exécuter des transactions financières.
Exfiltration de données sensibles : Un attaquant utilisant l’injection de prompt pourrait contraindre les modèles à divulguer diverses données sensibles, allant de documents financiers d’entreprise et d’informations personnelles identifiables (PII) aux prompts système et autres éléments de propriété intellectuelle.
Hameçonnage automatisé : Les commandes utilisées par un attaquant pourraient amener un modèle ou un agent à envoyer automatiquement des e-mails à des clients ou à des employés depuis des comptes de messagerie d’entreprise. L’attaquant pourrait demander au modèle d’inclure des liens d’hameçonnage dans les messages.
Détournement de modèle : À l’aide de commandes appropriées, un attaquant pourrait complètement contourner la finalité prévue d’un modèle et détourner ses capacités à d’autres fins. Par exemple, il pourrait utiliser le modèle pour diffuser de fausses informations, effectuer des remboursements non autorisés ou inciter les utilisateurs à communiquer des informations personnelles.
Atténuation et défense en profondeur
L’adoption de quatre bonnes pratiques peut aider les organisations à mettre en place une approche de défense en profondeur qui prévient les attaques et en limite les dommages.
1. Mettre en œuvre des garde-fous doubles (en entrée et en sortie) : Les organisations doivent mettre en place des garde-fous pour l’IA au niveau des entrées afin de détecter les schémas susceptibles de signaler une injection de prompt. Parallèlement, elles doivent appliquer des garde-fous aux sorties afin de veiller à ce que les modèles et les agents ne divulguent pas d’informations sensibles, ne génèrent pas de spam et n’effectuent pas d’appels non autorisés vers d’autres systèmes.
2. Utiliser des jetons canaris : Les jetons canaris sont des marqueurs cachés dans les systèmes d’IA qui permettent de détecter rapidement une injection de prompt ou une fuite de données. Les développeurs peuvent faire en sorte qu’un jeton (une chaîne de données unique) apparaisse dans un prompt système, invisible pour les utilisateurs. Parallèlement, les équipes de sécurité surveillent en temps réel les résultats générés par le modèle. Si le jeton apparaît dans ces résultats, cela signifie qu’un attaquant a contraint le modèle à divulguer les instructions système.
3. Limiter les privilèges des modèles et des agents : L’injection de prompt est particulièrement dangereuse, car les attaquants peuvent contraindre les modèles et les agents à effectuer diverses actions non autorisées. Les organisations peuvent en limiter l’impact en restreignant les actions que les modèles et les agents peuvent exécuter automatiquement.
4. Maintenir une supervision humaine : En plus de limiter les privilèges des modèles et des agents, les organisations doivent veiller à ce qu’une intervention humaine soit maintenue pour les actions ou décisions importantes. Par exemple, elles pourraient mettre en place des politiques exigeant qu’une personne approuve les interactions des modèles avec certains systèmes ou examine les transactions financières déclenchées par des agents.
Questions fréququemment posées
Les pare-feu d’applications web (WAF) traditionnels peuvent-ils bloquer les attaques par injection de prompts ?
Les pare-feu d’applications web (WAF) traditionnels ne sont pas conçus pour détecter de manière fiable les attaques par injection de prompt. Les WAF sont conçus pour rechercher du code susceptible de signaler une attaque, mais les attaques par injection de prompt utilisent des instructions en langage naturel que les WAF ne considéreraient pas comme des menaces. En outre, les WAF ne pourraient pas protéger contre les injections de prompt indirectes, car ils se concentrent sur le trafic HTTP entrant et les requêtes des utilisateurs, et non sur les instructions intégrées à des sources tierces.
Comment les pipelines de génération augmentée par récupération (RAG) accroissent-ils les risques d’injection de prompt ?
Les pipelines de génération augmentée par récupération (RAG) offrent aux attaquants un autre moyen de transmettre des commandes malveillantes aux modèles. Les attaquants peuvent intégrer des commandes dans des fichiers stockés dans la base de données vectorielle utilisée par un système RAG. Lorsque le modèle récupère des informations dans la base de données, il ingère ces commandes et peut éventuellement les exécuter.
En quoi l’injection de prompt diffère-t-elle de l’empoisonnement des données RAG ?
L’empoisonnement des données de génération augmentée par récupération (RAG) consiste à introduire de fausses informations ou des biais dans une base de données avant l’inférence, afin que les modèles qui y récupèrent des informations produisent des résultats inexacts ou préjudiciables. L’injection de prompt consiste à fournir à un modèle des commandes ou du contenu malveillants au moment de l’inférence afin de l’amener à effectuer des actions non autorisées.
Le réglage fin d’un LLM peut-il empêcher les attaques par injection de prompt ?
Non, le réglage fin d’un grand modèle de langage (LLM) ne peut à lui seul empêcher complètement les attaques par injection de prompt, même s’il peut rendre les vulnérabilités plus difficiles à exploiter. Par exemple, les développeurs pourraient apprendre à un modèle à reconnaître certains schémas susceptibles de signaler une attaque. Cependant, les modèles étant conçus pour accepter des instructions en langage naturel, ils resteront vulnérables aux tentatives d’injection de prompt.
Qu’est-ce qu’un « jeton canari » et comment est-il utilisé pour protéger les LLM ?
Un jeton canari est une chaîne de données unique que les développeurs peuvent intégrer aux prompts système. Les utilisateurs légitimes ne voient jamais cette chaîne. Mais si un attaquant parvient à amener le modèle à divulguer les prompts système, celui-ci divulguera également le jeton canari par inadvertance. Lorsque les équipes qui surveillent en permanence les sorties des modèles détectent ce jeton, elles savent qu’une faille de sécurité est en cours.
Comment une entreprise peut-elle sécuriser les systèmes et applications d’IA pendant l’inférence et lors de leur exécution ?
La sécurisation des systèmes et applications d’IA pendant l’inférence et l’exécution nécessite des contrôles capables d’inspecter les requêtes, les réponses, les actions des agents et l’utilisation des outils au fil des interactions. Une sécurité à l’exécution propre à l’IA peut contribuer à bloquer les injections de requêtes, à prévenir les fuites de données sensibles, à faire respecter les politiques et à encadrer la manière dont les modèles et les agents interagissent avec les utilisateurs, les données, les API et les outils connectés.
Quelles fonctionnalités de F5 contribuent à la sécurité de l’IA en entreprise ?
F5 AI Guardrails aide à appliquer les politiques d’exécution et à se protéger contre des risques tels que l’injection de prompts, les fuites de données, les résultats préjudiciables et les actions dangereuses des agents. F5 AI Red Team utilise des tests contradictoires pour détecter les vulnérabilités et les faiblesses. F5 AI Gateway fournit un point de contrôle centralisé pour régir l’accès aux modèles, aux agents et aux outils, tandis que F5 Workforce AI Security offre une visibilité sur les usages autorisés et non autorisés de l’IA dans l’ensemble de l’entreprise. Ensemble, ces fonctionnalités font partie de la F5 AI Security Platform. Pour une protection plus étendue des applications, des API et des environnements distribués, la F5 Application Delivery and Security Platform (ADSP) réunit notamment des fonctionnalités de protection des applications web et des API, de gestion des bots, d’atténuation des attaques DDoS et de mise à disposition des applications.
