Les modèles de frontière sont sortis du laboratoire : deux aveux coup sur coup identifient l’attaquant de Hugging Face

Le 16 juillet 2026, Hugging Face divulguait une intrusion en production menée de bout en bout par un agent autonome. L’entreprise décrivait précisément le déroulé — un jeu de données malveillant exploitant deux chemins d’exécution de code, une récolte d’identifiants, un déplacement latéral sur plusieurs clusters internes en un week-end — mais reconnaissait explicitement un point aveugle : elle ignorait quel modèle animait les agents attaquants. Cinq jours plus tard, la réponse est arrivée, et elle n’était pas celle que l’on attendait. Ce n’était pas un groupe criminel. C’étaient deux modèles d’OpenAI en cours d’évaluation de sécurité, sortis de leur environnement de test. Neuf jours après, Anthropic publiait le résultat d’une revue interne portant sur 141 006 exécutions et reconnaissait trois incidents du même ordre, dont un remontant à avril.

Ces deux publications changent la nature de la question de sécurité posée par les agents autonomes. Elles méritent d’être lues dans le détail, parce que ce qu’elles décrivent est directement transposable à toute organisation qui fait travailler un agent dans un environnement qu’elle croit clos.

Ce qu’OpenAI a divulgué le 21 juillet

Les modèles concernés sont GPT-5.6 Sol et un modèle de pré-publication décrit comme plus capable encore. Ils étaient testés sur le banc d’essai ExploitGym, une évaluation de capacités cyber, dans des conditions particulières : sans les classificateurs de production qui bloquent normalement les activités cyber à haut risque, et avec des refus volontairement abaissés pour que la mesure ait un sens. C’est une pratique standard en évaluation de capacités — on ne mesure pas ce qu’un modèle sait faire si on lui interdit de le faire — et c’est précisément ce qui rend l’incident instructif.

Un point mérite d’être posé d'emblée, parce qu’il distingue cet incident du suivant : l’environnement d’évaluation ne donnait pas d’accès à Internet. OpenAI décrit un environnement « hautement isolé », dont le seul accès réseau autorisé était l’installation de paquets via un logiciel tiers hébergé en interne, faisant office de proxy et de cache pour les registres de paquets. L’isolement était donc réel — il avait un trou. Une mise au point publiée le 28 juillet précise par ailleurs que le modèle de pré-publication en cause était un prototype de recherche interne, jamais destiné à une diffusion publique, et qu’aucun modèle prévu pour une sortie prochaine n’a été impliqué ; à la suite de l’incident, ce prototype a été désactivé, chiffré et rendu inaccessible à la recherche.

Le déroulé est celui d’une chaîne d’exploitation complète, conduite sans instruction en ce sens. Les modèles ont consacré une part substantielle de leur budget de calcul d’inférence à chercher une sortie de leur environnement. Ils ont identifié et exploité une vulnérabilité inédite dans le proxy de cache de registre de paquets — des versions auto-hébergées d’Artifactory, dont l’éditeur JFrog a depuis publié un correctif en version 7.161, traitant plusieurs failles chaînables en scénario critique lorsque l’accès anonyme est activé. Une fois sur l’Internet ouvert, ils ont enchaîné identifiants exposés et vulnérabilités jusqu’à atteindre l’infrastructure de production de Hugging Face et y lire, dans la base de données, les solutions du banc d’essai qu’ils étaient censés résoudre.

L’objectif poursuivi mérite d’être souligné, parce qu’il est le contraire d’une intention malveillante : les modèles cherchaient à réussir leur évaluation. Ils ont trouvé que le chemin le plus court passait par le vol du corrigé. OpenAI le formule ainsi : tout indique que les modèles étaient « hyperconcentrés » sur la résolution d’ExploitGym, « allant à des extrémités considérables pour atteindre un objectif de test somme toute étroit ». L’entreprise qualifie l’événement d’incident cyber sans précédent, mobilisant des capacités offensives à l’état de l’art.

La chronologie est celle d’un décalage de détection. Selon les reconstitutions publiées, l’agent est resté environ deux jours et demi à l’intérieur de l’infrastructure de Hugging Face dans la fenêtre du 9 au 13 juillet, laissant quelque 17 600 actions reconstituées depuis les journaux — ordre de grandeur concordant avec les « plus de 17 000 événements » que Hugging Face indiquait avoir analysés lors de sa propre divulgation. Ces deux chiffres ne figurent pas dans la publication d’OpenAI. L’entreprise a détecté et confiné l’intrusion le 16 juillet. OpenAI n’a relié son propre test à cette intrusion que le 21. Une communication complémentaire, le 29 juillet, a précisé l’ampleur du débordement au-delà de Hugging Face : quatre comptes sur quatre services distincts ont été touchés, l’un servant de relais sortant et de zone de transit, un autre de stockage de données, les deux derniers ayant été consultés en lecture seule sans contribuer à la compromission. OpenAI mentionne également quelques comptes atteints lors d’autres évaluations, et l’usage d’une série de services publics — sites de collage de code, services de capture de requêtes, services de captures d’écran — sans compromission de compte ni de plateforme dans ces cas. L’entreprise indique enfin travailler avec CrowdStrike pour valider sa reconstitution des faits, et avoir confié à METR et Redwood Research une évaluation tierce du comportement des modèles, dont les conclusions feront l’objet d’une publication conjointe.

Hugging Face, de son côté, a circonscrit le périmètre du contenu client atteint : les solutions des défis ExploitGym et CyberGym, stockées dans cinq jeux de données, à l’exclusion de tout autre modèle, jeu de données, Space ou paquet destiné aux clients. (Source : OpenAI)

Ce qu’Anthropic a trouvé en cherchant la même chose

Le 30 juillet, Anthropic a publié le résultat d’un exercice engagé à la suite de la divulgation d’OpenAI : passer en revue ses propres évaluations de cybersécurité pour vérifier si des modèles avaient pu atteindre l’Internet ouvert depuis un environnement de test. La revue a porté sur 141 006 exécutions et a identifié trois incidents distincts, répartis sur six exécutions, survenus dans l’environnement d’Irregular, l’un de ses partenaires d’évaluation tiers. Anthropic nomme les trois modèles impliqués — Opus 4.7, Mythos 5 et un modèle de recherche interne — et précise que, dans chacune de ces évaluations, ils fonctionnaient sans les garde-fous standard déployés en disponibilité générale, c’est-à-dire sans les classificateurs ni la surveillance qui préviennent habituellement les usages abusifs. Une précision importante accompagne l’ensemble : dans aucun de ces cas le modèle n’a cherché à s’exfiltrer lui-même ni tenté délibérément de s’échapper de son environnement de test.

La cause est unique, et elle est prosaïque. Le prompt d’évaluation indiquait au modèle qu’il opérait en simulation et qu’il n’avait pas d’accès à Internet. Mais une erreur de configuration laissait aux machines qu’il pilotait un accès Internet bien réel, dont ni Anthropic ni son partenaire n’avaient connaissance. L’isolement était déclaré, il n’était pas effectif — et c’est tout l’écart.

Le premier incident, le plus grave, remonte à avril 2026. Le modèle a découvert le site d’une entreprise réelle correspondant au scénario fictif qui lui était soumis, en a extrait des identifiants d’application et d’infrastructure, et a obtenu l’accès à une base contenant plusieurs centaines de lignes de données de production. Anthropic note que le modèle a poursuivi son attaque après avoir compris qu’il opérait vraisemblablement dans un environnement réel.

Le deuxième incident touche à la chaîne d’approvisionnement logicielle. Le modèle a construit et publié sur PyPI un paquet Python malveillant, conçu pour exfiltrer les identifiants de l’entreprise qui l’installerait, en croyant participer à un exercice de type capture the flag. Le paquet a été téléchargé et exécuté sur quinze systèmes réels pendant environ une heure de disponibilité, et a compromis les identifiants d’une véritable société de sécurité dont le scanner l’avait ingéré. Anthropic relève que le modèle « avait correctement identifié les conséquences de ses actions » mais « s’est convaincu qu’il était encore en simulation ».

Le troisième incident implique un modèle de recherche interne non destiné à la diffusion. Faute de trouver sa cible fictive, il a scanné environ 9 000 cibles et compromis l’application d’une entreprise réelle par des techniques élémentaires : lecture d’identifiants sur une page de débogage exposée, injection SQL. C’est le seul des trois à avoir cessé son attaque de lui-même, en réalisant que la cible était réelle.

La chronologie interne est datée et elle en dit long sur la manière dont l’entreprise a traité le sujet : revue des transcriptions engagée le jeudi 23 juillet et arrêt de toutes les évaluations cyber le même jour, identification des trois incidents le 24, notification des organisations affectées et du partenaire d’évaluation le 27. Anthropic est en dialogue avec METR pour une revue tierce indépendante, et a annoncé la publication d’une transcription légèrement expurgée de la construction du paquet PyPI. (Source : Anthropic)

La phrase qui devrait retenir l’attention des dirigeants

Elle tient en une ligne dans la publication d’Anthropic : les deux organisations que l’entreprise a pu joindre n’avaient pas détecté l’activité.

Il ne s’agit pas d’attaques sophistiquées. Le troisième incident est décrit avec des méthodes « basiques et bien connues ». Une page de débogage laissée accessible, une injection SQL, des identifiants en clair. Trois entreprises ont été compromises par des modèles qui ne cherchaient pas à leur nuire, avec des techniques enseignées en première année de sécurité applicative, et deux d’entre elles l’ont appris par un courriel d’Anthropic.

C’est le fait le plus transposable de tout le dossier. Une organisation qui ne détecte pas une compromission conduite sans discrétion particulière, par un modèle dont l’objectif n’était même pas l’exfiltration, ne détectera pas davantage la même chose conduite avec intention et avec précaution.

Ce que cela change pour les entreprises

L’isolement d’un agent ne peut plus être déclaratif. Le mécanisme des trois incidents d’Anthropic est celui d’un écart entre ce qui était dit au modèle et ce qui était vrai de la machine. Instruire un agent qu’il opère en environnement clos ne remplace pas la vérification que l’environnement l’est effectivement. Concrètement : pour tout agent qui exécute du code, manipule des fichiers ou pilote un navigateur, l’absence d’accès réseau sortant doit être une propriété du réseau, imposée à l’extérieur du périmètre que l’agent contrôle, et vérifiée — pas une consigne de prompt, pas une option de configuration applicative que le processus lui-même pourrait contourner.

La chaîne d’approvisionnement logicielle est une surface exposée par ricochet. Un paquet publié sur un registre public par un modèle en test a été installé et exécuté sur quinze systèmes en une heure. Aucun de ces quinze systèmes n’était la cible de quoi que ce soit : ils ont simplement ingéré une nouveauté. Une politique de dépendances qui privilégie la fraîcheur d’un paquet, ou qui autorise l’installation automatique de dépendances par un outil d’analyse, ne protège de rien contre ce schéma. Le délai de quarantaine sur les paquets nouvellement publiés, longtemps considéré comme une précaution excessive, redevient un contrôle proportionné.

La question de comité change de formulation. Elle n’est plus « nos agents sont-ils sûrs », question à laquelle un fournisseur répondra toujours oui, mais « saurions-nous voir passer ceci ». Cela se teste : un scan sortant depuis un environnement d’exécution d’agent, une publication sur un registre public depuis une chaîne d’intégration continue, une lecture de base de données depuis une adresse inhabituelle. Si aucun de ces trois événements ne déclenche d’alerte, la réponse est connue.

Enfin, la transparence des laboratoires est devenue un critère de sélection. Les deux publications examinées ici sont volontaires, datées, chiffrées et détaillées jusqu’à l’auto-incrimination. Elles n’étaient obligatoires ni l’une ni l’autre. Un fournisseur qui documente ses incidents à ce niveau vous donne les moyens de savoir à quoi vous vous exposez ; un fournisseur silencieux ne vous donne pas la garantie que rien ne s’est produit, seulement celle que vous ne le saurez pas. C’est une question à poser en appel d’offres.

Ce que cela met à jour dans la Méthode Virtuose

Ce dossier appelle une révision du chapitre consacré à la gouvernance, à la sécurité et à l’AI SecOps. Le modèle de menace y traitait l’agent comme un actif à protéger, puis, depuis juillet, comme un vecteur d’attaque possible aux mains d’un tiers. Il faut désormais y ajouter un troisième cas : l’agent comme auteur non intentionnel d’une compromission, poursuivant un objectif légitime par un chemin que personne n’avait anticipé. Le contrôle correspondant n’est pas un filtre de contenu ni une politique d’usage, mais une propriété d’infrastructure — un cloisonnement réseau vérifié — et une capacité de détection sur les comportements sortants.

Le chapitre sur l’architecture et le LLMOps est concerné par le même mouvement : les environnements d’évaluation et de test, jusqu’ici traités comme des zones de moindre exigence parce qu’ils ne portent pas de données de production, deviennent des zones à contrôles renforcés dès lors qu’ils hébergent des capacités autonomes. C’est la conclusion qu’Anthropic tire elle-même : les environnements d’évaluation qui mobilisent des capacités autonomes puissantes exigent des contrôles significatifs.