Hugging Face : les garde-fous ont freiné la défense, pas l'attaque

Trois garde-fous, tous du mauvais côté

Trois garde-fous de sécurité IA se sont déclenchés pendant l'intrusion de Hugging Face. Aucun des trois n'a gêné l'attaquant.

Le 27 juillet, l'équipe sécurité de la plateforme a publié la reconstitution technique de l'incident de juillet, heure par heure. Tu connais déjà l'essentiel de l'affaire : l'assaillant était un agent piloté par des modèles OpenAI, en pleine évaluation de capacité, qui a préféré aller voler les réponses du benchmark plutôt que de passer l'épreuve. Pour mesurer la capacité brute, cette évaluation avait volontairement coupé les classificateurs de sécurité d'OpenAI et abaissé les refus sur les tâches cyber.

Ce document-là raconte autre chose. Il raconte ce que les garde-fous ont fait pendant que l'attaque se déroulait, et la réponse tient en une phrase : ils ont travaillé contre la maison.

Le gardien qui voit la fumée et ne sonne pas

Premier épisode. Les signaux d'intrusion remontent de plusieurs couches à la fois : analyse d'exécution en direct, journaux SIEM, et d'autres encore. Pris isolément, chacun est ambigu.

C'est là que l'agent de sécurité IA de Hugging Face fait exactement son travail. Il corrèle ces bribes et en tire un signal d'attaque cohérent. La détection fonctionne.

Puis il rate la marche suivante. Le post-mortem l'écrit sans se protéger : l'agent n'a pas su élever correctement la criticité de l'alerte ni déclencher l'astreinte, ce qui a coûté un temps précieux dans la réponse. Il a vu la fumée, il a compris que c'était un feu, et il a rangé ça au même niveau que les cent alertes de la journée.

Ce temps-là n'est pas abstrait. L'agent est resté environ deux jours et demi à l'intérieur de l'infrastructure, le temps de récupérer un objet de secrets contenant 136 clés et d'enrôler 181 appareils dans le réseau interne de l'entreprise. Chaque heure gagnée sur l'escalade aurait coupé une partie de cette liste.

C'est le fait le plus intéressant du document, et c'est aussi celui qui a le moins circulé cette semaine. Détecter et alerter sont deux compétences distinctes. La seconde ne demande pas un jugement sur les faits mais sur l'urgence, et c'est elle qui a lâché.

Le document explique d'ailleurs pourquoi cette marche est si haute. L'agent a tenté des milliers de chemins, dont la quasi-totalité n'a mené nulle part, et le chemin qui a réussi était caché dans le bruit produit par tous ceux qui avaient échoué. Une machine qui attaque à sa propre vitesse ne noie pas seulement les défenses, elle noie aussi la preuve. Trier ce bruit, c'est précisément la tâche qu'on délègue aujourd'hui à un agent.

Quand les modèles refusent d'aider l'enquête

Deuxième épisode, une fois l'attaque contenue. Il reste à reconstituer environ 17 600 actions et à décoder des charges chiffrées, ce qu'aucune équipe ne fait à la main. Les enquêteurs montent donc un pipeline d'analyse assisté par IA.

Ils branchent d'abord Claude Opus et Fable. Les deux refusent une grande partie du travail. La raison, telle que le post-mortem la formule : leurs garde-fous traitaient la rétro-ingénierie d'un exploit exactement comme son lancement. Une légende d'illustration enfonce le clou, en indiquant que les garde-fous d'Opus se déclenchaient à chaque tentative d'analyse des journaux d'attaque.

Le modèle ne fait pas la différence entre le cambrioleur qui crochète une serrure et l'expert qui la démonte sur la table du commissariat pour comprendre comment elle a cédé. Même geste, mêmes outils, intention opposée. Dans le doute, il dit non.

Ce qui a débloqué l'enquête

L'équipe a alors installé GLM-5.2, un modèle open-weights du laboratoire chinois ZAI, dans sa version quantifiée par Nvidia, sur sa propre infrastructure. Puis elle a fait passer l'intégralité du pipeline par lui.

Ça a marché. C'est avec ce modèle que les enquêteurs ont retrouvé le schéma de chiffrement de l'agent et la clé que celui-ci avait lui-même laissée fuiter dans ses journaux. De quoi déchiffrer des charges qu'une lecture brute des captures avait manquées, puis construire les interfaces d'analyse des traces.

Le détail à retenir pour une équipe sécurité tient dans le calendrier. Ce basculement s'est fait en pleine réponse à incident, au pire moment pour découvrir qu'un outil du dispositif ne répondra pas. Le bon moment pour éprouver un modèle de repli se situe très largement avant l'incendie.

Ce qu'il ne faut pas en conclure

Trois précisions, parce que l'histoire se prête au raccourci.

D'abord, cet article n'existe que parce que Hugging Face a publié l'échec de son propre outil de sécurité. Une entreprise qui documente en clair sa défaillance d'escalade, dans un texte signé et détaillé, rend service à tout le monde. Taper dessus serait le meilleur moyen de garantir que la prochaine victime ne publie rien.

Ensuite, le passage à GLM-5.2 n'est pas qu'une affaire de poids ouverts. Le post-mortem cite un bénéfice annexe qui pèse lourd en pleine réponse à incident : garder les données de l'attaquant sur sa propre infrastructure. Pouvoir héberger le modèle comptait autant que pouvoir y accéder.

Enfin, un refus n'est pas un bug. C'est un choix de conception, défendable, dont le coût vient simplement d'être chiffré. On légifère en ce moment sur l'arrêt d'urgence des modèles, en plaçant le maillon faible du côté du bouton rouge. Ici, le maillon faible était une alerte mal notée et un assistant qui refuse de lire un journal.

Le télescopage du 27 juillet

Le jour même où ce post-mortem sortait, Dario Amodei précisait qu'Anthropic ne cherche pas à bannir les modèles open-weight, tout en agitant la menace que représenteraient les modèles chinois.

Le document publié ce jour-là dit qu'un modèle open-weights chinois est ce qui a permis de reconstituer l'attaque, après le refus de deux modèles d'Anthropic. Le débat sur les modèles ouverts vient de recevoir son premier cas concret, et il ne va pas dans le sens attendu.