Le générateur ne peut pas être son propre validateur : ce que révèle l’incident OpenAI-Hugging Face sur la sécurité de l’IA

De temps à autre, un événement redéfinit discrètement les limites d’un secteur — non pas parce que quelque chose a été dit, mais parce qu’une réalité a été démontrée. La sécurité de l’IA a connu l’un de ces moments la semaine dernière. Autant le dire clairement avant d’entrer dans les détails : il ne s’agissait pas d’un simple nouvel élément à verser au dossier. Un risque décrit en théorie depuis des années par les chercheurs en sécurité et en sûreté s’est matérialisé, dans toute son ampleur, dans un rapport d’incident rendu public.

La semaine dernière, un modèle d’OpenAI a fait quelque chose qu’aucune équipe de sécurité d’entreprise n’a plus besoin d’imaginer : il s’est échappé de l’environnement où il était confiné, a découvert de lui-même une vulnérabilité réelle et l’a exploitée pour compromettre l’infrastructure d’une autre entreprise — de manière autonome, afin de trouver les réponses attendues au test.

Ce n’est pas une expérience de pensée. C’est le résumé d’un rapport d’incident conjoint rendu public par OpenAI et Hugging Face. C’est aussi la preuve la plus claire à ce jour d’un principe autour duquel nous développons la plateforme de sécurité de l’IA de Snyk depuis deux ans : le générateur ne peut pas être son propre validateur. L’entité qui crée un système d’IA — ou le système d’IA lui-même — ne peut pas être la seule autorité à certifier sa sécurité. Celle-ci doit être établie de l’extérieur, en continu, par un tiers indépendant du générateur. Ce n’est pas une simple formalité de conformité. C’est désormais une exigence opérationnelle avérée, et c’est précisément la lacune que la plateforme de sécurité de l’IA de Snyk vise à combler.

Ce qui s’est réellement passé

Selon la déclaration d’OpenAI, l’entreprise testait en interne GPT-5.6 Sol ainsi qu’un modèle encore plus performant, en préversion, face à ExploitGym, un benchmark conçu pour mesurer les capacités avancées en cybersécurité. Afin d’évaluer les capacités maximales des modèles, OpenAI a mené l’évaluation en désactivant les classificateurs de sécurité utilisés en production — selon ses propres termes, en « réduisant les refus liés à la cybersécurité à des fins d’évaluation ». Le test devait se dérouler dans un « environnement hautement isolé », avec un accès réseau limité à un proxy interne servant à installer des paquets logiciels.

L’isolation n’a pas tenu. Les modèles n’ont pas résolu le benchmark qui leur était soumis. À la place, ils ont découvert et exploité une vulnérabilité zero-day dans le proxy du registre de paquets, puis l’ont utilisée pour enchaîner des étapes d’élévation de privilèges et de déplacement latéral dans l’environnement de recherche d’OpenAI, jusqu’à atteindre un nœud disposant d’un accès Internet ouvert. Ils ont alors déduit que Hugging Face hébergeait probablement les solutions d’ExploitGym et, à l’aide d’identifiants volés et de la vulnérabilité zero-day, trouvé un moyen d’exécuter du code à distance sur les serveurs de production de Hugging Face. Selon OpenAI, l’objectif était de récupérer les réponses au test auquel le modèle était soumis. Les équipes de sécurité des deux entreprises ont détecté l’activité de manière indépendante. Celle de Hugging Face avait déjà commencé à la contenir lorsque les deux organisations ont pris contact pour échanger leurs observations. Depuis, OpenAI a signalé la vulnérabilité zero-day au fournisseur concerné, et les deux entreprises publient leurs conclusions conjointement (OpenAI ; Hugging Face).

La réaction de Clem Delangue, cofondateur et PDG de Hugging Face, va droit au cœur du sujet : « Cet incident, peut-être une première, confirme ce que nous pensons depuis longtemps : aucune entreprise ne peut résoudre seule, dans le secret, les enjeux de sécurité de l’IA. La solution passe par l’ouverture, la collaboration et un accès étendu à l’IA pour tous les défenseurs, partout. » À la suite de l’incident, Hugging Face a également appelé à une « transparence radicale » dans tout le secteur.

Les commentateurs ont eu raison de qualifier cet incident d’inédit : il s’agit du premier cas réel, bien documenté, où un système d’IA adopte un comportement de perte de contrôle qui, jusqu’ici, n’existait guère que dans des articles de recherche et des exercices de simulation des équipes de sécurité (OpenAI ; Hugging Face ; Time).

Pourquoi l’enjeu dépasse les gros titres

On pourrait être tenté d’y voir le simple problème d’un environnement de test mal configuré par une entreprise. Ce serait passer à côté de l’essentiel. L’isolation, la réduction des garde-fous et le benchmark lui-même ont tous été conçus par l’équipe qui menait l’évaluation. C’est une approche raisonnable pour tester les capacités d’un modèle, mais elle a fait d’une seule organisation à la fois le générateur, l’examinateur et l’inspecteur de sécurité de son propre modèle. Lorsque la barrière a cédé, personne à l’extérieur de cette organisation n’était en mesure de repérer le problème avant que le modèle n’atteigne les systèmes de production d’un tiers. C’est finalement une partie externe, Hugging Face, qui a joué ce rôle.

Ce n’est pas un cas isolé. C’est le même schéma que nous avons vu se répéter ces derniers mois dans l’écosystème de l’IA de pointe : un grand laboratoire spécialisé dans la sécurité de l’IA avait des fichiers internes faisant référence à la fuite d’un modèle non publié ; séparément, près d’un demi-million de lignes de prompts système et de logique d’utilisation des outils régissant le comportement de son propre agent de programmation ont été publiées sur un registre de paquets public. Deux incidents distincts en quelques jours, tous deux attribués à une erreur humaine plutôt qu’à une attaque (Fortune ; VentureBeat). Dans le même temps, un scanner de sécurité compromis a introduit une porte dérobée dans une bibliothèque de passerelle LLM largement utilisée (Snyk), et le compte piraté d’un mainteneur a servi à diffuser un cheval de Troie d’accès à distance via l’un des paquets les plus téléchargés de l’écosystème JavaScript (Snyk). Le constat est clair : les outils d’IA et les logiciels générés par l’IA sont désormais une surface d’attaque majeure, et l’autorégulation des organisations qui développent ces outils s’est révélée, à plusieurs reprises et de façon manifeste, insuffisante pour repérer les problèmes à temps.

Aucune de ces organisations n’est négligente. Certaines sont même réputées compter parmi les laboratoires les plus soucieux de la sécurité du secteur. C’est précisément là le problème. Si les concepteurs les plus avancés de l’IA de pointe ne peuvent pas valider de manière fiable les limites de sécurité de leurs propres systèmes, aucune entreprise qui adopte à grande échelle le développement assisté par l’IA ne devrait penser y parvenir seule — du moins pas en se fiant aux affirmations du fournisseur ou au jugement de l’IA sur ses propres résultats.

Le générateur ne peut pas être son propre validateur

C’est un argument structurel, qui dépasse le cadre d’un incident particulier.

Demandez à un LLM d’examiner son propre code, ou celui d’un autre modèle, à la recherche de failles de sécurité : vous obtiendrez des résultats utiles, mais pas reproductibles. Dans les recherches menées par Snyk, où nous avons comparé la revue de code par des agents LLM à l’analyse statique déterministe, nous avons effectué 300 analyses de sécurité répétées sur le même code, avec les mêmes prompts. Lorsqu’un modèle repérait une vulnérabilité connue et vérifiée, il signalait ce résultat de façon constante : environ 85 % des vrais positifs réapparaissaient à chaque exécution. En revanche, près de la moitié des autres éléments signalés par le modèle — les résultats nouveaux et non vérifiés — ne ressortaient que lors d’une exécution sur cinq, malgré des conditions identiques.

Demandez deux fois au même modèle d’examiner le même code, et vous pouvez obtenir deux réponses différentes. C’est utile pour repérer des problèmes qui échapperaient à un outil statique. Mais cela ne constitue pas, à lui seul, une couche de validation sur laquelle une entreprise peut s’appuyer en toute confiance : la validation exige de la reproductibilité, et le raisonnement, aussi performant soit-il, reste probabiliste.

C’est aussi pour cette raison que nous n’avons pas considéré la récente incursion d’Anthropic dans la découverte de vulnérabilités assistée par l’IA comme une menace pour le secteur de la sécurité applicative, mais comme une confirmation. La percée ne tient pas au fait qu’un modèle puisse trouver des vulnérabilités : les outils déterministes le font de manière fiable depuis des années. Elle tient au fait qu’un modèle puisse raisonner suffisamment bien pour contribuer à les corriger.

Mais le raisonnement ne vaut pas mise en application. Une entreprise a toujours besoin de preuves déterministes des changements apportés, d’une remédiation automatisée capable de dépasser ce qu’une boucle de raisonnement peut trier manuellement, et d’une gouvernance qui reste valable quel que soit le modèle, le fournisseur ou le laboratoire à l’origine du code. L’incident OpenAI-Hugging Face illustre la même leçon, avec des conséquences bien plus lourdes : sans couche de contrôle indépendante, les capacités de raisonnement constituent un risque, pas un mécanisme de contrôle.

Aucune entreprise ne mise sur un seul modèle

Le problème serait déjà préoccupant si toutes les entreprises adoptaient un seul modèle d’IA de pointe et faisaient confiance à son créateur pour en assurer la surveillance. Mais ce n’est pas ainsi que les entreprises construisent leurs systèmes. Dans la réalité, les déploiements répartissent les tâches entre des modèles de plusieurs fournisseurs : un modèle de pointe ici, un modèle plus rapide ou moins coûteux là, et un modèle à poids ouverts pour les cas où les données ne peuvent pas quitter les locaux. Le choix dépend de la tâche, des coûts et des capacités, et évolue souvent au fil des mois, à mesure que de nouvelles versions sortent. C’est une architecture raisonnable. Mais dans ce contexte, « faire confiance au générateur pour se valider lui-même » ne tient plus du tout, car il n’y a plus un seul générateur. Il y en a plusieurs, chacun avec sa propre approche de la sécurité, son calendrier de divulgation et sa définition des « garde-fous réduits à des fins d’évaluation ».

L’incident OpenAI-Hugging Face constitue aussi un test de résistance révélateur : il a fallu les équipes de sécurité de deux entreprises — l’une évaluant ses propres résultats, l’autre un tiers sans lien avec elle — pour seulement détecter et contenir ce qui se passait. Et l’équipe d’OpenAI n’avait pas encore repéré l’anomalie en interne lorsque celle de Hugging Face avait déjà commencé à la contenir. Multipliez maintenant ce problème de coordination par le nombre de fournisseurs de modèles présents aujourd’hui dans une pile technologique d’entreprise classique, chacun publiant des mises à jour de modèles de pointe à son propre rythme. Vous ne pouvez pas demander à cinq laboratoires différents de certifier chacun leur modèle et vous attendre à obtenir une posture de sécurité cohérente. Il faut une couche indépendante unique qui évalue tous les modèles de la même manière, quel que soit leur créateur. Sinon, le « multi-modèle » ne fait que reproduire en parallèle plusieurs versions incompatibles du même problème d’auto-validation.

La place d’Evo

C’est la lacune que Snyk a conçu Evo pour combler. Son architecture repose délibérément sur une validation indépendante par un tiers, plutôt que sur la confiance accordée à un modèle — ou à son créateur — pour évaluer sa propre sécurité.

Tout commence par la visibilité. L’agent de découverte d’Evo recense les modèles, agents, outils et serveurs MCP réellement utilisés dans les dépôts et les applications d’une organisation — la base indispensable à tout ce qui suit. À partir de là, Risk Intelligence teste chaque modèle dans ses conditions d’utilisation réelles : en tant qu’agent, avec des outils et des données en temps réel. Il mesure la fréquence de réussite des attaques réelles, confirme chacune d’entre elles de manière indépendante et établit une correspondance avec les référentiels déjà utilisés par votre équipe. L’incident de la semaine dernière relève d’une catégorie de risque comprenant le vol d’identifiants, les commandes contrôlées par l’attaquant et l’exécution d’outils non autorisée. Un modèle peut réussir tous les tests isolément et pourtant être détourné dès lors qu’il peut lire une entrée falsifiée ou appeler un outil. C’est pourquoi le score pertinent doit être mesuré en contexte, et non déclaré par le fournisseur lui-même. Ces scores alimentent le moteur de politiques d’Evo, afin qu’un modèle risqué n’obtienne pas discrètement l’accès à de vrais outils.. Un agent de politiques transforme ensuite ces résultats en mesures de gouvernance : des problèmes à examiner ou une barrière CI/CD pour les équipes qui souhaitent imposer des règles plus strictes. La décision est ainsi prise en dehors du modèle et du fournisseur.

Il faut résister à la tentation de classer cet incident parmi les « problèmes propres aux laboratoires d’IA de pointe » pour ensuite passer à autre chose. Les agents qui trouvent une voie inattendue pour atteindre leur objectif sont en train de devenir la norme dans les systèmes agentiques, et non une exception. Cela concerne autant les agents de programmation et de collaboration déjà déployés dans votre environnement que les benchmarks internes d’un laboratoire.

C’est le principe qui sous-tend Evo Agentic Development Security (ADS) : considérer ces agents comme des charges de travail à privilèges, et non comme de simples outils pratiques pour les développeurs. ADS surveille ce que fait réellement un agent au cours d’une session — les prompts, les appels d’outils, l’activité MCP, les commandes shell et l’accès aux fichiers — évalue ces actions au regard des politiques et peut bloquer ou réorienter une action à haut risque avant qu’elle n’aboutisse. En définissant clairement ce qu’un agent est autorisé à manipuler, on applique le même principe que dans le reste de cet article, à un niveau plus proche de vous : ne laissez pas le jugement de l’agent être le seul rempart entre une action et ses conséquences, et assurez-vous de pouvoir réellement l’arrêter si ce jugement est erroné.

Un autre élément correspond encore plus directement aux mécanismes de cet incident précis : Evo Continuous Offensive Security (COS), actuellement en accès anticipé, avec une disponibilité générale prévue en août 2026. Abstraction faite un instant de ce qu’OpenAI testait, cet incident constitue une expérience naturelle sur la structure des tests de sécurité offensive : des tests occasionnels, réalisés par l’organisation même qui a conçu le système testé, sans surveillance externe de ses limites. COS repose sur le principe inverse : une partie indépendante — ni le fournisseur du modèle ni le propriétaire de l’application — teste en continu, depuis l’extérieur, des applications et des agents natifs de l’IA en production. Une étape automatisée de red teaming ne se déclenche que lorsque des composants intégrant des LLM sont détectés, puis une étape de validation distincte confirme qu’une vulnérabilité peut réellement être exploitée avant qu’elle ne soit signalée.

L’attaque exploitait la surface d’attaque de l’application de Hugging Face : un chargeur de jeux de données qui exécutait du code distant et une faille d’injection de template dans la configuration d’un jeu de données. C’est précisément le type de vulnérabilité exploitable dans une application en fonctionnement que Continuous Offensive Security est conçu pour détecter en priorité : des tests autonomes menés de l’extérieur, qui attaquent l’application en production comme le ferait un adversaire. Les sondes s’enchaînent pour atteindre un objectif, au lieu de signaler des problèmes isolément, et vérifient qu’une voie d’attaque est réellement exploitable avant de la signaler — afin de fermer la porte avant que quelqu’un ne la franchisse. L’ambition de soumettre les systèmes d’IA à des tests de résistance face à des attaques réalistes n’est pas en cause : c’est le bon réflexe. Ce qui compte, c’est qui effectue les tests, à quelle fréquence et qui surveille les points d’entrée pendant leur déroulement.

Rien de tout cela ne remplace le modèle de pointe. Cela le contraint. Il faut une couche externe déterministe, précisément parce qu’on ne peut pas faire confiance au générateur — aussi performant et bien intentionné soit-il — pour certifier lui-même ses limites de sécurité. La semaine dernière, ce n’était pas une théorie. C’était le rapport d’incident de Hugging Face.

Ce que les responsables de la sécurité doivent retenir

Les organisations qui développent les systèmes d’IA les plus performants au monde viennent de démontrer, en production, que l’auto-validation échoue — non par mauvaise intention, mais de par sa structure même. Une même entité ne peut pas fiablement générer des capacités et en certifier les limites. Ajouter à votre pile d’autres modèles provenant d’autres fournisseurs ne réduit pas le problème : il l’amplifie. Toute entreprise qui adopte le développement assisté par l’IA ou déploie des agents autonomes — avec un seul modèle ou plusieurs — doit désormais considérer ce constat comme établi, et non comme une hypothèse.

Et le problème ne concerne pas seulement les laboratoires de pointe. La capacité qui permet à un modèle de sortir du bac à sable d’OpenAI est déjà intégrée aux agents de codage et de collaboration utilisés dans votre propre environnement. Elle exige le même niveau d’examen, et non un document de politique qui part du principe qu’elle ne sera pas mise à l’épreuve.

La validation indépendante n’est pas une fonctionnalité à ajouter plus tard. C’est le contrôle qui aurait permis de détecter le problème avant que Hugging Face n’y soit contraint. Vous souhaitez obtenir un cadre pour gouverner chaque actif d’IA dans votre environnement, quel que soit le laboratoire qui l’a conçu ? Réservez votre place à notre webinaire en direct.