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. Dans cet article, je vais expliquer 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, vous vous asseyez et essayez de le casser vous-même. 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 m'a pris 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é".

J'attaque mon propre IA délibérément, avant qu'un véritable attaquant n'ait la chance. Quand quelque chose casse, je ne me contente pas de le noter et de passer à autre chose, je corrige la véritable cause derrière cela, et je continue à tester ce même point faible chaque fois que je change quoi que ce soit, afin qu'il ne puisse pas revenir discrètement plus tard sans que je ne le remarque.

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

• Je trouve la faille avant que quelqu'un d'extérieur à l'entreprise ne le fasse
• Je corrige la véritable cause, pas seulement l'invite qui l'a déclenchée
• Je continue à vérifier 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 que j'utilise 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 que je rencontre 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. Vous devez juste lui donner plus de corde qu'il n'en a besoin et 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

   • Je teste ce qui est risqué pour mon application, pas seulement des choses génériques.
   • Exemple : pour un chatbot de santé, je ne vérifie pas seulement s'il dit quelque chose de grossier, je vérifie 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 moi-même des invites d'attaque, j'ai une autre IA les écrire et les essayer pour moi.
   • Exemple : je dis à 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 que je n'écrive 5 à la main en une heure.

3. Red teaming ouvert

   • Pas de liste de contrôle, pas de plan, j'essaie simplement de le casser de toutes les manières possibles.
   • Exemple : je fais répéter au modèle une phrase inventée, puis plus tard je dis 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

   • Je teste plus que du texte tapé, des images, de l'audio, tout ce que l'IA peut regarder, écouter ou agir.
   • Exemple : je cache 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 moi ou une petite équipe, j'ouvre les tests à un grand groupe de personnes extérieures et les laisse 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.

Je me souviens quand écrire des attaques à la main était juste… le travail. Vous vous asseyez là pendant des heures, rêvant de formulations de jailbreak,