Quatre échecs. Quatre couches. L’architecture elle-même est la vulnérabilité.

Un épisode récent du 10 avril 2026 du podcast Hard Fork du New York Times a examiné les implications de sécurité des systèmes d’intelligence artificielle avancés et a posé une question que l’industrie a évitée : et si la sécurité informatique n’était pas en sous-performance, mais fondamentalement mal conçue ?

L’épisode a été diffusé quelques semaines après une série d’incidents qui ont rendu la réponse difficile à ignorer. En un seul mois, un agent autonome d’IA a violé la plate-forme d’IA interne de McKinsey en deux heures. Une attaque de la chaîne d’approvisionnement contre une bibliothèque d’IA open source largement utilisée a eu des répercussions sur les entreprises en aval. Des chercheurs ont montré que le matériel censé être la dernière ligne de défense peut être compromis avec des pièces de rechange disponibles sur le marché pour moins de mille dollars. Et Anthropic a révélé qu’un modèle de frontière avait découvert de manière autonome des milliers de vulnérabilités zero-day dans le code que l’industrie considérait comme stable.

Quatre incidents. Quatre couches de la pile d’IA : application, orchestration, matériel et système d’exploitation. Chacun a révélé des limites significatives dans les contrôles conçus pour les protéger.

La fin de la pensée de périmètre

La sécurité informatique traditionnelle repose sur un seul principe : avec suffisamment de contrôles, de surveillance et d’investissements, les systèmes peuvent être sécurisés. Ce principe a façonné des décennies d’architecture, y compris les pare-feu, la gestion des identités, la sécurité des points de terminaison et les plates-formes SIEM, toutes construites sur l’idée que la visibilité et la gestion serrée équivalent à la sécurité.

L’industrie a commencé à passer à l’architecture Zero Trust, ce qui reflète une reconnaissance croissante que les frontières réseau traditionnelles ne peuvent plus être considérées comme fiables. Cependant, même à mesure que les modèles de confiance évoluent, les systèmes d’IA introduisent un défi différent : les données sensibles sont régulièrement agrégées, traitées et partagées à travers plusieurs couches d’infrastructure.

Cette approche avait du sens lorsque les systèmes étaient relativement centralisés et que les données restaient dans des limites clairement définies. Elle devient beaucoup moins efficace lorsque les données se déplacent en continu à travers les nuages, les API, les fournisseurs tiers et les pipelines d’IA, tandis que les utilisateurs et les ressources de calcul sont distribués à l’échelle mondiale. Le périmètre n’est plus une limite. C’est une surface en constante évolution, et nous appliquons toujours une pensée basée sur le contrôle à des systèmes qui ne peuvent pas réaliste être contrôlés.

Échec de la couche d’application : Lilli de McKinsey

Le 9 mars 2026, la startup de sécurité CodeWall a publié une divulgation qui a mis en évidence les risques auxquels sont confrontées les organisations qui déployant l’IA en interne.

L’agent offensif autonome de CodeWall, sans informations d’identification, sans connaissance interne et sans orientation humaine, a obtenu un accès en lecture et en écriture à la base de données de production derrière Lilli, la plate-forme d’IA interne de McKinsey, en moins de deux heures. Lilli est utilisée par plus de 40 000 employés pour des travaux de stratégie, de recherche de clients et d’analyse de documents, générant des centaines de milliers de requêtes par mois.

Le point d’entrée n’était pas sophistiqué. L’agent a trouvé une documentation d’API publiquement exposée répertoriant plus de 200 points de terminaison, 22 d’entre eux n’exigeant aucune authentification. Les vulnérabilités impliquées reflètent les risques mis en évidence dans la OWASP Top 10 pour les applications de modèles de langage, en particulier autour des interfaces exposées, des intégrations non sécurisées et de la confiance excessive dans les systèmes connectés.

L’une de ces interfaces contenait une vulnérabilité d’injection SQL cachée dans les noms de champs JSON plutôt que dans les valeurs de saisie, où la plupart des analyseurs automatisés regardent. À partir de là, l’agent a itéré à travers l’injection SQL aveugle jusqu’à ce que les données de production deviennent accessibles.

Ce qu’il a accédé : des dizaines de millions de messages de chat en texte clair, des centaines de milliers de fichiers, des dizaines de milliers de comptes d’utilisateurs et des millions de fragments de documents RAG représentant des années de recherche propriétaire. Il a également identifié les invites de système qui régissaient le comportement de Lilli pour chaque utilisateur.

La constatation la plus alarmante n’était pas le volume. C’était que les invites de système étaient accessibles en écriture. Un attaquant aurait pu réécrire silencieusement les instructions qui régissaient les sorties de Lilli, empoisonner les conseils stratégiques, intégrer des données confidentielles dans les réponses ou supprimer les garde-fous entièrement, avec une seule mise à jour de base de données. Aucun déploiement. Aucun changement de code. Aucune trace dans les journaux d’application.

Dans un communiqué public, McKinsey a déclaré qu’il avait résolu le problème dans les heures qui ont suivi et, à la suite d’une enquête menée par une société de forensique tiers, n’a trouvé aucune preuve que des données confidentielles de clients aient été consultées. Cette réponse compte. Mais elle ne change pas la leçon structurelle : une classe de vulnérabilités vieille de plusieurs décennies a exposé la mémoire opérationnelle d’un système d’IA moderne parce que les données derrière lui existaient sous forme lisible.

Échec de la couche d’orchestration : l’attaque LiteLLM

Trois semaines plus tard, le même schéma est apparu sous un angle différent et à travers une autre couche.

LiteLLM est une passerelle d’IA open source utilisée par des milliers d’entreprises pour acheminer les requêtes vers les fournisseurs d’IA. Sa position dans la pile est critique : elle se situe à la couche d’orchestration, détenant les clés d’API pour chaque fournisseur auquel elle se connecte. Toute compromission à ce niveau expose les informations d’identification à travers chaque service intégré.

Selon un rapport d’incident PyPI, le groupe d’acteurs menaçants TeamPCP a exploité les informations d’identification liées à une dépendance dans le pipeline CI/CD de LiteLLM et a utilisé l’accès du mainteneur pour publier deux versions compromises du package LiteLLM directement sur PyPI. Les versions compromises ont été disponibles pendant moins d’une heure avant d’être supprimées. L’opération n’a été découverte que parce que le malware contenait un bogue qui a provoqué la panne d’un ordinateur de chercheur.

La chaîne d’approvisionnement était le vecteur. La couche d’orchestration était la cible. En compromettant une seule dépendance en amont, les attaquants ont atteint la couche où vivaient les clés de fournisseur de chaque entreprise en aval.

L’équipe LiteLLM a plus tard détaillé l’incident et les efforts d’atténuation dans une divulgation publique GitHub.

Le rayon d’action est devenu visible presque immédiatement. TechCrunch, Fortune et The Register ont rapporté que Mercor, une startup de recrutement d’IA de 10 milliards de dollars travaillant avec des entreprises telles que OpenAI, Anthropic, Meta et Google, était parmi les organisations touchées. Les attaquants ont affirmé avoir obtenu de grandes quantités de données, notamment des profils de candidats, des informations personnelles, des entretiens vidéo de contractuels, du code source et des clés d’API. Meta a suspendu son travail avec Mercor en attendant l’enquête. Des rapports ultérieurs ont indiqué des modèles de malware similaires apparaissant dans d’autres outils et packages de développement, suggérant que l’opération pourrait s’étendre au-delà d’un seul projet.

L’incident LiteLLM n’était pas une anomalie. C’était le système se comportant comme conçu. Chaque composant d’un pipeline d’IA nécessite un accès à des données utilisables pour fonctionner, ce qui signifie que chaque composant est également un point de extraction potentiel. Épingler les dépendances et faire pivoter les informations d’identification sont des réponses nécessaires, mais ils s’adressent à l’incident, pas à l’architecture.

Échec de la couche matérielle : TEE.fail

Si la violation de McKinsey a démontré que la couche d’application ne peut pas être considérée comme fiable, et l’attaque LiteLLM a démontré que la chaîne d’approvisionnement ne peut pas être considérée comme fiable, la recherche TEE.fail a démontré que le matériel censé compenser les deux ne peut pas non plus être entièrement considéré comme fiable.

Le 28 octobre 2025, des chercheurs de Georgia Tech, Purdue University et Synkhronix ont publié TEE.fail, une attaque par canal auxiliaire qui extrait des clés cryptographiques des environnements d’exécution de confiance en utilisant l’interposition du bus de mémoire physique sur les serveurs DDR5. L’attaque affecte Intel SGX, Intel TDX et AMD SEV-SNP, y compris sur des systèmes entièrement corrigés, avec le chiffrement de texte de AMD activé. Ce sont les technologies largement promues comme fondement de l’informatique confidentielle.

Les chercheurs ont extrait des clés d’attestation : le matériel cryptographique utilisé pour vérifier que les charges de travail s’exécutent à l’intérieur d’environnements sécurisés. Avec ces clés, un système compromis peut se présenter comme fiable tout en fonctionnant entièrement en dehors des protections attendues. Les chercheurs ont démontré cela directement : ils ont forgé des attestations TDX sur BuilderNet d’Ethereum pour accéder à des données de transaction confidentielles et ont simulé des attestations Intel et NVIDIA pour exécuter des charges de travail en dehors de tout TEE tout en apparaissant légitimes.

L’implication NVIDIA est importante pour l’IA en particulier. Puisque l’attestation GPU dépend de l’attestation CPU, une chaîne de confiance CPU compromise peut miner les garanties fournies par les environnements d’inférence d’IA confidentiels. Le fondement matériel de l’inférence d’IA confidentielle est, dans ce modèle de menace, conditionnel à une TEE CPU qui a été démontrée comme compromise.

Les fournisseurs de matériel ont répondu avec des avis formels. AMD a déclaré que les attaques d’accès physique sortent de son modèle de menace standard et a indiqué qu’il ne publierait pas de mises à jour de micrologiciel. Intel et NVIDIA ont reconnu les résultats et ont indiqué des travaux d’atténuation en cours. Ces réponses sont raisonnables dans leurs modèles de menace. Ils mettent également en évidence une limite importante : les garanties de sécurité basée sur le matériel dépendent d’hypothèses, notamment le contrôle physique, que les déploiements souverains, réglementés et adverses ne peuvent pas toujours faire.

TEE.fail ne rend pas l’isolation matérielle sans importance. Il démontre qu’elle est conditionnelle.

Échec de la couche OS : La révélation de Mythos

Si les trois premiers incidents ont remis en question la couche d’application, la couche d’orchestration et la couche matérielle, une quatrième divulgation en avril 2026 a remis en question la couche sous-jacente à toutes les autres : les systèmes d’exploitation et les bibliothèques de base sur lesquelles toutes les autres couches s’exécutent.

Le 7 avril 2026, Anthropic a annoncé Claude Mythos Preview, un modèle de frontière qu’il a refusé de publier publiquement en raison de ses capacités de sécurité offensive, et a lancé simultanément Project Glasswing, un consortium avec AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, la Linux Foundation, Microsoft, NVIDIA et Palo Alto Networks. Anthropic a rapporté qu’en quelques semaines, Mythos avait découvert de manière autonome des milliers de vulnérabilités inconnues à travers les principaux systèmes d’exploitation et les navigateurs Web et était capable de produire des exploits fonctionnels pour la plupart d’entre eux.

Les constatations spécifiques sont plus difficiles à rejeter que toute synthèse le suggère. Un bug de 27 ans dans OpenBSD. Un bug d’exécution de code à distance de 17 ans dans le serveur NFS de FreeBSD, désormais suivi sous le numéro CVE-2026-4747, qui accorde un accès root à un attaquant non authentifié. Une vulnérabilité de 16 ans dans FFmpeg, l’une des bibliothèques de médias les plus déployées sur Internet. Dans un cas, un ingénieur Anthropic sans formation en sécurité a demandé au modèle de rechercher des failles d’exécution de code à distance pendant la nuit et s’est réveillé avec un exploit fonctionnel complet.

Ces constatations sont au niveau du système d’exploitation. OpenBSD et FreeBSD sont des noyaux. NFS est un sous-système de mise en réseau de noyau. FFmpeg est une bibliothèque de système qui est livrée avec la plupart des distributions Linux et sous-tend les pipelines de médias à travers Internet. La couche OS était considérée comme sûre non parce qu’elle avait été prouvée sécurisée, mais parce que trouver des failles profondes en elle nécessitait une expertise humaine rare et coûteuse. Cette hypothèse était la meilleure heuristique disponible. Elle n’a jamais été une garantie.

Cette contrainte s’est maintenant assouplie. Anthropic lui-même a présenté cela comme un changement à double usage : les mêmes capacités qui permettent à un modèle de frontière de trouver et de corriger des vulnérabilités à grande échelle permettent également, entre de mauvaises mains, de les trouver et de les exploiter à grande échelle. La décision d’Anthropic de restreindre l’accès via Project Glasswing reflète cette réalité. Elle ne la résout pas. Des capacités similaires se propageront, selon l’évaluation de l’entreprise. Le coût de l’audit de code hérité s’est effondré, et avec lui la défense implicite que ce code était trop obscur, trop ancien ou trop largement examiné pour contenir encore des failles critiques.

C’est également là que les quatre incidents se cumulent. La couche matérielle de protection de l’informatique confidentielle ne fonctionne pas en isolation. Elle fonctionne comme du code de noyau. Intel TDX fonctionne dans le noyau. Les pilotes GPU NVIDIA fonctionnent comme des modules de noyau. La chaîne d’attestation TEE dépend d’un système d’exploitation fiable pour rapporter fidèlement ce qu’il fait. Si la couche OS sous-jacente à votre TEE a des vulnérabilités latentes de plusieurs décennies, et qu’un modèle de frontière peut désormais les trouver à une vitesse industrielle, alors la sécurité conditionnelle de la couche matérielle dépend d’une couche OS dont les garanties de sécurité viennent d’être affaiblies par le même cycle de divulgation.

Les trois premiers incidents décrivent comment les systèmes d’IA sont violés aujourd’hui. Mythos décrit le rythme auquel tout ce qui se trouve en dessous, y compris les systèmes d’exploitation, les modules de noyau et les bibliothèques de système, va être réexaminé par des machines. La violation de McKinsey a exploité une classe de vulnérabilité d’injection SQL qui existait depuis plus de deux décennies. Les vulnérabilités de ce type sont précisément celles que les modèles de la classe Mythos sont démontrablement capables de trouver à une échelle industrielle.

Le modèle

Dans chaque cas, les données étaient en texte clair au moment où cela importait.

La couche d’application les traitait en clair. La couche d’orchestration les acheminait en clair. La couche matérielle, malgré ses protections, a finalement nécessité une décryption au point d’exécution. La couche OS sous-jacente à toutes les trois fonctionnait sur elles en clair par définition. Quatre couches, quatre échecs, et à chaque couche la même condition s’est appliquée : lorsque la violation a eu lieu, les données étaient lisibles.

Ceci n’est pas une collection d’échecs isolés. C’est l’architecture elle-même.

Les systèmes d’IA modernes sont conçus pour fonctionner sur des données lisibles. Chaque couche, y compris la récupération, l’acheminement, l’inférence et l’exécution d’outils, nécessite un accès en clair pour fonctionner. Ce choix de conception signifie que toute violation à n’importe quelle couche expose les données derrière elle.

La question n’est pas de savoir si une couche sera compromise. C’est ce que l’attaquant trouve lorsqu’il est.

De la violation supposée à l’exposition zéro

L’industrie a déjà commencé à passer de « prévenir la violation » à « supposer la violation ». Mais la plupart des architectures n’ont pas suivi les implications.

Si la violation est inévitable, alors la vraie question n’est pas de savoir comment garder les attaquants à l’extérieur. C’est ce qui se passe lorsqu’ils entrent. Actuellement, la réponse est simple : ils obtiennent les données. Parce que, malgré tous les investissements dans les infrastructures de sécurité, les données sont toujours exposées au moment où elles deviennent précieuses, lorsqu’elles sont utilisées.

La réponse de l’industrie a été prévisible : plus de surveillance, une détection plus rapide, des couches supplémentaires de calcul confidentiel. Ce sont des améliorations. Mais ils ne résolvent pas le problème de base. Ils supposent toujours qu’une couche – logiciel, matériel ou opérationnel – peut être considérée comme fiable pour garder les données en clair en toute sécurité.

L’alternative est de supprimer complètement les données en clair. Non pas pour sécuriser les couches autour des données, mais pour rendre les données elles-mêmes inaccessibles à quiconque les atteint. Le calcul sur des données chiffrées, où les invites, les poids de modèle et les sorties restent chiffrés tout au long du pipeline, répond à l’exposition que chacun de ces incidents a exploitée.

Les progrès de l’homomorphisme complet et d’autres techniques de calcul à préservation de la confidentialité commencent à rendre les architectures qui minimisent ou éliminent l’exposition en clair de plus en plus pratiques pour les charges de travail d’IA réelles. Même si des défis de performances, d’évolutivité et de mise en œuvre importants restent, l’objectif est fondamentalement différent des contrôles de sécurité traditionnels : réduire la valeur d’une violation réussie plutôt que de rendre simplement la violation moins probable.

Le changement n’est pas d’un outil de sécurité à un autre. C’est de la sécurité des systèmes à la réduction de l’exposition. De l’infrastructure de confiance à des données de confiance zéro. De la gestion des risques à la minimisation de la surface d’attaque elle-même.

Ce qui vient ensuite

La discussion Hard Fork a soulevé la question de savoir si la sécurité informatique est fondamentalement mal conçue. Les preuves des dernières semaines suggèrent que la réponse est oui, au moins pour l’IA.

L’ancien modèle supposait que les systèmes pouvaient être sécurisés, que les violations pouvaient être contenues et que l’exposition pouvait être gérée. La réalité émergente est que les violations doivent être supposées et que l’exposition doit être minimisée. Les incidents décrits ici suggèrent que la sécurité des systèmes d’IA peut de plus en plus dépendre de la réduction de la quantité de données sensibles disponibles lorsque les contrôles échouent.

Les vulnérabilités exposées à travers ces quatre incidents ne sont pas confinées à une seule couche. Elles sont systémiques. Les résoudre nécessitera plus que des améliorations incrémentielles. Cela nécessitera un changement de la sécurité des systèmes à la réduction de l’exposition, de la défense du périmètre autour des données à la suppression des données en clair que le périmètre était censé protéger.

La sécurité de l’IA n’est plus à propos de garder les attaquants à l’extérieur. C’est à propos de s’assurer que lorsqu’ils entrent, et qu’ils le feront, il n’y a rien de lisible pour eux à trouver.