Qu’est-ce que l’injection de prompt ?

Les attaques par injection de prompt utilisent des requêtes malveillantes et élaborées pour tromper un LLM afin qu’il prenne une action indésirable. Par exemple, un attaquant pourrait convaincre le système GenAI d’ignorer les garde-fous ou les politiques d’entreprise et de générer des types de contenu non approuvés.

Avec l’intégration généralisée de GenAI et des agents IA dans les flux de travail des entreprises, les attaques par injection de prompt représentent un risque significatif pour la fiabilité et la sécurité des services. Les attaquants peuvent tromper les agents pour qu’ils prennent des actions menant à des violations de données, des infections par des logiciels malveillants ou d’autres incidents de sécurité.

Points clés

• L’injection de prompt manipule les instructions du modèle pour déclencher des sorties non sécurisées, une exposition de données ou des actions non intentionnelles.
• L’injection de prompt indirecte peut se produire par le biais de contenus non fiables tels que des pages web, des documents, des courriels, des tickets ou des journaux de discussion.
• Le risque augmente lorsque les modèles peuvent utiliser des outils, accéder à des sources de données ou prendre des actions.
• Les mesures d’atténuation sont superposées. Les contrôles d’entrée et de sortie aident, mais la « prévention parfaite » n’est pas une hypothèse réaliste.
• L’objectif est de réduire le rayon d’explosion en utilisant le principe du moindre privilège, des frontières de données solides et des étapes de vérification pour les actions sensibles.

Comment fonctionne l’injection de prompt en pratique ?

Les LLM ont généralement des instructions et des garde-fous en place pour contrôler leur fonctionnement. Les créateurs de LLM intègrent certaines protections, et les entreprises ajoutent leurs propres instructions en configurant des outils pour effectuer diverses tâches dans leurs environnements.

Les attaques par injection de prompt utilisent des entrées soigneusement élaborées conçues pour contourner ces garde-fous et réaliser quelque chose qui bénéficie à l’attaquant, comme voler des données sensibles, produire des sorties violant les politiques ou déclencher des actions dans des outils connectés. Ces entrées peuvent être fournies directement à l’outil ou intégrées dans d’autres contenus qu’il consomme, tels que des documents récupérés par RAG ou des pages web que visite un agent.

Injection de prompt directe

L’injection de prompt directe implique que l’attaquant interagisse directement avec l’agent. Par exemple, un attaquant pourrait entrer des prompts dans un chatbot LLM. Ces invites malveillantes peuvent suivre divers schémas, tels que :

• Ignorer les instructions précédentes
• Jeux de rôle coercitifs
• Mode développeur
• Langage de contournement de la politique

L’objectif de ces instructions est de faire en sorte que l’invite de l’attaquant soit priorisée par rapport aux garde-fous du LLM, soit en exploitant une faille, soit en étant perçue comme plus importante par le LLM. Si cela réussit, le LLM peut générer du contenu non autorisé, divulguer des instructions cachées, fournir des recommandations dangereuses ou rediriger des actions vers le mauvais outil ou utilisateur.

Injection de prompt indirecte

Les attaques par injection de prompt indirecte insèrent des instructions malveillantes dans le contenu qu’un modèle consomme plutôt que des instructions directes. Ceci pourrait inclure :

• Webpages
• Documents
• E-mails
• Tickets informatiques
• Transcriptions de chat
• Bases de connaissances

Ces menaces sont plus significatives si un LLM accède à du contenu externe, soit via un RAG, soit en naviguant sur le web à la recherche de réponses potentielles, puisque les données récupérées sont traitées comme un contexte par le LLM. Des instructions malveillantes peuvent littéralement être cachées dans le contenu, par exemple en utilisant du texte blanc pour rendre les instructions invisibles aux lecteurs humains ou en utilisant un texte ayant l’apparence inoffensive que le modèle interprète comme des instructions.

Les principaux types d’attaques par injection de prompt

Les attaques par injection de prompt peuvent être réalisées pour atteindre divers objectifs. Deux des principaux types d’attaques tentent d’accéder à des informations sensibles concernant l’invite système ou de manipuler l’utilisation des outils d’une IA pour collecter des informations sensibles ou effectuer des actions nuisibles.

Fuite de prompt et extraction de l’invite système

Certaines attaques sont conçues pour accéder à l’invite système, qui peut inclure des données sensibles, telles que des instructions système cachées, des politiques ou des secrets. Cette information peut être utile à un attaquant car elle lui permet de concevoir des attaques ultérieures qui contournent ces défenses.

Le potentiel de fuite de prompts signifie que des secrets ne devraient jamais être intégrés dans des prompts. Des garde-fous de sécurité tels que des instructions de « non-révélation » peuvent être contournés ou neutralisés par un attaquant.

Détournement d’outils et d’agents

Les outils d’IA peuvent être capables d’appeler des fonctions ou des API, de naviguer sur Internet ou de déclencher des flux de travail. Un prompt soigneusement élaboré peut permettre à un attaquant de définir quels outils sont sélectionnés, les paramètres qui leur sont envoyés et la séquence dans laquelle les actions sont appelées.

Cela pose un risque qu’un attaquant puisse accéder à des données sensibles lors d’appels à des systèmes de billetterie, des CRM, des magasins de documents, des dépôts de code ou des consoles cloud. Pour gérer ce risque, les organisations devraient mettre en œuvre des contrôles d’accès au moindre privilège et des portes d’approbation avec intervention humaine pour les actions à fort impact, en particulier pour les agents d’IA qui opèrent sans supervision humaine.

Où l’injection de prompts se manifeste-t-elle dans les environnements d’entreprise ?

Des attaques par injection de prompts peuvent se produire partout où une organisation utilise GenAI. Des exemples courants incluent :

• Outils de chat publics
• Assistants intégrés
• Bots de support client
• Assistants de connaissance internes
• Copilotes de développeur
• Agents autonomes

Même si les utilisateurs n’interagissent pas directement avec ces outils, l’injection de prompts reste un risque. Les outils peuvent accéder à du contenu web, des pièces jointes, des journaux collés, des commentaires de SaaS tiers et d’autres entrées non fiables qui pourraient inclure des instructions malveillantes.

Chatbots et assistants orientés client

Les chatbots et les agents en contact avec les clients acceptent des entrées de texte libre de la part d’utilisateurs inconnus. Des attaques réussies d’injection de prompt pourraient impliquer la manipulation des résultats pour induire les clients en erreur et une exposition potentielle de données si le bot a accès au CRM ou aux systèmes de commande.

Pour gérer ces risques, les organisations devraient mettre en œuvre des portées de données strictes, masquer les données sensibles lorsque cela est possible, et spécifier des réponses types pour les demandes sensibles. De plus, ces outils devraient être surveillés pour détecter des signes d’abus potentiel, y compris les taux de demande, la répétition et la similarité des charges utiles.

RAG et assistants « Demandez à votre base de connaissances »

Les assistants RAG et « demandez à votre base de connaissances » ont la capacité d’accéder à des documents et à d’autres contenus qui pourraient être élevés au-dessus de la politique d’entreprise dans le cadre du contexte du LLM. En conséquence, un contenu malveillant intégré dans des pages web et d’autres ressources peut permettre à un attaquant d’échapper aux garde-fous.

Les organisations peuvent atténuer ces risques en mettant en œuvre un étiquetage de contenu, des listes blanches de récupération et une compartimentation des prompts. De plus, des contrôles d’accès basés sur le principe du moindre privilège limitent les données auxquelles ces outils peuvent accéder, réduisant ainsi les impacts potentiels d’une attaque.

Impacts de l’injection de prompt sur la sécurité des entreprises

Les attaques par injection de prompt peuvent influencer les outils alimentés par l’IA à faire le souhait de l’attaquant. Cela peut introduire des menaces significatives pour la confidentialité, l’intégrité et la disponibilité en raison du potentiel de violations de données, de résultats manipulés et de flux de travail corrompus.

Une attaque réussie par injection de prompt peut être difficile à enquêter en raison de l’utilisation d’outils légitimes et de la visibilité limitée sur ces outils. Cela pose également un risque significatif pour la conformité réglementaire si les organisations manquent de données pour prouver ce qui s’est passé et l’étendue de l’incident.

Impacts commerciaux courants

Les attaques par injection de prompt peuvent avoir une variété d’impacts différents sur l’entreprise, y compris :

• Fuite de données clients
• Exposition de la propriété intellectuelle (PI)
• Temps d’arrêt du service
• Réponses incorrectes aux demandes des clients
• Prise de décision basée sur des données inexactes
• Dommages réputationnels et financiers
• Pénalités réglementaires et exposition légale

Comment détecter l’injection de prompt ?

La détection de l’injection de prompt nécessite d’analyser les entrées, les sorties et le comportement des LLM pour identifier les anomalies ou les violations de la politique d’entreprise. Pour ce faire, les organisations doivent enregistrer les prompts, les réponses et les appels d’outils pour le suivi. L’analyse doit rechercher des anomalies, des violations de politique et des motifs de charge utile répétés.

Indicateurs dans les Prompts, le Contexte et les Appels d’Outils

Les prompts, le contexte et les appels d’outils peuvent inclure des indicateurs d’attaques par injection de prompt. Les éléments à surveiller incluent :

• Modèles d’instructions suspects
• Langage coercitif
• Fréquence inhabituelle des appels d’outils
• Destinations d’appels d’outils inhabituelles
• Données de taille excessive retournées par les outils
• Texte récupéré tentant d’agir comme politique

Atténuations pratiques pour l’injection de prompt

Les attaques par injection de prompt nécessitent une défense en profondeur, car les attaquants peuvent concevoir des prompts malveillants pour échapper à des recherches textuelles simples et à la correspondance de motifs. Un modèle d’atténuation en couches devrait inclure :

• Accès sécurisé aux applications et
• Contrôles d’interaction du modèle
• Gouvernance des données
• Tests opérationnels

L’objectif de ces mesures d’atténuation est de réduire l’impact et la fréquence des attaques. La nature des LLM rend impossible de garantir complètement que les attaques ne réussiront jamais.

Modèles de conception qui réduisent le rayon d’explosion

Les actions d’atténuation des injections de prompt doivent se concentrer sur la gestion du rayon d’explosion potentiel d’une injection réussie. Les meilleures pratiques incluent :

• Contrôles d’accès au moindre privilège pour les outils, connecteurs et sources de données : Cela inclut la mise en œuvre de permissions distinctes pour l’accès en lecture et en écriture.
• Portes humaines pour les actions sensibles : Par exemple, l’approbation humaine devrait être requise pour les paiements, les changements de compte, les tâches administratives privilégiées et d’autres activités à haut risque.
• Frontières solides pour les secrets : Les secrets ne devraient jamais être stockés dans des prompts, en utilisant plutôt des jetons à portée ou des modèles de coffre-fort.
• Segmentation pour les sources de récupération : Idéalement, les LLM ne devraient avoir accès qu’à des corpus de confiance contenant des données organisées et étiquetées.
• Post-traitement déterministe pour les sorties risquées : Les sorties des LLM dans des flux de travail à haut risque ou avec accès à des données sensibles devraient être post-traitées par des logiciels non-AI pour garantir que les politiques sont appliquées et que les données sensibles sont masquées.

Garde-fous en temps d’exécution

En plus de limiter le rayon d’explosion des attaques, les organisations peuvent également mettre en œuvre des garde-fous qui gèrent le risque en temps d’exécution. Les meilleures pratiques incluent :

• Filtrage et normalisation des requêtes : Toutes les réponses des LLM devraient être analysées pour filtrer le contenu potentiellement sensible ou malveillant et pour garantir le respect des politiques d’entreprise.
• Contrôles de perte de données: Utilisez DLP ou un SWG pour empêcher les données sensibles de quitter les systèmes par le biais de requêtes et de réponses lorsque cela est possible.
• Contrôles de risque de contenu: Les LLMs avec accès web doivent être restreints quant aux sites web et types de contenu auxquels ils peuvent accéder.
• Gouvernance d’accès pour les applications et assistants IA: Les applications et assistants IA doivent être limités par des contrôles d’accès basés sur le principe du moindre privilège qui restreignent les données et outils qu’ils peuvent utiliser.
• Journalisation et alertes: La journalisation et les alertes doivent être intégrées dans les outils alimentés par l’IA pour garantir une visibilité adéquate et des pistes de vérification.

Comment les injections de requêtes sont-elles testées et validées ?

Les vulnérabilités d’injection de requêtes doivent être testées régulièrement, car de petits changements dans les requêtes, les outils, les modèles et les sources de données peuvent réintroduire des risques. Une équipe rouge IA utilise des requêtes adversariales pour évaluer les comportements des modèles et des applications de manière structurée et répétable. Certaines des choses clés à tester incluent :

• Fuite de données
• Contournement de politique
• Mauvaise utilisation des outils
• Manipulation de récupération
• Sortie nuisible

Des tests doivent être effectués régulièrement, surtout après le déploiement de nouveaux agents, outils ou connecteurs. Le succès d’un programme de test peut être évalué en fonction du taux de réussite, de la gravité, de la couverture de détection, du temps de détection et du temps de confinement.

Construire une suite de tests d’injection de requêtes répétable

Une suite de tests d’injection de prompt peut garantir qu’une organisation traite correctement les principaux risques d’injection de prompt pour ses systèmes. Les meilleures pratiques incluent :

• Maintenez une bibliothèque de prompts adversariaux classés par catégories de risque.
• Incluez des éléments d’injection indirecte (documents, pages web, tickets) qui sont sûrs mais réalistes.
• Testez par flux de travail et par ensemble de permissions. Le même modèle peut être sûr dans un contexte et dangereux dans un autre.
• Automatisez les tests de régression lorsque les prompts, les sources de récupération ou les schémas d’outils changent.
• Documentez le comportement attendu et les voies d’escalade lorsqu’un test échoue.

Réduction des risques d’injection de prompt et garde-fous opérationnels.

L’injection de prompt est un risque croissant pour la cybersécurité des entreprises alors que celles-ci s’appuient de plus en plus sur des outils d’IA qui peuvent être trompés pour effectuer des actions malveillantes. La sécurité contre l’injection de prompt inclut la contrainte des entrées, du contexte, des actions et des sorties pour réduire la probabilité d’une attaque et ses impacts potentiels sur l’entreprise. Les organisations devraient :

• Restreindre l’accès des outils d’IA aux données et aux outils.
• Surveillez les entrées et les sorties pour détecter des anomalies et des violations de politique.
• Utilisez une désinfection déterministe et un modèle pour les réponses à haut risque.
• Testez régulièrement les outils avec des prompts adversariaux.

Éliminer le risque d’injection de prompt est impossible. Cependant, les organisations peuvent réduire la probabilité et l’ampleur d’une attaque réussie.

FAQ sur l’injection de prompt.

L’injection de prompt est-elle la même chose que le jailbreak ?

Le jailbreak est un type particulier d’attaque par injection de prompt conçu pour tromper un modèle afin de générer des sorties interdites et nuisibles. Les attaques par injection de prompt incluent également le risque qu’un modèle prenne des actions non approuvées et interagisse avec des outils tiers.

L’injection de prompt peut-elle être complètement empêchée ?

Non, l’injection de prompt ne peut pas être complètement empêchée en raison de la difficulté à identifier toutes les entrées malveillantes et du fait que les LLM ne sont pas des systèmes déterministes et prévisibles. Cependant, des contrôles de sécurité en couches peuvent réduire le risque et l’ampleur d’une attaque réussie.

Pourquoi l’injection de prompt indirecte est-elle considérée comme plus dangereuse ?

L’injection de prompt indirecte implique qu’un attaquant injecte des instructions dans un contenu consommé par un LLM, comme des pages web consultées lors de la collecte de contexte sur Internet. C’est plus dangereux car un attaquant pourrait être en mesure d’influencer un agent même s’il ne peut pas accéder directement à son interface utilisateur.

Que doit-on enregistrer pour enquêter sur les tentatives d’injection de prompt ?

Les journaux doivent inclure des événements, des appels d’outils et des violations de politique. Enregistrer des prompts bruts peut être dangereux en raison du risque qu’ils contiennent des données sensibles, et toutes les journaux doivent avoir ces informations expurgées.

Quel est le premier contrôle à mettre en œuvre pour un assistant IA ?

L’accès au moindre privilège est le contrôle le plus important à mettre en œuvre pour un assistant IA. Limiter son accès aux données et à d’autres outils réduit les dommages potentiels qu’une attaque réussie peut causer.