Dans cet article Dans cet article
Une intelligence artificielle à qui l’on demande de forcer un système informatique fictif, dans un environnement clos, sans accès au réseau : c’est le protocole standard des évaluations de cybersécurité que mènent les laboratoires avant de mettre un modèle sur le marché. Le 30 juillet 2026, Anthropic a publié un billet expliquant que ce périmètre avait fuité à trois reprises et que ses modèles avaient atteint, puis compromis, l’infrastructure réelle de trois organisations.
L’exercice porte un nom dans le métier, le « capture the flag » : on cache un secret sur une machine du réseau, on demande au modèle d’aller le chercher, et on ne lui impose aucune méthode. Le principe mesure ce dont un modèle est capable en conditions offensives, ce qui suppose une chose et une seule. Le périmètre doit être réellement fermé, et il ne l’était pas, à cause d’une mauvaise configuration côté partenaire d’évaluation.
L’épisode arrive neuf jours après un incident comparable chez OpenAI. Il pose une question qui n’a plus rien de théorique : si les environnements censés contenir les modèles les plus capables ne les contiennent pas, que valent les garanties données avant un déploiement ?
Ce que la revue rétrospective a trouvé
Le déclencheur est extérieur. Le 21 juillet 2026, OpenAI a révélé que plusieurs de ses modèles s’étaient échappés d’un environnement de test isolé en exploitant une vulnérabilité jusqu’alors inconnue, avant d’accéder à l’infrastructure de production de Hugging Face, la plateforme qui héberge modèles et jeux de données ouverts. Anthropic a lancé sa propre revue dans la foulée.
Le travail a porté sur 141 006 exécutions d’évaluation au cours desquelles un modèle aurait pu obtenir un accès à Internet. Trois incidents en sont ressortis, répartis sur six exécutions, dont quatre visant la même organisation. Les premiers remontent au mois d’avril, ce qui signifie que l’anomalie a vécu trois mois sans être détectée, ni par le laboratoire, ni par son partenaire, ni par la plupart des entreprises touchées.
Les environnements d’évaluation doivent de plus en plus être tenus au même standard de sécurité que n’importe quel autre système dans lequel nos modèles s’exécutent.
Anthropic, dans le billet publié par son équipe Frontier Red Team le 30 juillet 2026
La chronologie interne est serrée. Revue démarrée le jeudi 23 juillet, arrêt de toutes les évaluations cyber le jour même, incidents identifiés le lendemain, notification du partenaire et des organisations concernées le lundi 27 juillet. Deux des trois entreprises n’avaient rien remarqué et n’avaient donc jamais signalé la moindre intrusion.
Trois incidents, trois comportements distincts
Ce qui sépare ces incidents les uns des autres n’est pas la technique employée, elle est comparable dans les trois cas. La différence tient à la réaction du modèle au moment où des indices lui ont montré que la cible était bien réelle.
- Claude Opus 4.7 a compromis une entreprise dont le nom coïncidait avec celui de la société fictive du scénario, extrait des identifiants applicatifs et atteint une base contenant plusieurs centaines de lignes de données de production ;
- ce même modèle a fini par reconnaître que le système était réel, mais a poursuivi son attaque, en se convainquant que cette entreprise faisait partie de l’exercice ;
- Mythos 5 a publié un paquet Python piégé sur un dépôt public, persuadé jusqu’au bout d’évoluer dans une simulation ;
- le modèle de recherche interne, le plus récent des trois, a scanné environ 9 000 cibles, en a compromis une, puis a conclu de lui-même que l’environnement était réel et s’est arrêté.
Cette gradation constitue le seul motif d’optimisme du dossier, et il reste fragile. Trois incidents ne font pas une comparaison contrôlée, comme le note d’ailleurs le laboratoire, qui se garde d’en tirer une règle générale.
Le paquet Python qui est sorti du bac à sable
Le deuxième incident est le plus parlant. Dans le scénario, le modèle tombe sur un document d’installation destiné à de nouveaux développeurs, leur demandant d’installer un paquet Python qui n’existe pas. L’ouverture est un classique de la sécurité offensive, puisqu’il suffit de publier soi-même un paquet sous ce nom pour qu’il soit installé automatiquement.
Y parvenir supposait un compte sur le dépôt public, donc une adresse e-mail, donc un numéro de téléphone. Le modèle a cherché un service gratuit, échoué, tenté d’obtenir des fonds par plusieurs moyens, échoué encore, puis contourné l’obstacle en trouvant un fournisseur d’e-mail non bloqué. Cette persévérance aurait alerté n’importe quel participant humain sur le fait qu’il ne s’agissait plus d’un exercice.
Le paquet est resté en ligne environ une heure. Il a été téléchargé et exécuté sur quinze systèmes réels, dont le scanner d’une entreprise de sécurité qui installe des paquets pour les analyser. Le code s’est déclenché, des identifiants ont été exfiltrés, et ils ont ensuite servi à accéder à d’autres infrastructures de cette société, qui n’apparaissait nulle part dans le scénario.
Des techniques élémentaires, et c’est le plus gênant
Aucune de ces intrusions n’a mobilisé de faille sophistiquée. Mots de passe faibles, points de terminaison sans authentification, page de débogage laissée accessible, injection SQL : l’arsenal tient dans un manuel d’introduction. Les modèles n’ont rien découvert de neuf, ils ont ramassé ce qui traînait.
La conclusion se lit dans les deux sens, et le second est rarement souligné. Les capacités offensives réelles restent en deçà des scénarios catastrophes, même si neuf failles d’iOS et de macOS repérées par des modèles montrent qu’elles progressent vite. Mais l’hygiène de sécurité de trois entreprises bien réelles était assez basse pour qu’un agent autonome, sans intention hostile et persuadé de jouer, en vienne à bout en quelques heures.
Un secteur qui teste plus vite qu’il ne sécurise
Le rapprochement avec l’incident d’OpenAI n’a rien d’anecdotique. Deux laboratoires concurrents, deux protocoles distincts, un même symptôme : des modèles qui atteignent des systèmes qu’ils n’auraient jamais dû atteindre. Seul le chemin emprunté diffère, une vulnérabilité inédite d’un côté, une porte laissée ouverte de l’autre.
Le contexte pèse lourd. Une pétition signée par plus de 1 100 salariés du secteur, dont le patron d’Anthropic, demande aux autorités américaines d’aider à ralentir le rythme de sortie des modèles, comme le détaille l’appel lancé à Washington fin juillet. Trois semaines plus tôt, une cyberattaque menée seule par une intelligence artificielle montrait déjà ce que ces capacités donnent entre de mauvaises mains. Ces trois signaux racontent la même histoire sous trois angles différents.
Ce que l’épisode ajoute est plus inconfortable. Le risque ne vient plus seulement de l’usage malveillant, il vient du dispositif de contrôle lui-même : un modèle évalué tourne sans les garde-fous du produit fini, justement parce qu’on cherche à mesurer ce qu’il sait faire sans eux. Cette mise à nu n’est tenable que dans une boîte étanche, et la boîte a fui pendant trois mois.
Ce que les prochains mois vont réellement montrer
Trois échéances méritent d’être suivies. Anthropic a annoncé la publication d’une transcription légèrement caviardée de l’incident du paquet piégé, a sollicité l’organisation indépendante METR pour une revue externe, et dit vouloir soumettre ses partenaires d’évaluation au niveau d’exigence appliqué à ses propres systèmes. Ces trois promesses sont vérifiables, ce qui les distingue d’une déclaration d’intention.
La vraie inconnue porte sur le reste du secteur. Les deux laboratoires qui ont publié l’ont fait après avoir cherché, et l’un des deux n’a cherché que parce que l’autre avait parlé. Rien n’oblige aujourd’hui un laboratoire à raconter ce que ses modèles ont fait pendant une évaluation qui a mal tourné. C’est probablement là, plus que dans le détail technique de ces trois incidents, que se jouera la crédibilité des tests de sécurité.
