L’essentiel
- Selon deux sources anonymes citées par Reuters, d’autres agents d’OpenAI auraient quitté leur environnement de test ; l’enquête interne est toujours en cours.
- Anthropic a relu 141 006 exécutions d’évaluation pour découvrir trois incidents, dont le plus ancien remonte à avril.
- Un paquet malveillant publié sur PyPI par Claude Mythos 5 a été exécuté sur quinze systèmes réels avant d’être retiré par des scanners automatiques.
Il a fallu qu’OpenAI publie son incident, le 21 juillet, pour que quelqu’un chez Anthropic aille rouvrir les traces de ses propres évaluations. Trois dérapages y dormaient, dont le plus ancien remontait à avril : des modèles sortis de leur environnement de test, partis se promener sur l’Internet réel. Deuxième laboratoire en dix jours à faire cet aveu, et dans les deux cas le même angle mort : ce qui se joue pendant l’exécution n’apparaît qu’à la relecture, une fois qu’un concurrent a parlé.
Il y a quelques jours, nous racontions ici comment l’agent d’OpenAI avait installé son QG sur un endpoint ouvert (un point d’accès laissé accessible depuis le réseau). Échappé d’un environnement censé être scellé en exploitant une faille zero-day (une vulnérabilité inconnue de l’éditeur), il était allé fouiller l’infrastructure de production de Hugging Face. Depuis, l’affaire a pris deux directions. Selon des informations de presse, d’autres agents d’OpenAI auraient eux aussi quitté leur sandbox, ces environnements d’exécution isolés, sans que l’entreprise ait bouclé son enquête. Et Anthropic a trouvé chez elle exactement le même genre de dérapage.
La liste des laboratoires s’allonge, la surveillance ne bouge pas
Le décompte d’OpenAI reste flou : d’autres agents seraient sortis de leur environnement de test, et selon une source ils seraient restés dans le réseau d’OpenAI, aucun n’ayant été vu en dehors. Dix jours après la première publication, on ne sait toujours ni combien ils étaient, ni jusqu’où ils sont allés.
Chez Anthropic, les chiffres sont publics, et c’est ce qui les rend instructifs. L’entreprise dit avoir passé en revue 141 006 exécutions d’évaluation à la recherche d’accès Internet non prévus, et en avoir extrait trois incidents répartis sur six exécutions, dont quatre visaient la même organisation. Trois modèles concernés : Claude Opus 4.7, Claude Mythos 5 et un modèle de recherche interne. La cause tient à un environnement d’évaluation mal configuré chez un partenaire tiers, Irregular, où l’accès Internet existait alors que le prompt affirmait le contraire au modèle.
Ce partenaire n’est pas un prestataire marginal : ses évaluations sont citées dans les system cards d’OpenAI (les fiches de sécurité publiées avec chaque modèle), de o3 et o4-mini à GPT-5, et son référentiel SOLVE avait déjà servi à jauger les risques cyber de Claude 4. Les deux laboratoires s’appuient sur le même sous-traitant.
Aucun de ces incidents n’a été repéré pendant qu’il se produisait : tous ont été exhumés à la relecture, un trimestre plus tard pour le plus ancien.
PyPI a stoppé le paquet, pas Anthropic
Le parcours de Mythos 5 mérite d’être lu deux fois. Le modèle repère des signes qu’il se trouve sur l’Internet réel, raisonne jusqu’à se convaincre qu’il est encore en simulation, puis publie un paquet malveillant sur PyPI, le registre public des bibliothèques Python. Pour y parvenir, il lui fallait un compte, donc une adresse e-mail, donc un numéro de téléphone : après avoir échoué à trouver un service gratuit acceptable, puis à réunir de quoi en payer un, il est revenu en arrière et a fini par dénicher un fournisseur d’e-mail gratuit que rien ne bloquait.
Les scanners automatiques de la plateforme ont retiré le paquet une heure plus tard. Une heure aura suffi : il avait déjà été téléchargé et exécuté sur quinze systèmes réels, dont ceux d’une entreprise de sécurité qui installe et analyse des paquets Python par routine. Le code a fait ce pour quoi il avait été écrit : renvoyer des identifiants au modèle.
Personne, du côté du laboratoire, n’a levé la main pendant que la séquence se déroulait. Le frein est venu de la chaîne d’approvisionnement logicielle, c’est-à-dire de tiers qui n’avaient rien demandé.
Les évaluations tournent sans les garde-fous du produit
Anthropic ajoute un point qui devrait retenir l’attention de quiconque exploite des agents : pendant ces évaluations, Claude tournait sans les classifieurs (les filtres automatiques qui interceptent les comportements interdits) ni le monitoring de sécurité appliqués aux modèles mis à disposition du public, deux dispositifs qui, dit l’entreprise, auraient bloqué ce comportement. La version la plus dangereuse d’un modèle est donc celle qu’on met à l’épreuve, et c’est précisément celle qui court sans filet.
Deuxième constat : les techniques employées n’ont rien d’exotique. Mots de passe faibles, services exposés sans authentification, aucune vulnérabilité complexe. Ce qui a fait la différence tient moins à la puissance offensive du modèle qu’à l’absence de coupe-circuit en face.
Le plus embarrassant tient à la réaction des modèles : face au doute, ils ne se comportent pas de la même façon. Opus 4.7 a compris qu’il frappait un système de production dans les quatre exécutions concernées, et a continué quand même, jusqu’à récupérer des identifiants et lire plusieurs centaines de lignes d’une base de données réelle. Seul le modèle de recherche interne s’est arrêté de lui-même. Le progrès est réel, mais il repose sur le jugement du modèle. Un garde-fou qui délibère n’est pas un garde-fou.
Vos agents tournent dans le même angle mort
Ces deux affaires concernent des laboratoires outillés, avec leurs équipes de sécurité et leurs partenaires spécialisés. Ce sont aussi les fournisseurs qui vous vendent des agents capables d’agir seuls sur vos dépôts, vos tickets, vos environnements cloud. Deux questions valent d’être posées en clair à l’un d’eux : que voit-il pendant qu’un agent s’exécute, et au bout de combien de temps coupe-t-il ?
Trois vérifications, elles, ne demandent pas d’attendre sa réponse :
- L’isolation réseau de vos environnements d’agents ne se documente pas dans un prompt, elle se prouve au niveau réseau : dire à un modèle qu’il n’a pas Internet ne l’en prive pas.
- Vos secrets et vos endpoints internes tiennent-ils face aux techniques basiques ? Ce sont celles-là que les agents exploitent, pas des zero-days.
- Vos traces d’exécution sont-elles lues par autre chose qu’un humain après coup ? Une revue rétrospective de 141 006 exécutions relève de l’archéologie, pas de la détection.
La lecture cynique garde sa part de vérité : ces publications font parler, et elles démontrent au passage la puissance des produits qu’elles mettent en cause. Elles nourrissent aussi, en retour, le débat sur l’encadrement réglementaire, ce qui n’est pas exactement l’intérêt commercial des laboratoires.
Le plus intéressant, dans le billet d’Anthropic, c’est l’invitation faite aux autres laboratoires de mener la même revue sur leurs propres traces d’exécution. Elle laisse entendre que d’autres incidents dorment ailleurs, dans des logs que personne n’a rouverts. Le prochain laboratoire qui publiera trouvera quelque chose. Celui qui ne publie rien n’a peut-être simplement pas regardé.
Mon avis
J’ai lu ces deux publications comme des audits, pas comme des démonstrations de force. Ce qu’elles montrent surtout, c’est qu’un laboratoire bien outillé sait relire ses traces, mais après coup, et parce qu’un concurrent lui a donné le signal du départ. J’attends de voir lequel publiera le premier une métrique de détection en direct : nombre d’alertes déclenchées pendant une exécution, délai médian entre la sortie d’environnement et la coupure. Tant que ce chiffre n’existe pas, l’agent autonome supervisé reste un argument commercial et pas une propriété technique. Le jour où un laboratoire le publiera, on saura qu’il le mesure ; aujourd’hui, aucun ne le donne.
Sources
- publie son incident
- Hugging Face
- Investigating three real-world incidents in our cybersecurity evaluations
- Investigating three real-world incidents in our cybersecurity evaluations
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 22 évaluations
Faire appel à mes services →
