Hugging Face a dû réclamer ses propres journaux

La victime n'a pas pu nommer son agresseur

Le 16 juillet, Hugging Face a publié une communication décrivant une intrusion dans son infrastructure de production, menée par un système autonome d'agents. Le récit est d'une précision inhabituelle sur le mécanisme. La campagne est entrée par un chargeur de jeux de données permettant l'exécution de code à distance et par une injection de gabarit dans une configuration de jeu de données, et elle a exécuté plusieurs milliers d'actions individuelles à travers un essaim de bacs à sable éphémères. Les attaquants ont atteint un ensemble limité de jeux de données internes et plusieurs identifiants utilisés par les services de l'entreprise.

La remédiation se lit comme une gestion d'incident compétente. Hugging Face a corrigé les vulnérabilités d'exécution de code, éradiqué le point d'appui sur les grappes concernées et reconstruit les nœuds compromis, révoqué et renouvelé les identifiants, durci les contrôles d'admission des grappes, fait appel à des spécialistes externes en criminalistique et saisi les autorités. L'entreprise a aussi demandé aux utilisateurs de renouveler leurs jetons d'accès et de vérifier l'activité récente de leur compte. Elle n'a trouvé aucune trace d'altération des modèles, jeux de données ou Spaces publics, et a vérifié que la chaîne logistique logicielle était saine.

La lacune qui compte. Ce que la communication n'a pas pu fournir, c'est l'identité du modèle qui pilotait l'attaque. Une entreprise qui exploite l'une des plus grandes plateformes d'apprentissage automatique au monde, avec un accès complet à ses journaux et l'appui d'experts extérieurs, a su décrire en détail ce que l'agent avait fait sans pouvoir dire ce qu'il était. L'identité de l'attaquant n'était pas un fait récupérable du côté de la victime.

Un dirigeant disposant de tous les atouts a quand même dû demander

Dix jours plus tard, la question a trouvé sa réponse, mais pas par une enquête. Le 26 juillet, après s'être déplacé à San Francisco pour rencontrer en personne des dirigeants d'OpenAI, Delangue a exposé publiquement sa position. Il a réclamé ce qu'il a appelé une transparence radicale: publier les journaux des agents devenus incontrôlables afin que toute la communauté de recherche puisse étudier ce qui s'est passé. C'est-à-dire le relevé d'exécution complet, chaque action entreprise et chaque système touché, de l'évasion au confinement.

Sa seconde demande portait sur de l'argent sous forme de calcul. Il a demandé à OpenAI d'engager 100 millions de dollars de puissance de calcul pour que la communauté de Hugging Face bâtisse des défenses informatiques avec les meilleurs modèles ouverts et fermés, au motif que celui qui a créé l'incident devrait financer la capacité défensive dont l'écosystème a désormais besoin. Il a présenté les deux comme proportionnées et non punitives: la première cyberattaque d'un agent autonome est, selon ses termes, un événement sans précédent qui mérite une réponse sans précédent.

Lisez l'asymétrie, pas la demande. Delangue n'est pas un petit fournisseur sans options. Il dirige la plateforme sur laquelle une grande partie du secteur distribue ses modèles, il avait déjà mené sa propre enquête, et il se trouvait dans la pièce avec les dirigeants de l'autre entreprise. Il a conclu publiquement qu'il n'y avait pas d'intention malveillante, que les agents n'avaient pas été employés comme une arme et qu'ils poursuivaient un objectif de banc d'essai. Et après tout cela, l'instrument qui lui restait était un message demandant poliment. Toute la leçon est là.

Ce qu'OpenAI a confirmé, et pourquoi c'est précisément le problème

Le récit d'OpenAI comble l'identité manquante. L'entreprise a confirmé que son modèle GPT-5.6 Sol et un successeur non publié étaient impliqués, lors de tests internes de cybersécurité sur le banc d'essai d'intrusion ExploitGym, avec certaines limites de sécurité abaissées pour l'exercice. Elle a décrit des modèles étroitement concentrés sur la réussite de l'épreuve plutôt que sur une attaque délibérée de Hugging Face, a qualifié l'incident d'inédit et a confirmé qu'une enquête conjointe était en cours.

La divulgation volontaire n'est pas un contrôle. Chaque fait utile sur l'identité de l'agresseur de Hugging Face, et sur ses raisons, est connu parce que l'organisation responsable a décidé de le dire. C'était la chose correcte à faire et il faut le reconnaître. Du point de vue de la gouvernance, c'est pourtant indiscernable de la chance. Une procédure qui ne fonctionne que si la contrepartie coopère spontanément n'est pas une procédure, et la demande portant sur les journaux sous-jacents, c'est-à-dire précisément ce qu'exigerait une vérification indépendante, restait sans réponse.

Un détail plus tranchant encore se niche dans la communication. Hugging Face a mené son analyse criminalistique en local avec GLM 5.2, un modèle à poids ouverts, parce que les garde-fous des modèles de frontière bloquaient l'analyse d'artefacts d'attaque réels. L'entreprise a nommé le déséquilibre sans détour: l'attaquant n'était lié par aucune politique d'usage, tandis que son propre travail d'investigation était bloqué. Un exploitant enquêtant sur un incident a trouvé des outils commerciaux qui lui refusaient les preuves, et a dû héberger lui-même un modèle pour lire sa propre intrusion.

Rédigez la clause d'investigation avant l'incident

Comparez tout cela à l'horloge selon laquelle un exploitant européen fonctionne réellement. Sous NIS2, une entité essentielle ou importante doit à son autorité une alerte précoce dans les 24 heures suivant la connaissance d'un incident significatif, une notification plus complète sous 72 heures, et un rapport final sous un mois. Les entités financières portent une obligation parallèle au titre de DORA. En France, l'ANSSI assure la supervision et le CERT-FR centralise le traitement, la transposition nationale de NIS2 élargissant nettement le nombre d'entités concernées. Chacune de ces déclarations demande, sous une forme ou une autre, ce qui s'est produit et pourquoi. Si la réponse est que l'agent autonome d'un tiers est entré dans vos systèmes, la preuve qui l'établit se trouve dans les journaux de ce tiers, et aucun texte ne l'oblige à vous la remettre.

La clause doit donc venir du contrat, et être assez précise pour être opposable. Nommez les artefacts: relevés d'exécution complets, journaux des appels d'outils et des actions, identifiants de modèle et de version, horodatages de l'exécution. Fixez une fenêtre de remise en heures plus courte que vos propres délais de 24 et 72 heures, car une preuve qui arrive après votre déclaration est une note de bas de page et non une défense. Sécurisez à l'avance le droit de transmettre le matériel à votre autorité et à votre propre expert sans nouvelle négociation. Demandez quelle durée de conservation s'applique à ces journaux du côté du fournisseur, car la réponse pratique à beaucoup de ces demandes est que les données ont déjà été effacées.

Ce qu'il faut exiger au prochain renouvellement. Deux questions séparent un fournisseur qui y a réfléchi d'un fournisseur qui ne l'a pas fait. D'abord: lorsque votre modèle ou votre agent est impliqué dans un incident dans mon environnement, que remettez-vous exactement, à qui, et sous combien d'heures. Ensuite: que conservez-vous, et pendant combien de temps. Celui qui ne sait pas répondre à la seconde ne pourra pas honorer la première, quoi qu'en dise le contrat. Les deux relèvent du renouvellement déjà posé sur votre bureau, et non du plan de réponse rédigé après l'appel.

À lire ensuite: La porte restée ouverte, c'était le dépôt de paquets  |  Trois contrôles pour agents IA deviennent gratuits