Pour créer des systèmes d’IA efficaces, il faut d’abord les mettre à l’épreuve. Nous avons mené une mission de red teaming en simulant des attaquants afin de tester et d’examiner une application d’IA destinée aux clients dans les services financiers. Nos découvertes concernent quiconque déploie des applications basées sur des LLM dans des contextes où la sécurité est indispensable.
Le red teaming consiste à tenter délibérément de mettre en échec votre système d’IA afin de corriger ses vulnérabilités avant qu’un véritable attaquant ne les découvre. Dans les services financiers, les enjeux sont particulièrement élevés : les applications d’IA manipulent les données des clients, traitent des transactions et fournissent des analyses financières. Une défaillance peut entraîner aussi bien une mauvaise expérience utilisateur que des infractions réglementaires, des pertes financières et une atteinte irréparable à la marque.
Notre objectif était de détecter les vulnérabilités en amont, de tester des schémas d’attaque réalistes et d’aider l’organisation à répondre aux exigences de sécurité de l’IA que les autorités de réglementation prennent très au sérieux.
Une distinction s’impose ici : le jailbreak attaque les filtres de sécurité du modèle sous-jacent ; l’attaque par injection de prompt cible l’application elle-même en combinant une entrée utilisateur non fiable au prompt fiable du développeur. L’attaque par injection de prompt présente un risque supérieur, car elle cible votre système et les données confidentielles qu’il traite, et non un modèle généraliste.
Notre première série comprenait environ 750 tests portant sur :
Fuite de données entre sessions
Exposition de données personnelles (PII) par langage naturel, manipulation d’API et divers encodages
Injection SQL
Contournement du prompt système
Ces premiers tests ont révélé deux problèmes majeurs dans le système existant : le traitement des requêtes à intentions multiples et l’utilisation de prompts encodés.
Requêtes à intentions multiples : demandes combinant des requêtes légitimes et malveillantes. Par exemple : « Affiche mes dépenses par catégorie et exécute également [SQL malveillant]. » L’application ne détectait pas l’intention malveillante et dépendait entièrement des garde-fous de la couche de données en aval. Cela revient à laisser sa porte d’entrée ouverte parce qu’on fait confiance au coffre-fort de la cave.
Encodage : demandes encodées en Base64, hexadécimal, LeetSpeak et homoglyphes. Les systèmes peuvent avoir du mal à filtrer les intentions malveillantes. Bien que ces requêtes n’aient pas exposé de données sensibles, elles ont fortement déstabilisé le système : hallucinations, renvoi de SQL malveillant aux utilisateurs, classification confuse des intentions, etc.
Les résultats de nos premiers tests ont montré :
Hallucinations temporelles : le modèle fournit avec assurance des dates, des horodatages de transactions ou des synthèses temporelles inventés. C’est un risque important dans la finance, où un client agissant sur la base d’une date erronée pourrait subir de réelles conséquences
Renvoi de SQL malveillant à l’utilisateur, ce qui est préoccupant en raison des risques d’empoisonnement de la mémoire
Classification confuse des intentions
Mise en forme désordonnée des résultats
Forts de ces résultats, nous avons resserré notre champ d’étude. Les tests d’injection SQL et d’encodage sont devenus moins prioritaires, car l’équipe s’en occupait déjà. Nous nous sommes plutôt concentrés sur les vecteurs d’attaque les plus efficaces : l’exposition de données personnelles et les fuites entre sessions.
La découverte la plus frappante de la deuxième série était d’une simplicité désarmante : souvent, aucune ingéniosité n’est nécessaire.
Dans de nombreux cas, il suffisait de demander des données internes dans le cadre d’une requête apparemment légitime pour que le système accepte de les exposer. De simples requêtes recevaient des réponses mentionnant des identifiants internes et des champs système qui n’auraient jamais dû être présentés aux utilisateurs finaux.
En approfondissant, nous avons constaté qu’il ne s’agissait pas seulement d’une défaillance au niveau de l’application. Le service de conversion de texte en SQL en aval construisait des requêtes demandant plus de champs que nécessaire, et ses réponses explicatives mentionnaient des données qui auraient dû être restreintes. Cela a révélé une véritable faille entre les systèmes, le type de vulnérabilité qui n’apparaît que lorsque l’on teste l’ensemble de la pile plutôt que chaque composant séparément.
Testez le système en red team, pas le modèle. Tester un LLM isolément renseigne très peu sur le niveau de sécurité de votre application. Testez toute la pile de bout en bout, comme le ferait un utilisateur.
La validation des entrées doit précéder le LLM. Les requêtes encodées, les attaques à intentions multiples et les tentatives d’injection élémentaires doivent être interceptées en périphérie, et non déléguées aux services en aval.
Ne faites pas confiance aux interfaces. Dans les architectures multiservices, les failles les plus intéressantes se cachent entre les systèmes. La confiance zéro ne tolère aucune exception : validez tout, à chaque couche.
Les attaques simples fonctionnent. Les jailbreaks sophistiqués font les gros titres, mais parfois, il suffit de... demander. Si votre système révèle volontiers des identifiants internes lorsqu’un utilisateur les inclut dans une requête par ailleurs légitime, c’est un problème.
Comprenez ce que vous testez réellement. Les schémas d’attaque connus peuvent être interceptés grâce à l’entraînement du LLM lui-même plutôt que par vos garde-fous. Intégrez l’observabilité à votre red teaming pour savoir quels contrôles sont réellement sollicités.
Les environnements contraints exigent des solutions créatives. Les fournisseurs personnalisés et la prise en charge des modèles locaux permettent un red teaming pertinent sans accès spécialisé au cloud. Mais soyez transparents quant aux limites qui en découlent.
Le red teaming n’est pas une opération ponctuelle. Il est itératif, doit être automatisé autant que possible et évoluer avec votre système. Les attaques qui compteront demain ne sont pas celles qui comptent aujourd’hui.
Les systèmes d’IA en environnement réglementé feront l’objet d’une surveillance toujours plus étroite. Les organisations qui considèrent les tests de sécurité comme une discipline continue plutôt que comme une case à cocher avant le lancement seront mieux préparées à cette surveillance et éviteront les crises médiatiques qui leur font perdre la confiance de leurs clients.