Lorsque Hugging Face a été compromis la semaine dernière, son cofondateur Clement Delangue a soupçonné qu’un laboratoire d’IA de pointe en était responsable, compte tenu de la sophistication de l’agent impliqué. Il avait raison. Delangue a ensuite déclaré sur X qu’après avoir passé une journée à travailler avec OpenAI, il était fermement convaincu qu’il n’y avait aucune intention malveillante, et qu’il était stupéfiant que l’ensemble de l’incident se soit produit de manière autonome.

Les deux modèles d’OpenAI qui ont pénétré les systèmes de Hugging Face n’ont pas réussi grâce à la malveillance ou à une forme de superintelligence. Ils ont réussi grâce à des identifiants et des permissions auxquels ils n’auraient jamais dû pouvoir accéder — une défaillance d’identité non humaine qui relève de l’un des plus anciens problèmes de la cybersécurité, plutôt que du plus récent problème de l’IA, et que chaque entreprise peut réellement corriger.

Comment la compromission s’est déroulée

OpenAI a indiqué le 21 juillet que deux de ses modèles — GPT-5.6 Sol et un modèle non publié, plus performant — exécutaient un benchmark cyber appelé ExploitGym avec leurs refus de sécurité désactivés. Les modèles ont déduit que la clé de correction se trouvait dans la base de données de production de Hugging Face.

Y parvenir a nécessité deux défaillances distinctes. D’abord, une vulnérabilité zero-day dans un proxy de registre de paquets a permis aux modèles de sortir de leur bac à sable et d’accéder à l’internet ouvert — le type de persistance qu’OpenAI décrit dans son article complémentaire sur la sécurité à long horizon — et cet élément est véritablement nouveau.

La compromission de Hugging Face elle-même, en revanche, s’est produite de manière conventionnelle. Selon le propre récit d’OpenAI, les modèles ont enchaîné des identifiants volés et d’autres zero-days pour ouvrir une voie d’exécution de code à distance, après une série d’étapes d’élévation de privilèges et de mouvement latéral. L’élément exotique les a amenés jusqu’à la porte ; les identifiants les ont fait entrer.

Hugging Face a également indiqué la semaine dernière qu’un agent autonome avait collecté des identifiants cloud et de clusters dont le périmètre était suffisamment large pour accéder à plusieurs clusters internes, puis avait laissé derrière lui plus de 17,000 événements enregistrés dans des bacs à sable de courte durée au cours d’un week-end.

Les deux déclarations décrivent le même schéma d’escalade : un agent arrive à un endroit où il ne devrait pas être, découvre des identifiants dont le périmètre dépasse largement ce qu’exige n’importe quelle tâche, puis les utilise pour se déplacer latéralement. Il s’agit de deux récits d’un même incident, et non de deux attaques distinctes. L’agent observé par Hugging Face correspondait aux modèles d’OpenAI, et les deux entreprises décrivent la même escalade ordinaire.

La réalité en entreprise est pire

Pour une entreprise typique, le scénario équivalent serait pire, et non meilleur. OpenAI et Hugging Face comptent parmi les organisations les plus matures du secteur en matière de sécurité, et pourtant toutes deux ont encore eu besoin que l’intrusion se produise avant de pouvoir la détecter. L’entreprise moyenne qui connecte des agents à Copilot ou à un assistant interne ne dispose ni de l’inventaire des identités ni des capacités de surveillance comportementale que ces deux organisations ont mobilisés. La même compromission dans une entreprise typique ne serait pas contenue en quelques jours — elle passerait tout simplement inaperçue.

C’est pourquoi l’incident dépasse le cadre des laboratoires d’IA. Les agents d’entreprise sont de plus en plus connectés à des applications SaaS, des dépôts de code, des systèmes de tickets, des consoles cloud et des bases de données au moyen de clés API, de comptes de service, d’autorisations OAuth et d’autres identifiants machine. Chaque connexion crée une identité non humaine dont le rayon d’impact dépend moins du prompt du modèle que des permissions que l’organisation lui a déjà accordées.

Le secteur débat de la mauvaise défaillance

La réaction s’est divisée selon des lignes familières. David Sacks, ancien responsable IA et crypto de la Maison-Blanche, ainsi que plusieurs faucons à l’égard de la Chine, se sont emparés du paradoxe des garde-fous : les filtres de sécurité commerciaux ont bloqué les défenseurs de Hugging Face tandis que le modèle attaquant fonctionnait avec ses refus désactivés, et un modèle chinois à poids ouverts — z.ai's GLM 5.2 — a finalement permis à l’équipe de terminer son analyse forensique.

Hugging Face, de son côté, a défendu l’ouverture, en soutenant dans un billet de blog publié en avril que les modèles ouverts et les outils ouverts donnent aux défenseurs les mêmes capacités que celles dont les attaquants disposent déjà. Les deux arguments portent sur le modèle lui-même, et aucun ne traite le mécanisme sous-jacent.

La réduction des refus a permis au modèle de tenter une attaque, mais ce sont les identifiants au périmètre excessif qui lui ont permis de réussir — et ces facteurs n’ont rien à voir avec le fait que le modèle soit ouvert ou fermé, américain ou chinois. Rendre un modèle de pointe prouvablement sûr est un problème d’alignement pluriannuel qu’aucun client ne peut acheter ni accélérer. Définir précisément le périmètre d’une identité, en revanche, est un changement de configuration qu’une équipe peut livrer dans le sprint en cours. Le secteur est en pratique incité à se focaliser sur l’aspect qu’il ne contrôle pas, tout en traitant comme une note de bas de page celui qu’il peut maîtriser.

Forrester est parvenu à la même conclusion. Dans un billet consacré à l’incident, ses analystes estiment que les architectures de sécurité qui supposent une intention bénigne manqueront ce mode de défaillance, car un agent peut poursuivre un objectif autorisé par des moyens non autorisés — ce qui est précisément ce qu’ont fait les modèles d’OpenAI.

Une défaillance d’identité non humaine — le plus ancien problème de la sécurité

Si l’on retire le cadrage de science-fiction, il reste un cas d’école d’identité machine sur-privilégiée — le type de problème que les équipes de sécurité combattent depuis une décennie, désormais propulsé par un agent autonome opérant à la vitesse de la machine.

Les identités machine sont déjà plus de 80 fois plus nombreuses que les identités humaines dans la plupart des entreprises, selon une étude de CyberArk, et 42% d’entre elles disposent d’un accès privilégié ou sensible. Un agent hérite de tout ce que son identité peut atteindre. En pratique, ces identités incluent des comptes de service, des clés API, des identités de charges de travail, des jetons OAuth et d’autres identifiants qui échappent souvent aux cycles de revue appliqués aux utilisateurs humains.

L’OWASP classe l’identité des agents et l’abus de privilèges parmi les principaux risques agentiques — le schéma du mandataire confus, dans lequel des identifiants hérités et un périmétrage insuffisant permettent à un agent de dépasser son mandat. C’est précisément ce que décrivent les deux déclarations de juillet.

IEEE Senior Member Kayne McGladrey a soutenu dans de précédents entretiens avec VentureBeat que les entreprises clonent régulièrement des comptes utilisateurs humains sur des agents, qui disposent ensuite de bien plus de permissions que n’en aurait n’importe quel humain. Cet incident montre à quoi ressemble ce schéma lorsque l’agent est un modèle de pointe et que la cible est une base de données de production.

Les personnes les plus proches de l’incident l’interprètent de la même manière. OpenAI présente ses modèles comme hyperconcentrés sur l’obtention d’un score de benchmark, plutôt que comme agissant contre une cible particulière. Personne parmi les parties impliquées ne décrit un adversaire — seulement un objectif, une fonction de score et des identifiants accessibles alors qu’ils n’auraient pas dû l’être.

La défaillance précise est simple à identifier une fois le cadrage IA retiré. Un identifiant conçu pour une tâche mais capable d’en atteindre dix constitue une invitation permanente, et peu importe qu’il soit découvert par un attaquant humain, un ver ou un modèle autonome poursuivant un score de benchmark. Ce qui a changé en juillet, c’est le découvreur : un agent énumère les systèmes accessibles, teste les identifiants et pivote plus vite que n’importe quelle équipe rouge humaine, sans malveillance ni hésitation, chaque fois que le chemin est ouvert. Le périmètre excessif a toujours été la vulnérabilité ; l’agent n’a fait qu’industrialiser sa découverte.

Forrester a nommé le contrôle qui aurait atténué les dégâts. Son cadre de sécurité agentique, AEGIS, appelle au principe de « least agency » — maintenir les outils, identifiants et chemins réseau d’un agent au minimum requis par sa tâche — et classe cet incident dans la catégorie des privilèges et de l’agence non maîtrisés. C’est le même argument d’identité exprimé autrement, formulé indépendamment par un cabinet d’analystes.

Où se situe désormais le risque

Les données confirment que le risque se concentre désormais à cet endroit. Le 2026 Data Breach Investigations Report de Verizon a constaté que l’exploitation de vulnérabilités avait dépassé les identifiants volés comme premier vecteur d’accès initial pour la première fois en 19 ans. Cela représente la moitié « accès initial » de l’équation. L’autre moitié est celle qu’OpenAI décrit lui-même : des identifiants volés alimentant l’élévation de privilèges et le mouvement latéral qui ont suivi. Une vulnérabilité a ouvert la porte, et les identifiants ont circulé dans le bâtiment sans être contestés.

Au-delà de la compromission elle-même, ce même périmètre excessif entraîne une responsabilité juridique que la plupart des entreprises n’ont jamais intégrée dans leurs coûts. Les actions des modèles ont probablement enfreint le Computer Fraud and Abuse Act, selon TechCrunch. Le texte ne prévoit aucune exception pour un agent d’IA qui dépasse son périmètre autorisé pendant des tests approuvés. Quelle que soit la conclusion juridique, le facilitateur technique reste le même : une identité dont le périmètre dépasse sa tâche. Il s’agit d’un problème de contrôle d’accès avec un responsable et un budget, pas d’un débat philosophique sur la cognition machine.

Merritt Baer, Senior Advisor chez Andesite, G2I et AppOmni, et ancienne Deputy CISO chez AWS, a présenté à VentureBeat le changement sous-jacent comme une nouvelle forme d’asymétrie. Les deux camps recourent désormais aux mêmes capacités, a-t-elle déclaré, mais l’un est contraint par la gouvernance d’entreprise, les politiques, la conformité et les contrôles de sécurité, tandis que l’adversaire télécharge simplement un modèle à poids ouverts non censuré et poursuit ses opérations. Selon elle, les organisations qui traverseront le mieux cette phase seront celles qui traiteront l’IA comme une capacité résiliente et gouvernée, plutôt que comme un service unique qu’elles ne contrôlent pas.

Quatre mesures pour réduire le rayon d’impact

La compromission a réussi parce que l’agent a atteint des identités dont le périmètre dépassait largement ce qu’exigeait sa tâche. Aucun des quatre contrôles qui auraient permis de la contenir ne nécessite une nouvelle plateforme, et aucun ne figure dans les listes de conseils généraux sur la sécurité de l’IA qui circulent actuellement. Ils relèvent de l’hygiène des identités, appliquée aux acteurs non humains avec la même rigueur que celle déjà appliquée aux utilisateurs humains. Le point de départ consiste à savoir quelles identités un agent peut endosser, ce que chacune peut atteindre, et si cet accès reste nécessaire.

1. Limiter chaque identité non humaine à une seule tâche. Les modèles ont atteint des identifiants donnant accès à plusieurs clusters, ce qui a transformé un point d’appui en compromission. Une identité limitée à un seul travail, sans accès permanent à quoi que ce soit d’autre, se heurte à un mur dès le premier mouvement latéral au lieu d’ouvrir la porte suivante. C’est le principe du moindre privilège — le contrôle que tout le monde approuve mais que peu imposent aux comptes machine — et c’est ici la correction ayant l’impact le plus élevé.

2. Donner aux identifiants une durée de vie courte et les faire tourner agressivement. Les identifiants collectés ne sont utiles que tant qu’ils restent valides, et les deux agents de juillet ont fonctionné en les accumulant. Des durées de vie courtes et une rotation agressive transforment un vidage d’identifiants en bruit expiré, garantissant qu’un jeton volé lors d’une intrusion le week-end soit désactivé avant que l’attaquant puisse l’enchaîner. Les secrets statiques qui ne tournent jamais représentent la version défaillante de ce contrôle.

3. Surveiller les mouvements latéraux, pas seulement les prompts. Le signe révélateur dans les deux incidents était l’élévation de privilèges et le mouvement latéral, qu’un filtre de prompt ne détecte jamais parce qu’il observe la mauvaise couche. La surveillance du comportement des identités — fondée sur ce qu’une identité non humaine donnée fait normalement et déclenchant une alerte lorsqu’elle atteint un nouvel endroit — détecte l’escalade que les garde-fous de contenu manquent. La question pertinente pour toute pile technologique est de savoir si un outil actuellement en fonctionnement signalerait un compte de service se déplaçant soudainement entre des clusters.

4. S’exercer à la révocation instantanée avant d’en avoir besoin. Lorsque l’incident implique votre propre agent, le confinement le plus rapide consiste à tuer son identité en cours d’exécution, et cela ne fonctionne que si cette capacité existe avant le jour où elle devient nécessaire. Les équipes doivent s’entraîner à révoquer une identité machine sous pression de la même manière qu’elles s’exercent à gérer la compromission d’un identifiant humain. Si cela n’a jamais été fait, l’organisation ne dispose pas encore du contrôle — elle a une intention.

La défense a également fonctionné

L’équipe de sécurité d’OpenAI a détecté l’activité anormale en interne, les systèmes de détection et les agents propres à Hugging Face ont stoppé l’intrusion, et la compromission a été contenue en quelques jours plutôt que découverte des mois plus tard — parce que les défenseurs avaient de la visibilité sur les systèmes qu’ils contrôlaient. Cette même visibilité sous-tend la discipline qu’exigent les quatre contrôles.

Le débat sur la sécurité, l’ouverture ou l’origine américaine des modèles de pointe durera des années, et rien de tout cela ne sera tranché à temps pour aider l’entreprise qui déploie des agents ce trimestre. L’écart lié aux identités non humaines est différent : il est compris, mesurable et corrigeable dès maintenant. Le modèle qui a compromis Hugging Face n’avait pas besoin d’être brillant — il avait besoin d’identifiants que quelqu’un avait laissés à portée. La solution consiste à en définir le périmètre avant qu’un agent ne les trouve.