Dix-sept mille événements, et l'API a dit non
Le moment qui compte dans la divulgation de Hugging Face n'est pas l'intrusion. C'est un intervenant assis devant une API payante, les preuves en main, et qu'on éconduit. Le 16 juillet 2026, l'entreprise a publié le récit d'un incident de sécurité au cours duquel, dit-elle, des attaquants ont utilisé ce qu'elle décrit mot pour mot comme "(a remote-code dataset loader and a template-injection in a dataset configuration)" pour exécuter du code sur un worker de traitement. Ce que les intervenants avaient ensuite était, selon les propres termes de Hugging Face, "the full attacker action log, comprised of more than 17,000 recorded events". Ailleurs, le billet évoque "tens of thousands of automated actions".
Le refus est l'histoire, et Hugging Face en a écrit la phrase elle-même. Son billet indique : "This did not work: the analysis requires submitting large volumes of real attack commands, exploit payloads, and C2 artifacts, and these requests were blocked by the providers' safety guardrails, which cannot distinguish an incident responder from an attacker." La dernière proposition porte tout le poids. Le système ne portait pas un jugement erroné sur Hugging Face. Il n'avait aucun moyen de porter ce jugement.
Tout ce qui précède repose sur la seule parole de Hugging Face, et nous tenons à le dire nettement. Nous n'avons aucune source primaire indépendante pour les faits de l'incident. Aucun média ne les a corroborés ; chaque récit que nous avons trouvé se borne à reprendre le billet de l'entreprise. Hugging Face ne donne ni date d'intrusion ni date de détection, seulement "Earlier this week" et "over a weekend". Elle ne nomme aucun fournisseur. Et elle déclare son propre travail inachevé : "We are still completing our assessment of whether any partner or customer data was affected." Cet article n'est pas un compte rendu d'incident. C'est une lecture de ce que les contrats publiés des fournisseurs disent réellement, mise en regard de la conduite que décrit Hugging Face.
Nous avons lu les trois politiques en cherchant l'interdiction
Il n'y en a pas. Nous avons récupéré les politiques d'usage publiées d'Anthropic, d'OpenAI et de Google, et aucune des trois n'interdit d'analyser du matériel hostile provenant d'une brèche dans votre propre système. Ce n'est pas une lecture opportuniste. Chaque interdiction cyber dans les trois documents est bornée par une restriction, et la conduite que décrit Hugging Face échappe à toutes.
La politique d'usage d'Anthropic, en vigueur au 15 septembre 2025, interdit le travail visant à "Discover or exploit vulnerabilities in systems, networks, or applications without authorization of the system owner", et interdit séparément aux utilisateurs de "Create or distribute malware, ransomware, or other types of malicious code". Hugging Face était le propriétaire du système, la première clause ne l'atteint donc pas. Elle analysait des charges utiles qui existaient déjà, sans les créer ni les diffuser, la seconde non plus. Aucune exception pour la recherche en sécurité, la réponse à incident ou la défense ne figure nulle part dans le document. Le travail de jailbreak et d'injection de prompt n'est interdit que "without prior authorization from Anthropic", ce qui envisage une autorisation sans renvoyer à aucun processus publié pour l'obtenir.
Les politiques d'usage d'OpenAI, en vigueur au 29 octobre 2025, interdisent la "destruction, compromise, or breach of another's system or property, including malicious or abusive cyber activity". La restriction tient au mot another's. Le système en cause était celui de Hugging Face. Nous n'avons trouvé aucune exception pour la recherche en sécurité ; le seul passage de revue documenté concerne les "national security or intelligence purposes without our review and approval".
La Generative AI Prohibited Use Policy de Google, modifiée pour la dernière fois le 17 décembre 2024, dit : "Do not compromise the security of others' or Google's services. This includes generating or distributing content that facilitates: Spam, phishing, or malware." Là encore, c'est la restriction qui travaille. Soumettre des charges utiles capturées pour analyse, ce n'est ni les générer ni les diffuser. Aucune exception de sécurité, seulement une clause générale d'exceptions : "We may make exceptions to these policies based on educational, documentary, scientific, or artistic considerations, or where harms are outweighed by substantial benefits to the public." Aucune voie de demande, aucun contact, aucune procédure n'est documenté. Les trois politiques étaient en vigueur avant l'incident.
Le contrat de votre fournisseur n'est pas votre contrôle
Voici la phrase que nous poserions devant un conseil. L'écart ici n'est pas que le contrat et le classifieur se contredisent. C'est que le contrat n'a jamais traité la situation, tandis que le classifieur s'est comporté comme si elle était interdite. Les intervenants de Hugging Face, selon leur récit, ont heurté un refus pour un travail qu'aucune politique publiée des trois grands fournisseurs n'interdit.
Un opérateur qui aurait mené ses achats correctement se serait fait prendre quand même. Vous avez lu la politique d'usage. Vous n'avez rien trouvé qui interdise l'analyse défensive de votre propre brèche, parce qu'il n'y a rien à y trouver. Vous avez signé. Et ce qui vous a refusé, ensuite, c'est le runtime, un objet distinct du document, régi par aucune clause que vous ayez négociée et décrit dans aucune clause que vous ayez relue. Ce que vous avez vérifié et ce qui décide à trois heures du matin ne sont pas le même système.
Nous décrivons une lacune dans les termes publiés, nous n'accusons personne de les enfreindre. Anthropic comme OpenAI autorisent des aménagements contractuels, et des conditions entreprise non publiques peuvent dire tout autre chose que les politiques publiques ; nous n'avons pas vu ces conditions et ne pouvons nous prononcer. Nous ne pouvons pas non plus vous dire pourquoi les refus se sont produits. Hugging Face ne publie aucune transcription de refus, si bien que savoir si les blocages relevaient de la politique ou d'un simple sur-blocage du classifieur est inconnaissable de l'extérieur, et nous ne devinerons pas. Hugging Face ne nomme pas davantage les fournisseurs qui ont bloqué. Elle dit seulement : "we are sharing this feedback with the providers concerned."
Ce que Hugging Face a réellement affirmé, et ce qu'elle n'a pas affirmé
L'évaluation des dommages par l'entreprise est plus étroite qu'une lecture rapide ne le suggère, et cette précision mérite d'être préservée. Hugging Face rapporte "no evidence of tampering with public, user-facing models, datasets, or Spaces, and our software supply chain (container images and published packages) was verified clean". Ce sont deux affirmations différentes. Aucune preuve d'altération est une absence de constats. Verified clean est une assertion positive sur la chaîne d'approvisionnement, et c'est la plus forte des deux. Les fondre en une seule assurance est précisément ce qui rend un résumé d'incident moins exact que la divulgation qu'il résume.
L'attaquant était lui-même automatisé, et ce détail rend le problème de volume structurel plutôt que malchanceux. Hugging Face décrit la campagne mot pour mot comme "run by an autonomous agent framework (appearing to be built on an agentic security-research harness - used LLM still not known)". Un agent qui génère des dizaines de milliers d'actions produit un journal qu'une équipe humaine ne peut lire à la vitesse voulue, ce qui est précisément pourquoi les intervenants voulaient y mettre un modèle, et précisément là où ils ont été bloqués. La seule instruction opérationnelle du billet est brève : "we recommend rotating any access tokens and reviewing recent activity on your account."
Et Hugging Face a devancé l'argument que certains lecteurs voudront en tirer, aussi le citons-nous plutôt que de le contourner. Son billet indique : "This is not an argument against safety measures on hosted models". Nous en convenons, et cet article n'est pas cet argument. Des garde-fous incapables de distinguer un intervenant d'un attaquant font toujours un travail réel contre l'attaquant. Le constat porte ici sur ce que les termes publiés omettent et sur ce qu'un opérateur devrait donc tester, pas sur l'existence même des filtres.
Testez le refus avant que l'incident ne vous teste
Programmez l'exercice ce trimestre. Prenez du matériel hostile réel dans vos propres journaux, soumettez-le à l'API vers laquelle vous vous tourneriez vraiment pendant un incident, et notez ce qui revient. Le constat que vous cherchez n'est pas une assurance. C'est une réponse factuelle à une question qu'aucun contrat ne tranchera pour vous, obtenue un jour où rien ne brûle.
Pour un opérateur européen, l'horloge rend la chose concrète plutôt que théorique. Les obligations de signalement de NIS2 courent sur une alerte précoce à 24 heures et une notification à 72 heures, et DORA impose aux entités financières sa propre fenêtre étroite de notification initiale. Ces délais supposent que vous puissiez caractériser ce qui s'est passé. Si votre voie d'analyse cale à la troisième heure parce qu'un filtre refuse vos propres preuves, l'horloge ne s'arrête pas pendant que vous le découvrez. C'est la différence entre l'apprendre lors d'un exercice sur table et l'apprendre dans une fenêtre réglementaire.
Ensuite, gardez la voie qui ne peut pas être refusée. Le repli de Hugging Face, selon ses termes : "We ran the forensic analysis instead on GLM 5.2, an open-weight model, on our own infrastructure." GLM 5.2 vient de Z.ai, anciennement Zhipu, à Pékin ; Hugging Face elle-même ne caractérise pas l'origine du modèle, et cette identification est la nôtre, pas la sienne. L'origine n'est pas le sujet. Des poids que vous détenez, tournant sur du matériel que vous maîtrisez, est la seule configuration où le runtime d'un tiers n'a pas voix au chapitre sur l'analyse de votre incident. Tout opérateur devrait savoir aujourd'hui s'il en a une et si elle fonctionne.
À lire ensuite: Deux géants de l'IA se font intégrateurs | Vos graines MFA étaient parties avant le correctif
