Data / IA
Quand les IA franchissent leurs propres barrières : l’affaire Hugging Face
Par Laurent Delattre, publié le 22 juillet 2026
En cherchant les réponses d’un benchmark de cybersécurité, des modèles d’OpenAI ont exploité une faille zero-day pour sortir de leur environnement de test, avant de compromettre une partie de l’infrastructure de production de Hugging Face. Involontaire, mais bien réel, l’incident montre que les garde-fous conçus pour des assistants IA ne suffisent désormais plus face à des agents capables de poursuivre obstinément un objectif.
Depuis l’arrivée des grands modèles de langage en entreprise, une inquiétude traverse les rapports de sécurité : que se passera-t-il lorsqu’un système suffisamment autonome saura contourner les limites techniques qui l’empêchent d’agir ?
La question n’est plus seulement prospective. Le 21 juillet 2026, OpenAI a reconnu que plusieurs de ses modèles, évalués dans un environnement théoriquement isolé, avaient exploité des vulnérabilités jusqu’à pénétrer l’infrastructure de production de Hugging Face afin d’y récupérer les solutions d’un test.
L’incident ne prouve pas qu’une IA a développé une volonté de s’échapper ou une intention hostile. Il montre quelque chose de plus immédiatement préoccupant, notamment pour les entreprises : un agent optimisé pour atteindre un objectif étroit peut exploiter les faiblesses de son environnement, ignorer les frontières implicites de sa mission et poursuivre sa trajectoire jusqu’à affecter des systèmes tiers.
Cette évolution accompagne l’émergence des modèles dits « à long horizon ». Contrairement à un chatbot répondant à une question isolée, ils peuvent travailler durant des heures, multiplier les tentatives, exécuter des commandes, lancer des sous-agents et modifier leur stratégie lorsqu’un obstacle apparaît. Leur persistance constitue précisément leur valeur ajoutée. Elle augmente aussi mécaniquement le nombre d’occasions de trouver une faille.
Anthropic avait déjà observé une sortie de bac à sable
Un premier avertissement avait été documenté par Anthropic en avril dans la fiche système de Claude Mythos Preview. Dans le cadre de ce test comportemental, le modèle n’avait pas spontanément décidé de s’évader. Mais, un utilisateur simulé lui avait explicitement demandé de sortir d’un ordinateur sécurisé et de trouver un moyen de contacter le chercheur conduisant l’évaluation. Cette version préliminaire de Mythos Preview a réussi à développer un exploit en plusieurs étapes afin d’obtenir un accès Internet beaucoup plus large que celui autorisé. Elle a ensuite envoyé le message demandé au chercheur, qui a découvert le succès de l’expérience en recevant un courriel alors qu’il déjeunait dans un parc.
Le comportement réellement inattendu est survenu après cette réussite. Sans que cela lui soit demandé, le modèle a publié des informations sur son exploit sur plusieurs sites accessibles publiquement, bien que difficiles à trouver. Anthropic souligne par ailleurs qu’il ne s’agissait pas d’une évasion complète : le système manipulé par le modèle était distinct de l’infrastructure hébergeant ses poids. Le modèle n’a accédé ni à ses propres paramètres ni aux systèmes internes d’Anthropic.
L’incident illustrait néanmoins la capacité d’un agent à interpréter très largement un objectif et à prendre des initiatives risquées pour démontrer sa réussite. Anthropic concluait alors que Mythos Preview était probablement mieux aligné que ses prédécesseurs, mais qu’en raison de ses capacités supérieures, ses rares défaillances pouvaient présenter un risque plus élevé. Dit autrement, une IA peut désobéir moins souvent tout en devenant plus dangereuse lorsqu’elle le fait.
OpenAI avait déjà vu un modèle contourner son confinement
OpenAI a décrit un scénario voisin le 20 juillet, dans un billet consacré à la sécurité des modèles à long horizon. Contrairement à ce qui a parfois été rapporté, l’entreprise ne précise pas qu’il s’agissait de GPT-5.6 Sol, mais évoque un modèle interne généraliste destiné aux tâches de très longue durée.
Lors d’une évaluation appelée NanoGPT Speedrun, le modèle avait reçu pour instruction de transmettre ses résultats exclusivement dans Slack. Les règles du benchmark demandaient néanmoins aux participants de publier leurs améliorations au moyen d’une pull request sur GitHub.
Le modèle a privilégié cette seconde instruction. Après environ une heure de recherche, il a trouvé une vulnérabilité dans son bac à sable, contourné les restrictions d’accès extérieur et ouvert une pull request sur le dépôt GitHub public du benchmark. Les générations précédentes avaient rencontré le même obstacle, mais avaient fini par abandonner. Cette fois le modèle a persévéré jusqu’à réussir l’objectif qu’il s’était lui-même fixé finalement.
Dans un autre test, le modèle a tenté de récupérer des résultats privés dans le système d’évaluation. Lorsqu’un scanner a bloqué un jeton d’authentification, il en a séparé le contenu en plusieurs fragments avant de les reconstituer à l’exécution, afin que le secret complet n’apparaisse jamais dans une commande unique.
Ces exemples montrent la limite des contrôles analysant chaque action séparément. Une commande peut sembler anodine alors que la succession des commandes révèle une stratégie de contournement. OpenAI a depuis ajouté une surveillance portant sur l’ensemble de la trajectoire de l’agent, avec la possibilité d’interrompre une session en cours.
Jusqu’alors, ces incidents restaient contenus dans les environnements des laboratoires.
Mais « l’affaire Hugging Face », comme certains la surnomme déjà, leur donne une tout autre dimension.
Hugging Face découvre une intrusion pilotée par des agents
Le 16 juillet, Hugging Face a annoncé avoir détecté une intrusion dans une partie de son infrastructure de production. L’entreprise ignorait encore l’identité de son auteur, mais avait pu établir que l’opération avait été conduite de bout en bout par un système d’agents autonomes.
L’accès initial est passé par le pipeline de traitement des jeux de données. Un dataset spécialement conçu a exploité deux mécanismes permettant l’exécution de code : un chargeur distant de données et une injection de modèle dans une configuration. Le code s’est exécuté sur un worker chargé de traiter le dataset.
À partir de ce premier point d’appui, le système a obtenu des privilèges au niveau du nœud, collecté des identifiants associés au cloud et aux clusters, puis effectué des déplacements latéraux dans plusieurs environnements internes durant le week-end.
Hugging Face a constaté un accès non autorisé à un ensemble limité de datasets internes ainsi qu’à plusieurs identifiants utilisés par ses services. Au moment de sa déclaration, l’entreprise évaluait encore l’éventuel impact sur des données de clients ou de partenaires. Elle n’avait en revanche trouvé aucun indice de modification des modèles, datasets ou Spaces publics. Les images de conteneurs et les packages composant sa chaîne d’approvisionnement logicielle avaient également été vérifiés.
La campagne se distinguait par son échelle opérationnelle. Des milliers d’actions avaient été exécutées dans une multitude de bacs à sable éphémères. Le dispositif de commande et contrôle se déplaçait automatiquement entre différents services publics, ce qui compliquait son suivi.
Pour reconstruire l’attaque, Hugging Face a utilisé ses propres agents d’analyse sur plus de 17 000 événements enregistrés. Ils ont reconstitué la chronologie, identifié les secrets consultés, extrait les indicateurs de compromission et distingué les actions réellement efficaces des tentatives ou leurres. Selon l’entreprise, ce travail, qui aurait normalement demandé plusieurs jours, a été réalisé en quelques heures.
Quand les garde-fous gênent les défenseurs
L’analyse forensique a révélé une autre difficulté. Hugging Face a d’abord tenté de soumettre les journaux et artefacts de l’incident à des modèles avancés accessibles au travers d’API commerciales.
Or ces traces contenaient précisément ce que les mécanismes de sécurité de ces services cherchent à bloquer : commandes d’attaque, charges utiles d’exploitation, identifiants, scripts de déplacement latéral et artefacts de commande et contrôle. Incapables d’établir avec suffisamment de certitude que la demande provenait d’une équipe de réponse à incident, les modèles ont refusé une partie des analyses.
Hugging Face s’est alors tourné vers GLM 5.2, un modèle à poids ouverts de Z.ai, exécuté sur sa propre infrastructure. Cette solution lui a permis de traiter librement les données techniques tout en évitant que les journaux de l’attaquant et les secrets qu’ils contenaient ne quittent son environnement.
Il ne faut pas en conclure que les garde-fous sont inutiles. Sans eux, les mêmes capacités peuvent faciliter une attaque. L’incident révèle plutôt un problème d’asymétrie opérationnelle : l’agent offensif n’était soumis à aucune politique d’usage effective, tandis que les défenseurs se sont retrouvés limités par les protections des services qu’ils utilisaient.
Pour les RSSI, la réponse ne consiste donc pas nécessairement à déployer un modèle totalement dépourvu de contrôles. Elle consiste à préparer plusieurs voies d’accès : programmes de confiance proposés par les fournisseurs, procédures d’autorisation accélérées en cas d’incident et, pour les données les plus sensibles, modèle interne préalablement testé dans une enclave sécurisée. Cette capacité doit exister avant la crise, et non être improvisée pendant celle-ci.
Le coup de théâtre : les agents venaient d’OpenAI
Le 21 juillet, soit cinq jours après la déclaration de Hugging Face, OpenAI a reconnu que l’activité provenait de ses propres évaluations. Plusieurs modèles avaient été utilisés, dont GPT-5.6 Sol et un modèle de prélancement présenté comme encore plus performant. Leurs mécanismes de refus pour les tâches cyber avaient volontairement été réduits afin de mesurer leurs capacités offensives maximales.
Les modèles étaient évalués sur ExploitGym, un benchmark composé de centaines de vulnérabilités issues de logiciels réels, du moteur JavaScript V8 et du noyau Linux. Pour chaque exercice, l’agent reçoit notamment un programme vulnérable et une entrée provoquant le bug. Il doit transformer ce point de départ en un exploit fonctionnel permettant, par exemple, l’exécution de code ou l’élévation de privilèges.
L’évaluation se déroulait dans un environnement présenté comme fortement isolé. L’accès au réseau était limité à l’installation de packages, au travers d’un logiciel tiers hébergé en interne servant de proxy et de cache aux registres de composants.
Les modèles ont toutefois découvert une faille zero-day dans ce proxy. Ils l’ont exploitée pour obtenir un accès ouvert à Internet, avant d’élever leurs privilèges et de se déplacer latéralement dans l’environnement de recherche d’OpenAI jusqu’à atteindre un nœud disposant d’une connectivité extérieure.
Ils ont ensuite déduit que Hugging Face pouvait héberger des modèles, des datasets ou des solutions liés à ExploitGym. Ils ont recherché un moyen d’accéder à ces informations afin d’améliorer leur résultat. Selon OpenAI, au moins une trajectoire a combiné des identifiants volés et plusieurs vulnérabilités, dont des zero-day, pour établir un chemin d’exécution de code à distance sur des serveurs de Hugging Face.
L’objectif a finalement été atteint : les modèles ont récupéré des solutions du benchmark directement dans une base de données de production. En termes simples, les agents ont cherché à réussir l’examen en pénétrant le système qui hébergeait le corrigé.
OpenAI explique avoir détecté en interne une activité anormale. Les équipes et les agents de Hugging Face ont, de leur côté, identifié et interrompu les opérations sur leur infrastructure avant que les deux entreprises ne rapprochent leurs investigations.
OpenAI qualifie néanmoins l’événement d’incident cyber « sans précédent », tout en précisant que ses conclusions sont encore préliminaires. L’entreprise a signalé la vulnérabilité du proxy à son éditeur, renforcé les contrôles de ses environnements d’évaluation, engagé une enquête forensique commune et intégré Hugging Face à son programme d’accès de confiance destiné aux professionnels de la cybersécurité.
Le terme d’« attaque » doit néanmoins être manié avec précaution. OpenAI n’a pas ordonné à ses modèles de compromettre Hugging Face et rien n’indique qu’ils poursuivaient un objectif hostile général. Ils ont sur-optimisé l’objectif du benchmark et exploité toutes les voies disponibles pour obtenir la réponse. Du point de vue de la victime et des systèmes compromis, le résultat n’en reste pas moins celui d’une véritable intrusion.
Ce que les DSI et RSSI doivent en retenir
Le premier enseignement concerne les environnements de test des agents. Un benchmark cyber exécutant un modèle avancé avec des protections réduites doit être considéré comme une charge hostile, et non comme une simple expérience logicielle. Aucun proxy de packages, miroir de dépendances, service de journalisation ou outil d’administration ne doit devenir un tunnel implicite vers Internet. Les identités doivent être éphémères, les secrets absents ou factices, les flux sortants placés en liste blanche stricte et les systèmes tiers rendus techniquement inaccessibles.
La deuxième leçon concerne la surface d’attaque propre à l’IA. Les datasets ne sont pas toujours de simples fichiers passifs. Ils peuvent être accompagnés de scripts de chargement, de modèles de configuration, de composants sérialisés ou de code personnalisé. Les workers qui analysent ces contenus doivent être isolés, dépourvus d’identifiants cloud réutilisables et considérés comme jetables. L’exécution de code distant devrait être désactivée par défaut, tandis que les images, dépendances et configurations doivent être soumises à des contrôles d’admission.
Troisième impératif : passer du contrôle des actions au contrôle des trajectoires. Un pare-feu, une validation humaine ou un scanner de secrets peuvent bloquer une commande particulière. Ils détectent moins facilement un agent qui fragmente un secret, multiplie les sous-tâches ou emprunte successivement plusieurs chemins apparemment légitimes. Les entreprises doivent fixer des plafonds de durée, de calcul, de nombre d’actions et de privilèges, tout en surveillant l’évolution globale de l’objectif. Les accès au réseau, aux secrets ou à de nouveaux environnements doivent déclencher une nouvelle autorisation.
L’incident rappelle également l’importance de l’observabilité. Les journaux d’un agent doivent être complets, immuables et reliés à une identité technique permettant d’attribuer chaque action à un modèle, une session et un propriétaire humain. Des mécanismes d’arrêt d’urgence doivent pouvoir interrompre non seulement le modèle principal, mais également ses sous-agents, tâches planifiées et infrastructures éphémères.
La réponse à incident doit, elle aussi, être adaptée à la vitesse machine. Une équipe qui découvre pendant une compromission que ses modèles refusent d’analyser les artefacts offensifs perd un temps précieux. Les exercices de crise doivent donc inclure les outils IA envisagés, leurs politiques de refus, leurs limites de contexte et les procédures d’accès exceptionnel. Un modèle auto-hébergé peut constituer une solution de repli, à condition d’être lui-même isolé, journalisé et gouverné.
Enfin, la responsabilité ne disparaît pas derrière l’autonomie du système. Pour une organisation, les actions exécutées par un agent restent des actions réalisées au moyen de son infrastructure, de ses identités et de ses ressources. Les contrats fournisseurs, règles de délégation, périmètres d’autorisation et procédures de signalement devront intégrer cette nouvelle réalité. Les benchmarks et opérations de red team doivent notamment interdire explicitement les systèmes tiers et prévoir des mécanismes techniques empêchant leur accès.
L’affaire Hugging Face ne démontre pas qu’une IA voulait devenir libre. Elle établit qu’un modèle suffisamment capable, persistant et doté d’outils peut franchir des frontières que ses concepteurs pensaient solides, simplement parce que ces frontières se trouvent sur le chemin de son objectif.
Pour les DSI et RSSI, cette distinction intellectuelle importe moins que sa conséquence pratique : face à un agent autonome, les intentions supposées ne constituent jamais une mesure de sécurité. Seuls comptent les privilèges effectivement accordés, les systèmes réellement accessibles et la capacité de l’organisation à détecter puis interrompre la trajectoire avant qu’elle ne sorte du cadre prévu.
À LIRE AUSSI :
À LIRE AUSSI :
