Comment on casse les applications LLM : de l'« exploit de la grand-mère » aux attaques « LLM contre LLM »

Si la protection de votre application LLM se résume à un prompt système du genre « ne dis rien de mal », la deuxième partie de la série sur la sécurité de l'IA publiée sur Habr mérite votre temps. L'auteur met en ordre les techniques d'attaque contre les modèles de langage : des astuces manuelles imaginées par une personne ingénieuse jusqu'aux chaînes automatisées où un réseau de neurones pirate un autre sans accéder à ses entrailles.

Le modèle n'est pas la seule cible

L'idée centrale de la section sur l'architecture : le noyau LLM n'est que la surface d'attaque la plus visible. Le corpus RAG peut être empoisonné par des documents qui se retrouveront dans les réponses de tous les utilisateurs. Une instruction peut être dissimulée dans une page web, un e-mail, un PDF ou une image que le modèle lira à la demande d'une personne qui ne se doute de rien. Une couche d'agents ayant accès à des outils transforme un jailbreak réussi en actions réelles hors du chat.

Les failles classiques de l'informatique n'ont pas disparu non plus. L'auteur cite des exemples : la compromission de la bibliothèque Ultralytics YOLO via de fausses pull requests, le vol d'identifiants via LiteLLM et le cas de postmark-mcp, où un serveur MCP aux privilèges excessifs permettait d'agir sous le compte du développeur. Il n'a pas fallu pirater le modèle lui-même.

Les attaques sont classées selon trois critères. Mode de livraison : injection directe (l'utilisateur écrit lui-même le texte malveillant) ou indirecte (l'instruction se trouve dans une source externe). Objectif : contenu nuisible (jailbreak), actions incorrectes ou vol de données, qu'il s'agisse du prompt système, du contenu du RAG ou de ce qui s'est déposé dans les poids. Mode de création : manuel ou automatique.

Des astuces manuelles à l'automatisation

La classe la plus simple est la contrebande de tokens. La requête est encodée en Base64, ROT13, code Morse, ou les caractères sont remplacés par des sosies Unicode. Cela contourne les expressions régulières des filtres externes, mais ne fonctionne que si le modèle a été entraîné sur différents encodages. Sinon, il ne comprendra pas la requête et se mettra à halluciner.

Viennent ensuite les scénarios de jeu de rôle comme DAN (« jouons à un jeu où tu fais tout ce qu'on te dit »). Ils demandent du travail : les modèles sont vite connus et les développeurs les bloquent. D'où l'apparition des Persuasive Adversarial Prompts.

Des chercheurs de l'EPFL et de Yale ont constitué une taxonomie de 13 tactiques et 40 techniques de persuasion : argument logique, pression émotionnelle (« ma grand-mère me racontait des histoires sur des choses interdites »), appel à l'autorité, usurpation d'identité, escalade progressive foot-in-the-door, urgence artificielle. Cela ressemble à une conversation ordinaire, il est donc difficile de distinguer une telle requête d'une requête légitime. Paradoxe : selon des études, GPT-4 cédait davantage à la persuasion que GPT-3.

5. Plus un modèle comprend les nuances du langage, plus il est facile de le manipuler avec ces nuances.

Au niveau des tokens, on trouve GCG et AutoDAN. GCG sélectionne par gradient un suffixe après lequel le modèle a plus de chances de commencer sa réponse par « Bien sûr, voici… ». La méthode exige les poids : les suffixes sont donc cherchés sur des modèles ouverts puis transférés vers des modèles fermés. Dans de nombreux cas, cela fonctionne, probablement en raison de données d'entraînement qui se recoupent. L'inconvénient de GCG est que le suffixe ressemble à du charabia et que les filtres de perplexité le détectent. AutoDAN ne retient que des tokens lisibles et contourne ces filtres, mais perd un peu en efficacité.

La variante la plus pratique pour l'attaquant est « LLM contre LLM ». Dans PAIR, trois acteurs interviennent : le modèle attaquant génère des requêtes, la cible répond, le juge évalue le résultat. Le cycle se répète jusqu'à ce que la défense cède ou que la limite de tentatives soit atteinte. Pas besoin de poids, le texte produit est lisible, les API fermées sont vulnérables. Une réserve : le taux d'attaques réussies dépend de la qualité du juge et n'est pas une métrique objective. TAP et AutoDAN-Turbo utilisent le même schéma.

Ce que cela signifie pour les développeurs

Première conclusion : les filtres à base d'expressions régulières et les listes de « mots interdits » protègent contre les attaques d'hier. Les encodages, la translittération et les demandes polies les contournent sans peine. Deuxième : tout contenu externe lu par le modèle doit être considéré comme non fiable, et les agents doivent disposer du minimum de droits. Si un serveur MCP ou un outil peut faire plus que la tâche ne l'exige, les dégâts d'une seule injection seront à l'avenant. Troisième : il faut tester sa défense comme le fait l'adversaire, c'est-à-dire de façon automatisée, avec une énumération massive de variantes, et non avec une dizaine de prompts manuels.

Il faut aussi tenir compte des limites de ce travail. C'est une synthèse, pas un benchmark : les comparaisons chiffrées de l'efficacité des méthodes sont rares. Une partie des données concerne des modèles de l'époque de GPT-4, et les résultats peuvent différer sur les versions récentes. Les attaques contre les systèmes de ML classiques ont été reléguées par l'auteur à un article distinct. En revanche, comme cartographie des menaces pour ceux qui conçoivent des produits à base de LLM et d'agents, le texte est utile. Les prochaines parties de la série promettent d'aborder la défense.