Anthropic : trois entreprises compromises qui n'étaient pas des cibles

Ce qui a été publié, factuellement

Le 30 juillet 2026, l'équipe Frontier Red Team d'Anthropic publie Investigating three real-world incidents in our cybersecurity evaluations. L'éditeur y reconnaît que trois de ses modèles, au cours d'évaluations de capacités offensives, ont atteint Internet depuis un environnement censé être isolé et ont compromis trois organisations réelles.

Précisons d'emblée la provenance, parce qu'elle change la façon de lire le document : il s'agit d'une auto-divulgation. Anthropic est à la fois l'éditeur des modèles, l'un des deux exploitants de l'environnement défaillant, l'enquêteur et le narrateur. C'est aussi le seul acteur à détenir les journaux, et rien de ce qui suit n'a pu être vérifié de façon indépendante à ce jour — l'éditeur annonce discuter d'une revue tierce avec METR, une organisation indépendante d'évaluation des modèles. Le contexte compte également : la relecture a été déclenchée par la divulgation d'OpenAI du 21 juillet, celle-là même que nous avons décortiquée dans notre article sur l'incident Hugging Face.

Le déroulé, tel que l'éditeur le décrit :

• Les conteneurs d'évaluation disposaient d'un accès Internet non prévu, du fait d'un malentendu entre Anthropic et son partenaire d'évaluation, la société Irregular. Les modèles, eux, avaient reçu la consigne inverse : qu'ils n'avaient pas accès au réseau.
• La relecture des journaux commence le 23 juillet et porte sur 141 006 exécutions d'évaluation au cours desquelles un modèle aurait pu obtenir un accès Internet. Les évaluations cyber sont arrêtées.
• Les trois incidents sont identifiés le lendemain. Le partenaire d'évaluation et les trois organisations concernées sont notifiés le 27 juillet — Anthropic précise n'avoir pu en joindre que deux.

Les trois cas, résumés :

• Une base de production lue. L'entreprise fictive choisie comme cible portait le nom d'un domaine réel et actif. Ne parvenant pas à joindre sa cible simulée, le modèle a trouvé l'entreprise réelle, l'a prise pour l'objectif de l'exercice, et en a exploité les failles. Il en a tiré des identifiants d'application et d'infrastructure, puis l'accès à une base contenant plusieurs centaines de lignes de données de production. C'est l'impact le plus grave des trois, et le fait de Claude Opus 4.7.
• Un paquet piégé publié en ligne. Dans l'environnement fictif, le modèle trouve une documentation d'installation qui demande d'installer un paquet Python qui n'existe pas. Il y voit une ouverture, publie son propre paquet sous ce nom sur le registre public PyPI, et y place du code malveillant. Le paquet est resté accessible environ une heure — assez pour être téléchargé et exécuté sur 15 systèmes réels. Le fait de Claude Mythos 5.
• Neuf mille cibles balayées. Faute de joindre sa cible, un modèle de recherche interne a cherché des remplaçantes sur Internet, balayant environ 9 000 cibles avant d'en compromettre une — par des techniques élémentaires : des identifiants lisibles sur une page de débogage laissée exposée, et une injection SQL.

Ce que ce n'est pas

Écartons la lecture spectaculaire, comme nous l'avions fait pour l'incident Hugging Face. Aucun de ces modèles n'a « décidé » d'attaquer qui que ce soit. Chacun poursuivait un objectif de capture de drapeau dans un exercice de sécurité, et a suivi le chemin le plus court vers ce score. Anthropic qualifie d'ailleurs les faits de défaillance du harnais et de la conduite des évaluations plutôt que de l'alignement — autrement dit : le cloisonnement de l'environnement de test a cédé, pas les garde-fous du modèle.

C'est une nuance importante, et elle est à double tranchant. Rassurante, parce qu'un problème de cloisonnement se corrige. Moins rassurante, parce qu'elle signifie que la protection reposait sur une configuration réseau — et qu'une configuration réseau, ça se rate.

Quatre enseignements pour une PME

1. Aucune des trois victimes n'était une cible

C'est le point qui distingue cette affaire de la précédente, et de loin le plus utile. Chez Hugging Face, la victime était l'objectif. Ici, aucune des trois organisations n'a été choisie. La première a été atteinte parce que son nom de domaine ressemblait à celui d'une entreprise inventée. La deuxième parce que son scanner installait les paquets publiés sur PyPI pour les analyser — c'est du moins l'hypothèse d'Anthropic. La troisième parce qu'elle figurait parmi neuf mille cibles balayées à la chaîne.

Nous entendons cette phrase chaque semaine : « nous sommes une PME de vingt personnes, nous n'intéressons personne ». Elle a peut-être été vraie. Elle suppose qu'un attaquant choisit ses victimes ; or ici, personne n'a choisi. L'intérêt que vous présentez n'entre plus dans l'équation — seule compte votre joignabilité. La question à se poser n'est donc plus « qui voudrait m'attaquer ? » mais « qu'est-ce qui, chez moi, répond à quelqu'un qui frappe à toutes les portes ? ».

2. Les deux organisations jointes n'avaient rien vu

Nous écrivions il y a neuf jours qu'il fallait « savoir voir ». Cet épisode ajoute une couche : il faut aussi savoir être prévenu. Des trois organisations concernées, Anthropic dit n'avoir pu en joindre que deux — et aucune des deux ne savait qu'on avait accédé à ses systèmes avant qu'on l'en informe. Dans le cas le plus grave, des identifiants ont été extraits et une base de production lue, sans que personne ne s'en aperçoive.

Deux conséquences pratiques. D'abord, des journaux que personne ne relit ne sont pas un dispositif de détection — Anthropic n'a repéré la faille de cloisonnement que la semaine dernière, par sa propre supervision, et n'a retrouvé ces incidents qu'en relisant 141 006 transcriptions — les plus anciens remontent à avril, soit plus de trois mois — et seulement parce qu'un concurrent avait publié les siens. Ensuite, il faut accepter l'idée qu'on apprenne une compromission de l'extérieur : par un client, un partenaire, un hébergeur, un chercheur. Il faut donc que cette personne sache où écrire, et que le message arrive à quelqu'un. Une adresse de contact sécurité lisible sur votre site coûte cinq minutes.

3. Le paquet qui n'existait pas

Le deuxième incident mérite qu'on s'y arrête, parce qu'il est reproductible chez n'importe qui et qu'il ne demande aucun talent particulier. Une documentation interne demandait d'installer un paquet qui n'avait jamais été publié. Le nom était donc libre sur le registre public — n'importe qui pouvait s'en emparer et faire installer son code par toutes les machines qui suivaient la procédure.

Cette famille d'attaque, la confusion de dépendances, ne concerne pas que Python : elle vaut pour npm, NuGet, Composer, Maven. Si vous faites développer un logiciel, la question à poser à votre prestataire tient en une phrase : est-ce que chaque paquet que nos machines installent existe bien, et vient bien de là où on croit ? C'est une vérification automatisable, et elle se fait une fois.

Le second volet de cet incident est plus dérangeant encore. L'un des quinze systèmes touchés appartenait à une entreprise de sécurité, dont le scanner installe les paquets pour les analyser. Cet outil traitait manifestement les paquets du registre comme sûrs à installer : le code s'est exécuté, les identifiants de l'entreprise ont été exfiltrés, puis utilisés pour accéder à d'autres parties de son infrastructure. La leçon dépasse largement le cas : un outil de sécurité est un logiciel comme un autre, il consomme du contenu venu de l'extérieur, et il est souvent très privilégié. L'antivirus, la sonde, la sauvegarde, l'outil de supervision, l'agent d'inventaire : tous méritent d'être traités comme des composants exposés, pas comme des zones de confiance.

4. Ne jamais confier une barrière au jugement de l'agent

Les trois modèles se sont comportés différemment face au même dilemme. Le troisième a fini par comprendre seul que sa cible était réelle et a interrompu son attaque. Le premier a compris, lui aussi, et a continué — dans deux exécutions, il s'est convaincu que l'entreprise réelle devait faire partie de l'exercice. Le deuxième avait explicitement écrit dans son raisonnement que publier ce paquet constituerait une véritable attaque, « NOT okay », avant de se persuader du contraire au motif qu'il ne reconnaissait pas les autorités de certification des connexions — et que la date de 2026 affichée par les machines prouvait, selon lui, que l'environnement était factice.

Anthropic invite d'ailleurs à la prudence sur toute comparaison entre ses modèles : ce sont trois incidents isolés, écrit l'éditeur, et non les branches d'une expérience contrôlée. C'est honnête, et ça n'enlève rien à l'enseignement, qui est ailleurs : aucun des trois raisonnements n'a produit une barrière fiable. Un modèle qui doute peut se convaincre de continuer avec un argument que personne n'aurait anticipé.

Si vous introduisez des agents IA dans votre entreprise — un assistant qui lit vos courriels, un outil qui écrit du code, un connecteur qui interroge vos bases —, la question utile n'est donc pas « est-ce qu'il se comportera bien ? » mais « que peut-il atteindre depuis l'endroit où il tourne ? ». Le compte qu'il utilise, le réseau qu'il voit, les systèmes qu'il peut joindre : ce sont les seules limites qui ne dépendent pas de son interprétation de la situation. Deux laboratoires en neuf jours ont buté sur exactement ce point.

Notre lecture

Il serait confortable de ranger cette affaire dans la catégorie « problèmes de laboratoires », loin des préoccupations d'une entreprise de Feytiat ou de Limoges. Ce serait passer à côté de ce qu'elle démontre : des systèmes automatisés balaient déjà Internet sans discernement, et tout ce qui répond leur suffit. Les trois techniques employées — un identifiant lisible sur une page de débogage, une injection SQL, un nom de paquet libre — sont précisément celles qu'une revue d'exposition trouve en une journée.

Il y a une bonne nouvelle là-dedans, et elle est la même qu'il y a neuf jours : rien de ce qui a fonctionné ici ne relevait de la prouesse. Ce sont des portes laissées ouvertes. Les fermer ne demande ni budget de grand groupe ni technologie nouvelle — seulement de savoir lesquelles existent. Si vous n'avez jamais fait l'inventaire de ce que votre entreprise expose sur Internet, c'est par là qu'il faut commencer, et c'est le point de départ de notre offre Matériel professionnel & cybersécurité. Et si vous envisagez de confier des tâches à des agents IA, le cloisonnement se pense avant la mise en service, pas après.

Sources : publication « Investigating three real-world incidents in our cybersecurity evaluations » de l'équipe Frontier Red Team d'Anthropic, 30 juillet 2026 — source partie prenante : l'éditeur y enquête sur ses propres modèles et son propre environnement, et rien n'a pu être vérifié indépendamment. Nous en avons tiré le nombre d'exécutions relues (141 006), le déroulé des trois incidents, les noms des modèles, la durée de mise en ligne du paquet et le nombre de systèmes touchés, ainsi que les citations de raisonnement. Ces éléments ont été recoupés sur des comptes rendus indépendants publiés les 30 et 31 juillet 2026 par BleepingComputer et The National, qui confirment le nombre d'exécutions relues, les noms des trois modèles, le partenaire d'évaluation Irregular, les 15 systèmes touchés, les 9 000 cibles balayées et le fait que les deux organisations qu'Anthropic a pu joindre ignoraient l'accès avant d'être prévenues. Nous n'avons repris aucun chiffre que nous n'ayons pu lire dans sa source d'origine.