Lilli de McKinsey a été rendu public le 9 mars. Le bilan ne fait état d’aucun préjudice.

Le 9 mars 2026, la start-up de sécurité CodeWall a publié son récit de la manière dont un agent autonome qu'elle avait développé a obtenu, en une petite heure environ et sans un seul identifiant, un accès complet en lecture et en écriture à la base de données de production qui sous-tend Lilli, l'assistant IA d'entreprise de McKinsey & Company. L'intrusion elle-même a eu lieu le 28 février ; ce que consigne cette entrée de l'archive des incidents liés à l'IA, c'est le jour où elle est devenue publique. Selon CodeWall, la base de données à laquelle l'agent a accédé contenait 46,5 millions de messages de conversation en clair, 728 000 fichiers, 57 000 comptes utilisateurs et les 95 invites système qui régissent la façon dont Lilli répond — et ces invites se trouvaient dans la même base de données que l'agent pouvait modifier. Les personnes présentes dans ces données étaient les propres collaborateurs de McKinsey : le cabinet indique que 72 pour cent de ses employés, soit plus de 40 000 personnes, utilisent Lilli, qui traite plus de 500 000 invites par mois. L'entrée complète, avec ses niveaux de gravité et de confiance ainsi que les enregistrements voisins parmi lesquels elle figure, se trouve dans l'Orca AI Incident Archive.

Cette ouverture condense deux types d’affirmations très différents, et la fiche d’archive est attentive à cette différence. Elle classe le dossier comme un incident, avec une confiance A, non contesté, une gravité élevée, une région États-Unis, un type INFRA — infrastructure, et non une défaillance de modèle. Elle consigne aussi l’absence de préjudice réel. C’est ce dernier champ qu’il vaut la peine de relire deux fois, car il ne signifie pas que l’exposition était sans danger. Il signifie qu’aucun préjudice n’a été établi au dossier, et l’article ci-dessous sépare ce sur quoi deux parties s’accordent de ce qui repose sur la version d’une entreprise concernant ses propres recherches.

Pourquoi la divulgation est un événement daté à part entière

Le résumé de l’archive pour cette entrée renvoie au 28 février 2026, le jour où l’agent de CodeWall a découvert la faille, et l’archive conserve cette date antérieure comme un enregistrement distinct. La séparation n’a rien de bureaucratique. Avant le 9 mars, les seules parties qui savaient ce qui s’était passé au sein de Lilli étaient McKinsey et le chercheur qui en avait informé McKinsey. Après le 9 mars, la forme de la défaillance, la réponse de l’entreprise et l’affirmation sur ce que contenait la base de données étaient toutes consignées dans les archives publiques, où d’autres chercheurs en sécurité pouvaient les contester.

Lilli n’est pas un projet annexe. The Register situe son déploiement en juillet 2023, pour le chat, l’analyse de documents et la recherche dans les travaux internes du cabinet. L’article de CodeWall, qui indique aussi l’origine du nom — la première femme professionnelle recrutée par le cabinet, en 1945 —, évoque plus de 100 000 documents internes en amont. The Register, qui a rapporté cette révélation le jour même, chiffre l’adoption à 72 % des employés et le volume à plus de 500 000 prompts par mois — des chiffres que McKinsey a elle-même publiés dans une étude de cas publique consacrée à la plateforme.

Comment l'agent est entré

Le récit de CodeWall commence par la documentation, pas par l’exploitation. Son agent a découvert que la documentation API de Lilli était exposée publiquement et entièrement documentée : plus de 200 points de terminaison au total, dont la plupart nécessitaient une authentification, et 22 qui n’en nécessitaient pas. L’un de ces points de terminaison non authentifiés écrivait les requêtes de recherche des utilisateurs dans la base de données. Les valeurs étaient correctement paramétrées, mais les clés JSON — les noms des champs — étaient concaténées directement dans le SQL.

L’agent l’a remarqué parce que les messages d’erreur de la base de données renvoyaient ces clés JSON mot pour mot. CodeWall affirme que le scanner ZAP de l’OWASP n’a pas signalé le problème, et que l’agent a ensuite effectué quinze itérations à l’aveugle, chaque message d’erreur lui apprenant un peu plus sur la structure de la requête, jusqu’à ce que des lignes de production réelles commencent à remonter. À partir de là, il a enchaîné l’injection avec une faille d’autorisation au niveau des objets pour lire l’historique de recherche individuel des employés. L’entreprise décrit l’ensemble de l’opération comme entièrement autonome, de la sélection de la cible au rapport, sans identifiants et sans intervention humaine. Son fondateur et directeur général, Paul Price, a déclaré à The Register que le processus était « entièrement autonome, de la recherche de la cible à l’analyse, à l’attaque et au rapport ».

Ce que CodeWall affirme se trouvait à l’intérieur

Chaque chiffre de cette section provient de l'article publié par CodeWall le 9 mars. Aucune charge utile n'a été publiée, si bien que rien de tout cela ne peut être reproduit ni compté indépendamment — une limite que la section suivante aborde.

• 46,5 millions de messages de chat, stockés en texte clair, couvrant le travail stratégique, les missions clients, les finances et les fusions-acquisitions.

• 728 000 fichiers, dont le compte rendu détaille 192 000 PDF, 93 000 feuilles de calcul Excel, 93 000 présentations PowerPoint et 58 000 documents Word — 436 000 au total, laissant les 292 000 restants non classés dans la même phrase.

• 57 000 comptes utilisateurs, 384 000 assistants IA et 94 000 espaces de travail, ce que CodeWall décrit comme la structure organisationnelle complète de l'utilisation de l'IA en interne par l'entreprise.

• 95 prompts système et configurations de modèles pour 12 types de modèles, montrant comment l’assistant a été instruit, quels garde-fous existaient et quels modèles se trouvaient en dessous.

• 3,68 million de fragments de documents pour la génération augmentée par récupération, avec des chemins de stockage S3 et des métadonnées de fichiers internes — la base de connaissances qui alimente l’assistant.

• 1,1 million de fichiers et 217 000 messages d'agents transitant par des API d'IA externes, dont plus de 266 000 magasins vectoriels sur la plateforme d'OpenAI.

Ce que CodeWall présente comme le point principal n'est pas l'injection, mais l'endroit où l'injection a atterri. Les prompts système de Lilli étaient des lignes dans la même base de données que l'agent pouvait modifier, ce qui signifie qu'un attaquant disposant du même accès aurait pu réécrire les instructions de l'assistant au moyen d'une seule instruction UPDATE encapsulée dans un seul appel HTTP — sans déploiement, sans modification de code, sans fichier sur disque à comparer. CodeWall indique que ses propres tests ne visaient qu'à vérifier : elle a lu, sans écrire, et affirme qu'aucun service de production n'a été perturbé.

Ce que McKinsey a déclaré le même jour

Un porte-parole de McKinsey a déclaré à The Register le 9 mars que le cabinet avait corrigé tous les problèmes identifiés par CodeWall en quelques heures après en avoir eu connaissance. « Notre enquête, soutenue par une société indépendante de premier plan spécialisée en criminalistique numérique, n’a trouvé aucune preuve que les données clients ou les informations confidentielles des clients aient été consultées par ce chercheur ou par tout autre tiers non autorisé », a déclaré le porte-parole, ajoutant que « les systèmes de cybersécurité de McKinsey sont robustes ».

Silicon UK a rapporté la même information le 13 mars, dans le compte rendu de Matthew Broersma : McKinsey a déclaré avoir « récemment été alerté d’une vulnérabilité liée à notre outil d’IA interne, Lilli, par un chercheur en sécurité », avoir « rapidement confirmé la vulnérabilité et corrigé le problème en quelques heures », et qu’aucune donnée client ni information confidentielle client n’avait été consultée. Ce rapport note également que Price est le seul employé de CodeWall, un détail qu’il vaut la peine de retenir car il joue dans les deux sens : une structure de recherche composée d’une seule personne a trouvé en deux heures ce que les propres scanners de l’entreprise n’ont pas trouvé, et une structure d’une seule personne vend aussi l’outil qui l’a trouvé.

Deux récits de la correction, à un jour d’intervalle

Le calendrier de divulgation de CodeWall se présente comme suit : l'agent identifie l'injection SQL et commence à énumérer la base de données de production le 28 février ; la chaîne complète est confirmée le jour même, avec 27 constats documentés ; un courriel de divulgation responsable est envoyé à l'équipe de sécurité de McKinsey le 1er mars, accompagné d'un résumé d'impact de haut niveau ; le directeur de la sécurité de l'information de l'entreprise accuse réception et demande des preuves détaillées le 2 mars ; et le 2 mars, tous les points de terminaison non authentifiés sont corrigés et vérifiés, l'environnement de développement est mis hors ligne et la documentation publique de l'API est bloquée. La divulgation publique suit le 9 mars.

La version de McKinsey est que le correctif est intervenu dans les heures suivant l’information. {{1}}La chronologie de CodeWall situe le correctif au lendemain de son e-mail de divulgation.{{/1}} Les deux versions sont publiques. Aucune des parties ne les a conciliées, et cet article ne cherche pas à le faire : {{2}}la différence se joue entre un correctif le jour même et un correctif le lendemain{{/2}}, et la séquence qui compte — l’information, puis le correctif, puis la publication — n’est pas contestée.

Établi, source unique, et l’écart entre les deux

Établi, convenu par les deux parties : il y avait une faiblesse non authentifiée dans la surface d’API publique de Lilli ; elle a été découverte par un chercheur en sécurité externe plutôt que par un initié ; McKinsey l’a confirmée et corrigée ; les points de terminaison non authentifiés ont été fermés, l’environnement de développement a été mis hors ligne et la documentation de l’API publique a été bloquée.

Source unique, de CodeWall : chacun des décomptes ci-dessus, la chronologie de deux heures, les quinze itérations à l’aveugle, les 27 constatations documentées, et l’affirmation selon laquelle les prompts pouvaient être écrits au moyen de la même injection. Rien de tout cela n’est réfuté. Rien de tout cela n’a non plus été vérifié de manière indépendante, car les charges utiles qui permettraient à quiconque de vérifier n’ont pas été publiées, et Price a refusé de fournir à The Register les prompts exacts utilisés par son équipe.

Promptfoo, l’entreprise de sécurité spécialisée dans l’IA, a publié le 10 mars une évaluation qui énonce précisément la limite : le dossier public « ne prouve pas de manière indépendante chaque nombre de lignes signalé ni chaque étape de l’exploitation », même s’il étaye la forme de l’incident. C’est la lecture correcte des éléments disponibles. La catégorie de bogue est reconstructible ; l’ampleur relève du témoignage.

Le préjudice que le dossier ne porte pas

C’est ici que l’évaluation de l’archive fait réellement son travail. Un chemin de deux heures vers un accès en lecture et en écriture à l’intérieur de la base de données de production d’un assistant à l’échelle de l’entreprise ressemble à un constat de préjudice, et l’archive n’en consigne aucun. Ce constat repose sur trois éléments : la déclaration de McKinsey selon laquelle une enquête forensic menée par un tiers n’a trouvé aucune preuve que des données clients aient été consultées ; la déclaration de CodeWall selon laquelle ses tests étaient uniquement destinés à la vérification et n’ont rien perturbé ; et l’absence, dans la couverture examinée pour cet article, de toute conclusion contradictoire.

Cela ne repose pas sur un audit technique indépendant, sur la décision d’un régulateur ni sur une notification de violation. Aucun identifiant CVE n’a été attribué dans les sources examinées — Lilli est un logiciel interne plutôt qu’un produit distribué, et aucun avis ne le nomme — et aucune autorité de supervision ne semble avoir ouvert de dossier. Aucune preuve publique n’a été mise au jour, dans les sources examinées pour cet article, indiquant que les données ont été utilisées, vendues ou exposées davantage. C’est ce que signifie ici « aucun préjudice réel enregistré » : une affirmation sur les éléments de preuve concernant un registre, et non un constat selon lequel l’exposition était sans danger.

L’écart compte parce que le risque intéressant était prospectif. L’accès en lecture expose ce qui était déjà là. L’accès en écriture à la couche de prompt expose ce que l’assistant dirait ensuite — des conseils empoisonnés, la suppression de garde-fous, des éléments confidentiels intégrés à une réponse qu’un consultant colle ensuite dans un document client. CodeWall a décrit ces conséquences comme étant à la portée de quiconque dispose du même accès. Personne n’a montré qu’elles avaient été exploitées. Les deux affirmations peuvent être vraies en même temps : la capacité était réelle, et le préjudice ne s’est pas matérialisé au vu des éléments que quiconque a publiés.

Pourquoi il est classé comme infrastructure et non comme une défaillance du modèle

L’archive classe ce dossier en INFRA, et le dossier technique confirme cette étiquette. Rien dans le récit de CodeWall n’exigeait de tromper le modèle. Il n’y a eu ni jailbreak, ni injection de prompt à partir d’un document, ni entrée adverse que l’assistant aurait été amené à avaler. Le point d’entrée était une documentation exposée, une vérification d’authentification manquante et une construction SQL non sécurisée ; le modèle était simplement l’élément le plus précieux derrière la porte.

L’analyse du 10 mars de Promptfoo établit la même distinction du côté défensif : Lilli « apparaît, au vu des informations publiques, comme un incident de sécurité applicative qui a atteint un système d’IA, et non comme une évasion de modèle », et une grande partie de ce que l’on appelle sécurité de l’IA relève encore de la sécurité logicielle, de la sécurité des données et de la gouvernance de la configuration. La partie propre à l’IA était le rayon d’impact, et non la violation — parce que les invites, les règles de routage et les paramètres de récupération étaient des données applicatives mutables, l’accès en écriture à la base de données est devenu la capacité de modifier le comportement de l’assistant sans toucher au code.

Qu’est-ce qui a changé par la suite ?

Les changements concrets sont ceux que les deux parties décrivent : les points de terminaison non authentifiés ont été fermés et vérifiés, l’environnement de développement a été mis hors ligne et la documentation publique de l’API a été bloquée. McKinsey a déclaré avoir trouvé la vulnérabilité, l’avoir confirmée et corrigée, et sa position publique est qu’aucune donnée client n’a été consultée.

Ce qui n’a pas changé, c’est l’exposition plus large décrite par cet incident. L’article de CodeWall se termine en affirmant que les prompts sont stockés dans des bases de données, transmis via des API et mis en cache dans des fichiers de configuration, et qu’ils bénéficient rarement de contrôles d’accès, d’un historique des versions ou d’une surveillance de l’intégrité — ce qui est une affirmation sur un secteur, et non une conclusion sur McKinsey, et doit être lu comme l’argument d’une entreprise qui vend des tests automatisés en continu. La société est en accès anticipé et cherche des partenaires de conception ; la divulgation sert aussi de démonstration.

Ce que le dossier laisse subsister est plus circonscrit et plus utile que l’argumentation. Un assistant à l’échelle de l’entreprise, une base de données de production, deux heures, aucun identifiant, et une ligne de préjudice qui semble fausse parce que les deux parties ayant accès aux faits affirment toutes deux que les données n’ont pas été utilisées. Les chefs d’accusation relèvent de l’une de ces parties. La vulnérabilité relève des deux.