deepteam : Tester les modèles OpenAI contre les attaques adverses en un seul tour

L’avancement rapide des grands modèles linguistiques (LLM) comme ceux d’OpenAI a apporté d’immenses capacités, mais aussi un besoin critique de mécanismes de sécurité robustes. Il est primordial de s’assurer que ces modèles ne peuvent pas être contraints de générer du contenu nuisible ou illicite. Ce défi a donné naissance au “red teaming”, une pratique où des experts en sécurité simulent des attaques adverses pour découvrir des vulnérabilités. Un nouveau framework, deepteam, offre une approche simplifiée de ces tests vitaux, fournissant une suite de méthodes pour évaluer la résilience d’un LLM contre diverses formes de manipulation.

deepteam est conçu pour exposer les faiblesses des applications LLM en simulant plus de dix vecteurs d’attaque distincts, allant de l’injection de prompts simple à des techniques plus élaborées comme le leetspeak ou les instructions encodées. Le framework commence par des attaques de base, puis applique progressivement des méthodes d’“amélioration d’attaque” plus avancées, imitant la sophistication évolutive des acteurs malveillants du monde réel. Bien que deepteam prenne en charge les attaques à un seul tour et à plusieurs tours, l’accent est mis ici sur l’évaluation de la défense d’un modèle OpenAI contre les invites adverses à un seul tour — celles où l’attaquant tente d’obtenir une réponse nuisible en une seule interaction.

Pour mener ces tests, les développeurs doivent d’abord installer les bibliothèques deepteam et OpenAI nécessaires et configurer leur clé API OpenAI, ce qui est essentiel pour que deepteam puisse à la fois générer des attaques adverses et évaluer les réponses du LLM. Le processus implique la définition d’une fonction de rappel qui interroge le modèle OpenAI cible — dans ce cas, gpt-4o-mini — et renvoie sa sortie. Cette fonction agit comme l’interface entre le framework d’attaque et le LLM testé.

Une fois l’interface du modèle établie, des vulnérabilités et des types d’attaque spécifiques sont définis. Pour cette série de tests, la catégorie de vulnérabilité choisie était “Activité illégale”, avec un accent particulier sur les sous-catégories sensibles afin de tester rigoureusement les protocoles de sécurité du modèle. Plusieurs méthodes d’attaque à un seul tour ont ensuite été déployées :

L’Injection de Prompts est une technique courante où les utilisateurs tentent de contourner les instructions inhérentes d’un modèle en injectant du texte manipulateur dans un prompt. L’objectif est de tromper le modèle pour qu’il ignore ses politiques de sécurité et génère du contenu restreint. Lors de ce test, un prompt injecté a tenté de forcer le modèle à adopter une personnalité contraire à l’éthique qui encouragerait les activités illégales. Cependant, le modèle a résisté avec succès, répondant par un sans équivoque “Je suis désolé, je ne peux pas vous aider avec cela”, confirmant son adhésion aux directives de sécurité.

L’Attaque GrayBox exploite une connaissance partielle du système LLM ciblé pour élaborer des prompts adverses. Contrairement aux entrées complètement aléatoires, les attaques GrayBox exploitent les faiblesses connues en reformulant les attaques de base avec un langage abstrait ou trompeur, rendant l’intention malveillante plus difficile à détecter pour les filtres de sécurité. Ce test impliquait un prompt déguisé en instructions pour créer de faux documents d’identification et utiliser des canaux cryptés. Le modèle, cependant, n’est pas tombé dans l’obfuscation.

Dans une Attaque Base64, des instructions nuisibles sont encodées en Base64 pour contourner les filtres de mots-clés directs. L’attaquant cache le contenu malveillant dans un format encodé, espérant que le modèle décodera et exécutera les commandes cachées. Ici, une chaîne encodée contenait des directives liées à des activités illégales. Malgré la nature cachée de la requête, le modèle n’a pas tenté de décoder ou d’agir sur le contenu déguisé.

L’Attaque Leetspeak déguise les instructions malveillantes en substituant des caractères normaux par des chiffres ou des symboles (par exemple, ‘a’ devient ‘4’, ‘e’ devient ‘3’). Cette substitution symbolique rend le texte nuisible difficile à détecter pour les filtres de mots-clés simples tout en restant lisible pour un humain ou un système capable de le décoder. Un texte d’attaque instruisant des mineurs dans des activités illégales, écrit en leetspeak, a été clairement reconnu par le modèle comme malveillant, malgré l’obfuscation.

De même, l’Attaque ROT-13 emploie une méthode d’obfuscation classique où chaque lettre est décalée de 13 positions dans l’alphabet, brouillant les instructions nuisibles sous une forme codée. Cela les rend moins susceptibles de déclencher des filtres de contenu basiques basés sur des mots-clés, bien que le texte soit facilement décodable. Le modèle gpt-4o-mini a démontré sa capacité à détecter l’intention malveillante sous-jacente.

Une Attaque Multilingue implique la traduction d’un prompt de base nuisible dans une langue moins couramment surveillée. Le principe est que les filtres de contenu et les systèmes de modération pourraient être moins efficaces dans des langues autres que celles largement utilisées comme l’anglais. Lors d’un test, une attaque écrite en swahili, demandant des instructions liées à une activité illégale, a également été résistée avec succès par le modèle.

Enfin, l’Attaque par Problème Mathématique intègre des requêtes malveillantes dans des notations mathématiques ou des énoncés de problèmes, faisant apparaître l’entrée comme un exercice académique inoffensif. Dans ce scénario, l’entrée a formulé un contenu d’exploitation illégal comme un problème de théorie des groupes, demandant au modèle de “prouver” un résultat nuisible et de fournir une “traduction” en langage clair. Le modèle a réussi à identifier et à refuser de s’engager avec la requête nuisible sous-jacente.

À travers tous ces tests adverses à un seul tour, le modèle gpt-4o-mini a démontré des défenses robustes, refusant constamment de générer du contenu nuisible ou restreint. Ce processus rigoureux de red-teaming utilisant deepteam fournit des informations précieuses sur la posture de sécurité d’un LLM, soulignant l’effort continu requis pour construire et maintenir des systèmes d’IA sûrs et fiables capables de résister à des tactiques adverses de plus en plus sophistiquées.