McKinsey infiltré : une IA autonome exploite une faille SQL

McKinsey infiltré : une IA autonome exploite une faille SQL

Plus tôt cette année, un agent IA autonome a pénétré la plateforme IA interne de McKinsey en utilisant rien de plus qu'une ancienne faille d'injection SQL. Aucun identifiant, aucune guidance humaine. Moins de deux heures.

Il a atteint les systèmes de production, exposant des millions de messages de chat et des centaines de milliers de fichiers. La sécurité de l'IA a changé, et les hypothèses traditionnelles ne tiennent plus. Cet article explique ce qu'est le red-teaming en IA, les attaques qui comptent le plus, et comment tester les systèmes IA avant que les attaquants ne le fassent.

Qu'est-ce que le red-teaming dans les systèmes IA ?

Le red teaming consiste à casser votre propre système IA avant que quelqu'un d'autre ne le fasse pour vous.

Au lieu de croiser les doigts en espérant que personne ne trouve un moyen de faire fuiter des données de votre chatbot ou de le faire dire quelque chose qu'il ne devrait pas, il s'agit de s'asseoir et d'essayer de le casser délibérément. Tant qu'il est encore sûr de le réparer.

Le nom vient du milieu militaire. L'équipe rouge joue l'attaquant ; l'équipe bleue joue le défenseur. Pour les LLM, cela signifie lancer les entrées les plus désagréables que vous pouvez imaginer sur votre modèle et observer ce qui en ressort :

• Révèle-t-il quelque chose de privé ?
• Accepte-t-il quelque chose qu'il devrait refuser ?
• Pouvez-vous le manipuler pour qu'il agisse bien en dehors de son objectif ?

Ce n'est pas un test normal, et cette distinction peut prendre un certain temps à vraiment intégrer. Les tests normaux vérifient si votre application fonctionne lorsque quelqu'un l'utilise normalement. Le red teaming vérifie ce qui se passe lorsque quelqu'un essaie activement de la perturber.

Cela compte davantage pour les LLM que pour les logiciels ordinaires, car le même modèle peut se comporter complètement différemment selon la façon dont vous formulez une demande. Votre code n'a pas changé. Vos invites n'ont pas changé. Mais la sortie ? Totalement différente.

Comment le red-teaming atténue les risques

En termes simples : un système IA est risqué parce que personne ne sait ce qui le fera échouer jusqu'à ce que quelqu'un essaie. Le red teaming atténue ce risque en transformant "nous ne savons pas" en "nous savons, et nous l'avons déjà corrigé".

L'idée est d'attaquer son propre IA délibérément, avant qu'un véritable attaquant n'ait la chance. Quand quelque chose casse, il ne suffit pas de le noter et de passer à autre chose, il faut corriger la véritable cause derrière cela, et continuer à tester ce même point faible chaque fois que quelque chose change, afin qu'il ne puisse pas revenir discrètement plus tard sans être remarqué.

C'est tout le mécanisme. Le risque diminue parce que :

• La faille est trouvée avant que quelqu'un d'extérieur à l'entreprise ne le fasse
• La véritable cause est corrigée, pas seulement l'invite qui l'a déclenchée
• La vérification continue indéfiniment, car l'IA continue de changer et les anciennes corrections peuvent silencieusement se briser à nouveau

La carte : OWASP Top 10 pour les applications LLM

Avant d'entrer dans des attaques spécifiques, voici le cadre utilisé pour les organiser : le OWASP Top 10 pour les applications LLM. C'est la liste de contrôle standard de l'industrie pour les risques de sécurité IA les plus courants en production, et la plupart des outils de red teaming, y compris DeepTeam et Promptfoo, sont construits autour de cela.

Les chiffres montrent pourquoi cela compte. Plus de la moitié des CISO considèrent désormais l'IA générative comme un risque de sécurité direct, tandis que l'injection d'invite apparaît dans près de trois quarts des déploiements IA audités. Ce n'est plus une liste de contrôle théorique, c'est ce que les organisations trouvent en production.

Voici la liste actuelle, dans l'ordre où OWASP les classe :

| # | Risque | Ce que cela signifie | |---|--------|----------------------| | LLM01 | Injection d'invite | Le modèle ne peut pas distinguer les instructions des données, donc le texte d'un attaquant est traité comme une commande. | | LLM02 | Divulgation d'informations sensibles | Le modèle révèle des données privées, des identifiants ou des informations confidentielles auxquelles il avait accès. | | LLM03 | Chaîne d'approvisionnement | Un modèle de base, un ensemble de données, un plugin ou une dépendance compromis sapent tout ce qui est construit dessus. | | LLM04 | Empoisonnement des données et du modèle | Les données d'entraînement, de fine-tuning ou de récupération sont altérées pour que le modèle apprenne la mauvaise leçon. | | LLM05 | Gestion incorrecte des sorties | Les systèmes en aval font confiance à la sortie du modèle sans la valider d'abord, et cette confiance est abusée. | | LLM06 | Agence excessive | Le modèle ou son agent environnant détient plus d'outils, de permissions ou d'autonomie que ce que la tâche nécessite. | | LLM07 | Fuite de prompt système | Les instructions cachées qui façonnent le comportement du modèle sont exposées. | | LLM08 | Faiblesses de vecteur et d'embedding | La couche de récupération derrière les applications RAG est empoisonnée, manipulée ou exposée de manière incorrecte. | | LLM09 | Désinformation | Le modèle produit des réponses confiantes, plausibles et incorrectes, et les gens y croient. | | LLM10 | Consommation illimitée | Les requêtes gourmandes en ressources augmentent les coûts ou mettent le service hors ligne. |

Les attaques rencontrées régulièrement

Avec cette carte en main, voici où le risque se concentre et combien en pratique. Voici les quatre types d'attaques qui apparaissent constamment, qu'il vaut la peine de connaître.

1. Injection d'invite

   • C'est la plus importante. Presque tout le reste sur cette liste en découle. Le modèle ne peut pas faire la différence entre les instructions et le texte qu'il lit simplement. Donc, si vous pouvez faire passer vos mots devant lui, vous pouvez souvent le faire traiter vos mots comme une commande.
   • Cela se manifeste de trois manières :
     • Direct : L'utilisateur tape "Ignorez les instructions précédentes et..." → le modèle se conforme immédiatement.
     • Indirect : Une page web cache "Ignorez les instructions précédentes et..." → l'utilisateur demande au modèle de résumer la page → le modèle suit l'instruction cachée à la place.
     • Jailbreak : "Fais semblant d'être DAN..." → la réponse normale est "Je ne peux pas vous aider avec ça" → après que le jeu de rôle s'installe, c'est "Bien sûr, voici comment [quelque chose qu'il aurait dû refuser]."

2. Divulgation d'informations sensibles

   • C'est le modèle qui remet des choses qu'il ne devrait pas : des données utilisateur privées, ses propres instructions cachées, ou des données d'entraînement qui devaient rester enfouies.
   • Les deux premières nécessitent que quelqu'un essaie. La troisième non, et c'est ce qui la rend effrayante. Pas de ruse, pas d'invite astucieuse, rien d'adversarial. Le modèle fait simplement son travail avec un accès qu'il n'aurait jamais dû avoir. C'est exactement ce qui s'est passé chez McKinsey, personne n'a jailbreaké quoi que ce soit. Un point de terminaison mal sécurisé a fait tout le travail.
   • Les trois façons sont :
     • Fuite de prompt système : Demander au modèle de répéter ses propres instructions cachées — et parfois il le fait.
     • Extraction de données d'entraînement : Si on le demande de la bonne manière, le modèle reproduit du texte mémorisé textuellement, parfois en incluant de vrais noms et e-mails.
     • Fuite d'accès légitime : Le modèle est connecté à une base de données ou un outil, et une question normale du quotidien ramène des données qu'il n'aurait jamais dû montrer.

3. Agence excessive

   • Celui-ci est différent des deux premiers. Il ne s'agit pas de tromper le modèle pour qu'il dise quelque chose de mauvais. Il s'agit de ce qui se passe lorsque le modèle, ou l'agent qui l'entoure, peut faire plus que ce que la tâche exige. Vous n'avez pas besoin d'une attaque astucieuse pour que cela tourne mal. Il suffit de lui donner plus de corde qu'il n'en a besoin et d'attendre.
   • Cela se manifeste de trois manières :
     • Trop de fonctionnalités : L'agent n'a besoin que de lire des fichiers, mais l'outil auquel il est connecté peut aussi les supprimer.
     • Trop de permissions : Un agent construit pour un utilisateur se connecte à une base de données en utilisant un compte qui peut voir les données de tout le monde.
     • Trop d'autonomie : L'agent supprime, envoie ou publie quelque chose sans demander d'abord à un humain.

Les méthodes de red-teaming

1. Red-teaming spécifique au domaine

   • Tester ce qui est risqué pour l'application, pas seulement des choses génériques.
   • Exemple : pour un chatbot de santé, il ne s'agit pas seulement de vérifier s'il dit quelque chose de grossier, mais de vérifier s'il donne un mauvais dosage de médicament, car c'est le véritable danger.

2. Utiliser un LLM pour le red teaming

   • Au lieu d'écrire soi-même des invites d'attaque, une autre IA peut les écrire et les essayer.
   • Exemple : demander à un modèle "Essayez de faire en sorte que ce chatbot divulgue des données privées", et il revient avec 50 tentatives différentes en quelques minutes, au lieu d'en écrire 5 à la main en une heure.

3. Red teaming ouvert

   • Pas de liste de contrôle, pas de plan, simplement essayer de le casser de toutes les manières possibles.
   • Exemple : faire répéter au modèle une phrase inventée, puis plus tard dire simplement cette phrase de retour, et il la traite comme une commande, parce qu'il s'en souvient de plus tôt dans la conversation.

4. Red-teaming de nouvelles modalités

   • Tester plus que du texte tapé, des images, de l'audio, tout ce que l'IA peut regarder, écouter ou agir.
   • Exemple : cacher une instruction cachée à l'intérieur des données invisibles d'une image (métadonnées). Une personne regardant l'image ne voit rien de mal, mais l'IA la lit et la suit comme une commande.

5. Red-teaming crowdsourcé

   • Au lieu de compter uniquement sur une petite équipe, ouvrir les tests à un grand groupe de personnes extérieures et les laisser tous essayer de le casser à leur manière.
   • Exemple : Meta a fait appel à 350 experts différents de tous horizons pour attaquer Llama 2 pendant des mois avant sa sortie, car une petite équipe ne pourrait jamais penser à tous les angles qu'un avocat, un médecin ou un chercheur en sécurité essaieraient chacun.

Il fut un temps où écrire des attaques à la main était simplement… le travail. Il fallait s'asseoir pendant des heures, rêvant de formulations de jailbreak.