Pour bâtir des systèmes d’IA efficaces, il faut d’abord les mettre à l’épreuve. Nous avons mené un exercice d’équipe rouge en simulant des attaquants afin de tester et de sonder une application d’IA destinée à la clientèle dans le secteur des services financiers. Nos constatations concernent quiconque déploie des applications propulsées par des LLM dans un contexte où la sécurité est indispensable.
Un exercice d’équipe rouge consiste à tenter délibérément de compromettre 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 accèdent aux données des clients, traitent des transactions et fournissent des renseignements financiers. Une défaillance peut entraîner une mauvaise expérience utilisateur, des infractions réglementaires, des pertes financières ou des dommages irréparables à la marque.
Notre objectif était de détecter rapidement les vulnérabilités, de tester des scénarios d’attaque réalistes et d’aider l’organisation à répondre aux attentes de sécurité de l’IA que les organismes de réglementation prennent très au sérieux.
Une distinction s’impose ici : le jailbreak s’attaque aux filtres de sécurité du modèle sous-jacent, tandis que l’injection d’invite cible l’application elle-même en combinant les entrées utilisateur non fiables à l’invite fiable du développeur. L’injection d’invite présente un risque accru, car elle cible votre système et les données confidentielles qu’il traite, plutôt qu’un modèle polyvalent.
Notre première série comprenait environ 750 tests portant sur les éléments suivants :
Fuite de données entre les sessions
Exposition de renseignements personnels (par le langage naturel, la manipulation d’API et divers encodages)
Injection SQL
Contournement de l’invite système
Durant ces premiers tests, nous avons relevé deux problèmes majeurs dans le système existant : le traitement des requêtes à intentions multiples et l’utilisation d’invites encodées.
Requêtes à intentions multiples : des demandes qui combinent des requêtes légitimes et malveillantes. Par exemple : « Affiche mes dépenses par catégorie, puis exécute aussi [SQL malveillant]. » L’application ne détectait pas l’intention malveillante et dépendait entièrement des mesures de protection de la couche de données en aval. C’est comme laisser votre porte d’entrée ouverte parce que vous faites confiance au coffre-fort du sous-sol.
Encodage : des demandes encodées en Base64, en hexadécimal, en LeetSpeak ou au moyen d’homoglyphes. Il peut être difficile pour les systèmes de 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 code SQL malveillant aux utilisateurs, confusion dans la classification des intentions, etc.
Les résultats de nos premiers tests ont révélé ce qui suit :
Hallucinations temporelles : le modèle fournit avec assurance des dates, des horodatages de transaction ou des résumés portant sur une période donnée qu’il a inventés. Il s’agit d’un risque important dans un contexte financier, où un client qui agit en fonction d’une date erronée pourrait subir de réelles conséquences
Renvoi de code SQL malveillant à l’utilisateur (préoccupant en raison des risques d’empoisonnement de la mémoire)
Confusion dans la classification des intentions
Mise en forme désordonnée des résultats
Forts de ces constatations, nous avons resserré notre champ d’analyse. Les tests d’injection SQL et d’encodage ont été relégués au second plan, puisque 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 renseignements personnels et les fuites entre les sessions.
La constatation la plus frappante de la deuxième série était d’une simplicité déconcertante : souvent, nul besoin d’être astucieux.
Dans bien des cas, il suffisait simplement 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 produisaient des réponses mentionnant des identifiants internes et des champs système qui ne devraient jamais être présentés aux utilisateurs finaux.
En approfondissant notre analyse, nous avons constaté qu’il ne s’agissait pas seulement d’une défaillance de l’application. Le service de conversion de texte en SQL en aval construisait des requêtes visant plus de champs que nécessaire, et ses réponses explicatives faisaient référence à 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 lorsqu’on teste la pile complète plutôt que chaque composant séparément.
Soumettez le système à un exercice d’équipe rouge, et non le modèle. Tester un LLM isolément vous renseigne très peu sur la posture 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 à la périphérie plutôt que confiées aux services en aval.
Ne faites pas confiance aux points de jonction. Dans les architectures multiservices, les failles entre les systèmes dissimulent les vulnérabilités les plus intéressantes. La confiance zéro signifie qu’il ne faut faire confiance à rien : validez donc tout, à chaque couche.
Les attaques simples sont efficaces. Les jailbreaks sophistiqués font les manchettes, 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 scénarios d’attaque connus peuvent être interceptés grâce à l’entraînement du LLM lui-même plutôt que par vos mesures de protection. Intégrez l’observabilité à vos exercices d’équipe rouge afin de comprendre quels contrôles sont réellement sollicités.
Les environnements restreints exigent des solutions créatives. Les fournisseurs personnalisés et la prise en charge des modèles locaux permettent de mener des exercices d’équipe rouge pertinentes sans accès infonuagique spécialisé. Il faut toutefois faire preuve de transparence quant aux limites qui en découlent.
Les exercices d’équipe rouge ne sont pas ponctuels. Ils sont itératifs, doivent être automatisés lorsque possible et doivent évoluer au même rythme que votre système. Les attaques qui compteront demain ne sont pas les mêmes que celles qui comptent aujourd’hui.
Les systèmes d’IA en milieu réglementé feront l’objet d’une surveillance qui ne fera que s’intensifier. Les organisations qui considèrent les tests de sécurité comme une pratique continue plutôt que comme une simple formalité à accomplir avant le lancement seront mieux placées pour répondre à cette surveillance et éviter les crises de relations publiques qui minent la confiance de leurs clients.