Le 9 mars 2026, CodeWall a annoncé que son agent d’intelligence artificielle avait réussi à compromettre le chatbot interne de McKinsey, appelé Lilli.

L’agent autonome développé par CodeWall a été conçu pour détecter les vulnérabilités des systèmes, sans aucune connaissance interne de la plateforme de McKinsey & Company. Les chercheurs l’ont simplement déployé face au système et l’ont laissé tester les failles de manière autonome. En peu de temps, il a identifié plusieurs vulnérabilités critiques, dont la possibilité de modifier les prompts système.

Cette expérience, menée dans un cadre de recherche en cybersécurité, met en lumière un enjeu plus large. À mesure que les entreprises déploient des agents IA connectés à leurs systèmes internes, à leurs API et à leurs données sensibles, ces environnements deviennent des cibles de plus en plus attractives. Ces résultats montrent clairement les risques liés à un déploiement sans mesures de sécurité solides ni analyse des menaces adaptée.

Comment l’agent IA de CodeWall a compromis Lilli

L’agent IA a commencé par analyser la surface d’attaque de la plateforme. Il a rapidement découvert que la documentation des API était accessible publiquement, exposant plus de 200 endpoints.

Parmi eux, 22 ne nécessitaient aucune authentification. En exploitant cette faille avec une simple injection SQL, l’agent a réussi à obtenir un accès complet au système en moins de deux heures.

Lilli est utilisé par plus de 70 % des collaborateurs de McKinsey et traite plus de 500 000 requêtes chaque mois. Conçu pour répondre aux besoins du cabinet, il permet de discuter, analyser des documents et effectuer des recherches, avec un accès à des décennies de données internes.

Une fois l’accès obtenu, un volume important de données sensibles a été exposé, notamment :

• 46,5 millions de messages, incluant des discussions stratégiques, des informations financières et des échanges clients
• 3,68 millions de fragments de documents RAG, constituant la base de connaissances du système
• 728 000 fichiers, dont des documents Microsoft Office et des PDF
• 57 000 comptes utilisateurs, couvrant l’ensemble des employés utilisant le système
• 384 000 assistants IA internes, reflétant la manière dont l’IA est utilisée dans l’organisation

Plus inquiétant encore, les prompts système contrôlant le comportement de Lilli étaient également accessibles dans la base de données. CodeWall a signalé la vulnérabilité à McKinsey.

McKinsey a rapidement corrigé le problème et a publié un communiqué indiquant qu’aucune preuve ne montrait que des données clients ou confidentielles avaient été consultées par CodeWall ou par un tiers non autorisé. Les correctifs ont notamment supprimé les endpoints non sécurisés, mis hors ligne l’environnement de développement et restreint l’accès à la documentation API.

Les risques liés aux systèmes IA mal sécurisés

Cet incident met en évidence un défi croissant pour les entreprises. Les systèmes IA capables d’interroger des données internes, d’analyser des documents et de répondre aux employés sont souvent directement connectés à des volumes importants d’informations sensibles.

Lorsque les contrôles d’accès, les API ou les bases de données sont mal configurés, ces plateformes peuvent offrir un accès direct à des données critiques. Deux principaux risques se dégagent :

1. Exfiltration de données confidentielles : exposition à des tiers

Une faille de ce type pourrait exposer des données appartenant non seulement à McKinsey, mais aussi à ses clients, notamment des multinationales, des institutions financières, des agences gouvernementales et des organismes du secteur public. Sans contrôles d’accès solides et sans authentification, un seul endpoint vulnérable peut ouvrir la voie à un volume beaucoup plus large d’informations confidentielles.

2. Manipulation des prompts : risque sur l’intégrité des résultats

Un hacker pourrait modifier le comportement de l’agent IA, permettant une altération des données (data poisoning) ou la production de réponses volontairement trompeuses. Pour les organisations qui s’appuient sur des assistants IA pour récupérer ou résumer des informations, des prompts manipulés peuvent fausser les résultats ou faire apparaître des données incorrectes. Les utilisateurs accordent souvent une grande confiance aux résultats générés par l’IA, ce qui rend ce type d’attaque particulièrement dangereux.

Comment réduire les risques liés aux plateformes IA

Lorsque les agents IA interagissent avec des systèmes internes, des documents ou des API, ils deviennent une couche applicative à part entière. Ils doivent donc être sécurisés au même niveau que n’importe quel système manipulant des données sensibles.

Dans le cas de Lilli et d’autres assistants IA d’entreprise, le principal risque ne vient pas du modèle lui-même, mais de l’écosystème qui l’entoure : les identifiants, les API, les bases de documents internes et les permissions qui les relient. Les contrôles de sécurité et la modélisation des menaces pour les agents IA doivent être mis en place avant le déploiement, et non après que des chercheurs ou des attaquants aient découvert des failles.

Les organisations souhaitent réduire les risques liés aux plateformes IA internes doivent se concentrer sur plusieurs domaines pratiques :

• Traiter les agents IA comme des applications à privilèges élevés : appliquer des contrôles d’accès basés sur le principe du moindre privilège, limiter le périmètre des données que l’agent IA peut récupérer et séparer les accès entre différents domaines de données peut réduire fortement l’impact en cas d’abus ou de manipulation du système.
• Intégrer une modélisation des menaces spécifique à l’IA : les audits de sécurité classiques ne couvrent pas toujours des risques comme l’injection de prompts, l’exfiltration indirecte de données ou la manipulation du contexte. Avant de lancer un assistant IA interne, il est important de comprendre comment le système interagit avec les bases de données et les API, et de tester son comportement face à des prompts malveillants conçus pour contourner les protections.
• Surveiller et journaliser l’activité de l’IA : journaliser les requêtes qui accèdent à des données internes, mettre en place des alertes en cas d’accès inhabituels, et intégrer l’activité des agents IA aux outils de supervision existants aide à détecter les abus ou les tentatives d’exploration du système.
• Inclure les plateformes IA dans les tests d’intrusion : intégrer les assistants IA aux tests d’intrusion et aux exercices de red team, notamment sur les scénarios d’injection de prompts et d’exfiltration de données, permet de détecter les failles avant les hackers.

How Outpost24 helps

Outpost24 propose une solution de services de tests d’intrusion pour l’IA qui permet de identifier les risques spécifiques à l’IA avant les hackers. Nos pentesters expérimentés évaluent le comportement de vos systèmes IA face à des scénarios d’attaque réels, en utilisant des méthodologies spécifiques à l’IA et les bonnes pratiques OSAI+.

Outpost24 dispose de plusieurs décennies d’expérience dans l’aide aux organisations pour gérer leur surface d’attaque, avec des racines fortes dans le hacking éthique. Contactez-nous dès aujourd’hui si vous souhaitez découvrir comment nous pouvons vous aider à sécuriser vos applications.

Regardez notre webinaire dans lequel les experts Outpost24 échangent sur le hack de l’IA de McKinsey. Vous y découvrirez pourquoi les systèmes d’IA créent de nouvelles surfaces d’attaque, quelles sont les erreurs les plus fréquentes des équipes de sécurité lors des tests de systèmes IA, et comment les tests d’intrusion sur l’IA permettent d’identifier les vulnérabilités avant les attaquants. Le webinaire est disponible à la demande ici.