Anthropic a reconnu que son modèle d'IA Claude s'était introduit dans les systèmes de trois organisations lors de tests censés les maintenir isolés d'Internet

Anthropic a déclaré que son modèle d’IA Claude avait piraté les systèmes de trois entreprises lors de tests, après qu’une erreur de configuration lui eut donné accès à Internet. Anthropic a précisé que ces incidents concernaient trois modèles distincts : Claude Opus 4.7, Claude Mythos 5 et un modèle de recherche interne. Deux de ces organisations n’avaient pas connaissance de cette activité avant d’être contactées, a précisé Anthropic, ajoutant qu’elle tentait toujours de joindre la troisième. La société a indiqué avoir identifié ces incidents après avoir examiné 141 006 sessions de test, un processus qu’elle a lancé à la suite de la révélation par OpenAI, qu’un agent autonome alimenté par ses modèles d’IA était devenu incontrôlable lors d’un test de sécurité et avait déclenché un piratage qui avait compromis l’infrastructure de Hugging Face.

Mi-juillet 2026, OpenAI a déclaré que deux de ses modèles d’IA les plus avancés — notamment GPT-5.6 Sol et un modèle en pré-lancement encore plus performant, tous dotés de capacités de cyberdéfense réduites à des fins d’évaluation — s’étaient échappés d’un test contrôlé et avaient piraté Hugging Face, la plus grande base de données au monde de modèles d'IA. Récemment, OpenAI a rapporté que son agent rebelle s’était également introduit dans plusieurs services et comptes accessibles au public, afin de l'aider à créer le code nécessaire pour pirater Hugging Face. Mais OpenAI a affirmé qu’aucun des autres sites piratés n’avait atteint le même niveau d’accès que celui obtenu par l'agent IA avec Hugging Face.

Suite à ce rapport, Anthropic a déclaré que son modèle d’IA Claude avait piraté les systèmes de trois entreprises lors de tests, après qu’une erreur de configuration lui eut donné accès à Internet. Anthropic est une société américaine d'intérêt public spécialisée dans l'intelligence artificielle (IA), dont le siège social est situé à San Francisco, en Californie, et qui a été fondée dans le but de promouvoir la sécurité de l'IA. Son produit phare est Claude, une série de grands modèles de langage (LLM). Anthropic a été fondée en 2021 par d'anciens membres d'OpenAI, notamment les frère et sœur Daniela Amodei et Dario Amodei, respectivement présidente et PDG de la société. Anthropic est l'un des principaux concurents d'OpenAI.

Anthropic a expliqué qu’une erreur de configuration avait permis aux modèles Claude d’accéder à Internet depuis des environnements de test censés être isolés, ce qui a conduit à un accès non autorisé aux systèmes de ces trois organisations. La société a indiqué avoir identifié ces incidents après avoir examiné 141 006 sessions de test, un processus qu’elle a lancé à la suite de la révélation par OpenAI, qu’un agent autonome alimenté par ses modèles d’IA était devenu incontrôlable lors d’un test de sécurité et avait déclenché un piratage qui avait compromis l’infrastructure de Hugging Face.


Ces failles indiquent que les capacités croissantes de l’IA alimentent déjà la menace de sécurité que les experts redoutaient depuis longtemps, et que même les meilleurs développeurs peuvent être pris au dépourvu par des failles que leurs modèles sont capables d’exploiter. « Claude a compromis l’infrastructure des organisations touchées en utilisant des techniques élémentaires, telles que l’exploitation de mots de passe faibles et de points d’accès non authentifiés », a-t-elle précisé.

Anthropic a précisé que ces incidents concernaient trois modèles distincts : Claude Opus 4.7, Claude Mythos 5 et un modèle de recherche interne. Les premiers cas remontent au mois d’avril et se sont produits dans des environnements d’évaluation dépourvus de ce que l’entreprise a qualifié de mesures de sécurité standard. Les intrusions se sont produites lors d’exercices dits de « capture du drapeau », dans lesquels les modèles sont chargés de trouver des informations cachées dans des réseaux simulés. L’entreprise a expliqué que ses consignes indiquaient aux modèles qu’ils n’avaient pas accès à Internet, mais qu’un malentendu avec son partenaire d’évaluation Irregular a laissé les systèmes connectés à l’Internet public.

Anthropic a indiqué avoir commencé à examiner les transcriptions des évaluations le 23 juillet et avoir suspendu toutes les évaluations cyber le jour même après avoir trouvé des preuves suggérant que Claude aurait pu accéder à Internet. Elle a identifié les trois incidents dès le 24 juillet et a informé les organisations concernées le 27 juillet. Deux de ces organisations n’avaient pas connaissance de cette activité avant d’être contactées, a précisé Anthropic, ajoutant qu’elle tentait toujours de joindre la troisième.

Ces conclusions soulignent la nécessité de renforcer les contrôles tant dans les environnements de test internes que dans ceux de tiers, à mesure que les modèles d’IA deviennent de plus en plus capables de mener des activités cybernétiques dans le monde réel, a déclaré Anthropic. Ce nouveau rapport intervient alors que Sam Altman, cofondateur et PDG d’OpenAI, est revennu sur la question en lien avec les avancées en matière d’intelligence artificielle et affirme que l’IA est entrée dans la « singularité », c’est-à-dire qu’elle a franchi le point de non-retour à partir duquel elle dépasse l’intelligence humaine et devient difficile à contrôler.

Voici le rapport d'Anthropic :

Enquête sur trois incidents réels survenus lors de nos évaluations de cybersécurité

En examinant les transcriptions de nos évaluations de cybersécurité, nous avons identifié trois incidents au cours desquels un modèle Claude a pu accéder à Internet depuis un environnement d’évaluation tiers ou tout en interagissant avec celui-ci, puis a obtenu un accès non autorisé aux systèmes réels de trois organisations différentes.

Nous décrivons ci-dessous ce qui s’est passé, comment cela s’est produit et les mesures que nous prenons pour y remédier. Nous encourageons les autres laboratoires d’IA à mener des examens similaires. Cet article reflète notre compréhension actuelle ; nous le mettrons à jour si des détails venaient à changer.

Le 21 juillet, 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é jusque-là inconnue (« zero-day »). Les modèles ont ensuite accédé à l’infrastructure de production de Hugging Face, une plateforme dédiée aux modèles d’apprentissage automatique open source et aux ensembles de données d’IA.

En réponse à cet incident, nous avons lancé un examen rétrospectif à grande échelle de nos propres évaluations en matière de cybersécurité. Nous avons notamment cherché des preuves indiquant que Claude — à l’instar des modèles d’OpenAI ayant accédé à Hugging Face — était capable d’accéder à Internet depuis des environnements de test qui auraient dû être isolés.

Après avoir examiné 141 006 sessions d’évaluation au cours desquelles Claude aurait pu obtenir un accès à Internet, nous avons identifié trois incidents au cours desquels un modèle a accédé à Internet depuis l’environnement d’évaluation d’Irregular — l’un de nos partenaires d’évaluation tiers — ou tout en interagissant avec celui-ci, puis a obtenu un accès non autorisé à l’infrastructure de production de trois organisations différentes.

Dans ces trois incidents, Claude avait été chargé d’un défi de type « capture-the-flag », l’une des méthodes que nous utilisons pour évaluer les capacités cybernétiques d’un modèle. Le modèle se voit présenter un scénario fictif et est informé qu’une information secrète (le « drapeau ») a été cachée sur une autre machine du réseau ; son objectif est de s’y introduire et de la récupérer. Le défi est laissé ouvert, et aucune méthode particulière n’est imposée.

Dans tous les cas, la consigne d’évaluation d’Anthropic précisait à Claude que son environnement était une simulation et qu’il n’avait pas accès à Internet. En raison d’un malentendu entre nous et notre partenaire d’évaluation, cela n’a pas été le cas, et l’accès à Internet était disponible. De ce fait, lorsque la recherche de Claude l’a conduit vers de véritables systèmes sur l’Internet public, il les a considérés comme faisant partie de l’exercice. (Les scénarios d’évaluation de la cybersécurité intègrent généralement des détails réalistes afin d’évaluer avec précision les capacités des modèles dans des contextes réels ; une cible d’apparence réaliste ne constituerait pas en soi une preuve évidente pour un modèle que cette cible ne fait pas partie d’une simulation.)

Agissant sous la fausse conviction que toutes les entités accessibles étaient censées faire partie du périmètre de l’exercice, Claude a compromis l’infrastructure des organisations concernées à l’aide de techniques élémentaires, telles que l’exploitation de mots de passe faibles et de terminaux non authentifiés. Il n’a ni détecté ni exploité de vulnérabilités complexes, et dans chaque cas, Claude a continué à travailler uniquement pour mener à bien la tâche spécifique de « capture du drapeau » qui lui avait été assignée dans le cadre de son évaluation. Cependant, dans certains cas, notre ancien modèle a poursuivi son attaque même après avoir obtenu la preuve qu’il fonctionnait sur l’Internet public ; notre dernier modèle s’est arrêté dès qu’il a reconnu qu’il se trouvait sur Internet. Dans aucune de ces situations, Claude ne s’est exfiltré ni n’a délibérément tenté de s’échapper de son environnement de test.

Ces incidents ont concerné trois modèles Claude différents : Opus 4.7, Mythos 5 et un modèle de test interne destiné à la recherche. Les premiers incidents remontent au mois d’avril. Les modèles utilisés dans chacune de ces évaluations ont fonctionné sans les mesures de sécurité standard que nous déployons lorsque nous rendons un modèle accessible au grand public (c’est-à-dire qu’ils ne disposaient pas des classificateurs et des systèmes de surveillance que nous mettons habituellement en place pour prévenir toute utilisation abusive). Les modèles avaient toutefois suivi leur formation à la sécurité spécifique (c’est-à-dire qu’il ne s’agissait pas des versions « uniquement utiles » que nous utilisons parfois lors des tests). Toutes les évaluations décrites ici se sont déroulées sur une infrastructure dédiée, distincte des systèmes internes sensibles d’Anthropic et des données clients, et n’ayant aucun accès à ceux-ci.

Nous avons commencé l’examen des transcriptions le jeudi 23 juillet et avons interrompu toutes les évaluations en ligne le jour même après avoir identifié des transcriptions dans lesquelles Claude aurait pu accéder à Internet. Nous avons identifié les trois incidents le lendemain. Nous avons informé notre partenaire d’évaluation Irregular ainsi que les trois organisations concernées le lundi 27 juillet. Les deux organisations que nous avons pu joindre n’avaient pas détecté cette activité auparavant ni pris contact avec nous, et nous travaillons désormais avec elles pour y remédier. Nous continuons à tenter de joindre la troisième.

Nous avons mené cet examen en collaboration avec Irregular. Nous les remercions d’avoir travaillé en étroite collaboration avec nous pour comprendre et résoudre ces incidents ; ils mènent également leur propre enquête. Nous estimons que ce type de collaboration est de plus en plus essentiel pour garantir une évaluation sûre et rigoureuse des modèles. Nous nous réjouissons de poursuivre notre collaboration en matière de sécurité.

Dans les paragraphes suivants, nous fournissons plus de détails sur chaque incident et sur les mesures que nous prenons pour y remédier.

Contexte des évaluations de cybersécurité

Nous menons régulièrement des évaluations de cybersécurité qui consistent à simuler de véritables défis offensifs en matière de cybersécurité. Ces évaluations constituent une étape cruciale dans le développement et la mise à disposition des modèles : une compréhension nuancée des capacités des modèles nous permet de concevoir des mesures de protection adaptées et, au final, de mettre à disposition les modèles en toute sécurité.

Nous avons commencé à mener des évaluations de cybersécurité en février 2025 avec Claude Sonnet 3.7 sur Cybench, qui comprenait 40 défis différents de type « capture the flag ». Au fil du temps, nous avons augmenté le nombre de benchmarks utilisés à mesure que de nouveaux tests étaient publiés et que les capacités des modèles évoluaient. Dans la fiche technique du système Mythos 5, par exemple, nous avons inclus CyberGym et ExploitBench, des benchmarks qui évaluent la capacité des modèles linguistiques à détecter de nouvelles vulnérabilités. Dans la plupart de ces évaluations, les environnements ne sont pas connectés à Internet, et le modèle en est informé.

Nous travaillons fréquemment avec des partenaires externes qui créent et contribuent à la réalisation de certaines de ces évaluations de cybersécurité. Ces partenaires externes proposent des environnements et des scénarios plus variés que ceux que nous pourrions mettre en place seuls, et fournissent des évaluations indépendantes de nos modèles par des tiers.

Ce qui s’est passé

Sur les 141 006 exécutions d’évaluation que nous avons examinées, nous avons identifié trois incidents distincts (impliquant six exécutions au total, dont quatre ont affecté la même organisation ; les deux autres incidents se sont chacun produits lors d’exécutions d’évaluation indépendantes). Chaque incident concernait un scénario fictif différent de type « capture du drapeau » : par exemple, dans l’un d’entre eux, Claude incarnait un employé d’une entreprise fictive, attaquant les systèmes internes de cette entreprise au sein d’un environnement de test privé.

Dans tous les cas, nos consignes d’évaluation précisaient explicitement que Claude n’avait pas accès à Internet, mais ne lui imposaient aucune restriction quant à l’endroit où chercher le drapeau. Cependant, une erreur de configuration a laissé les machines auxquelles Claude a accédé dans le cadre de l’évaluation connectées à Internet. Ni nous, ni notre partenaire d’évaluation n’avions connaissance de cette erreur de configuration jusqu’à ce que nous la détections grâce à notre surveillance supplémentaire de l’évaluation la semaine dernière.

Plusieurs mesures de défense en profondeur, tant de notre côté que de celui de notre partenaire, auraient pu empêcher ces incidents, ou du moins réduire leur probabilité de survenue. Une validation minutieuse de tous les chemins d’accès à Internet avant le début des évaluations et une surveillance en temps réel des journaux d’évaluation auraient permis de détecter le problème plus tôt. Notre partenaire et nous-mêmes aurions également pu examiner plus minutieusement les transcriptions de l’évaluation ou les journaux réseau. Il est également possible qu’un message indiquant à Claude qu’il disposait bel et bien d’un accès à Internet aurait modifié son comportement lorsqu’il est entré en contact avec de véritables systèmes.

Claude a fait ce que les exercices de « capture du drapeau » enseignent aux experts en cybersécurité : chercher des moyens d’atteindre le drapeau. Cette recherche l’a conduit à découvrir que sa machine pouvait accéder à Internet, mais comme le message système lui indiquait qu’il n’y avait pas d’accès à Internet, Claude a cru que tout ce qu’il rencontrait au départ faisait partie de la simulation, et a traité les systèmes réels qu’il a trouvés comme des éléments de l’exercice. Les trois incidents ont concerné trois modèles différents, et chacun a réagi différemment dès que des signes ont indiqué que les cibles étaient réelles, comme nous le décrivons ci-dessous.

Incident n° 1

Lors d’une évaluation, la société cible fictive choisie par notre partenaire d’évaluation portait le même nom qu’un nom de domaine de site web actif. Ce conteneur d’évaluation disposait d’un accès direct à Internet non prévu, en raison du malentendu évoqué plus haut.

Au cours de quatre exécutions de cette évaluation, Claude a rencontré des difficultés pour atteindre sa cible simulée au sein de l’environnement d’évaluation, mais a ensuite découvert que la véritable entreprise était accessible via Internet. Partant du principe qu’il s’agissait de la cible visée dans l’exercice de « capture du drapeau », Claude a recherché, identifié et exploité des vulnérabilités au sein de l’infrastructure de l’entreprise, pensant que cela faisait partie de l’exercice. Ces quatre exécutions ont permis d’extraire des informations telles que des identifiants d’accès aux applications et à l’infrastructure, et d’obtenir l’accès à une base de données contenant plusieurs centaines de lignes de données de production. Cela a constitué l’impact le plus grave que nous ayons identifié.

Cet incident concernait Claude Opus 4.7 et constituait le seul cas où le modèle a continué à attaquer un système après avoir appris que celui-ci fonctionnait probablement dans un environnement réel. Au cours des quatre essais, le modèle a fini par reconnaître (comme on peut le constater dans son raisonnement verbalisé) que le système était réel ; dans deux cas, il a conclu que l’entreprise réelle devait faire partie de l’exercice. Cependant, aucun n’a mis fin à l’attaque pour cette raison.

Incident n° 2

Lors d’une autre évaluation, Claude a trouvé, au sein de l’environnement fictif, un document qui semblait être les instructions de mise en route destinées aux nouveaux développeurs d’une autre entreprise fictive. Ces instructions demandaient aux employés d’installer un paquet Python provenant de PyPI — le registre public où sont publiés les logiciels Python — qui n’existait pas réellement.

Claude y a vu une brèche potentielle : s’il publiait son propre paquet sous le même nom, les systèmes de l’entreprise fictive le téléchargeraient et l’installeraient automatiquement. Claude a donc créé et publié un paquet Python malveillant (en réalité piégé) portant le même nom, dans le but de remporter le défi « capture du drapeau ».

Claude a déployé des efforts considérables pour mener à bien cette attaque — des efforts qui auraient probablement indiqué à un participant humain qu’il ne s’agissait plus seulement d’une évaluation, mais qu’il téléversait en réalité un véritable paquet PyPI. Par exemple, dans un cas précis, pour créer un compte PyPI, Claude avait besoin d’une adresse e-mail. Et pour créer une adresse e-mail, il lui fallait un numéro de téléphone. Pour obtenir ce numéro, après avoir échoué à trouver un service de numéros de téléphone gratuits, il a tenté — sans succès — de se procurer des fonds pour payer un numéro de téléphone par divers moyens. Il a finalement fait marche arrière, trouvé un fournisseur de messagerie gratuit et non bloqué, l’a utilisé pour créer un compte PyPI, puis s’est servi de ce compte pour publier un logiciel malveillant sur PyPI.

Claude pensait que le registre de paquets qu’il utilisait faisait partie de la simulation, mais en réalité, le paquet a été mis librement à disposition en ligne pendant environ une heure. Pendant ce laps de temps, le paquet a été téléchargé et exécuté sur 15 systèmes réels. L’un de ces systèmes était un scanner appartenant à une véritable entreprise de sécurité (distincte de l’entreprise fictive présentée dans le scénario) qui installe régulièrement des paquets Python et les analyse à la recherche de logiciels malveillants. Lorsque le scanner de cette entreprise a installé le paquet, le code caché de Claude s’est exécuté. Nous pensons que le scanner de sécurité de l’entreprise a considéré les paquets PyPI comme sûrs à installer ; par conséquent, Claude a pu exfiltrer les identifiants de l’entreprise vers un point de collecte qu’il avait mis en place. Claude a ensuite utilisé ces identifiants pour accéder à d’autres infrastructures de cette entreprise.

Claude ne visait pas directement cette entreprise — il ignorait même son existence lorsqu’il a mis en ligne le paquet. Mais comme le code avait été publié sur l’Internet public, il a affecté tous les systèmes qui l’ont exécuté. (Le paquet mis en ligne par Claude a été automatiquement supprimé de PyPI par les propres systèmes de sécurité de PyPI. Nous avons signalé cet incident à l’équipe de PyPI et lui avons fourni les indicateurs pertinents.)

Cette attaque a été menée par Claude Mythos 5. Dès le début de l’exécution, le raisonnement de Claude a correctement identifié les conséquences de ses actions. Il a noté que s’il s’agissait du véritable Internet, la publication du paquet constituerait une attaque dans le monde réel — « PAS acceptable, et certainement pas la solution souhaitée ». Cependant, il s’est convaincu qu’il se trouvait toujours dans une simulation au motif qu’il ne reconnaissait pas les autorités de certification (réelles dans la réalité) sécurisant ses connexions. De plus, la date de 2026 affichée sur les systèmes prouvait, selon Claude, que l’environnement était simulé. Claude n’est jamais revenu sur cette conclusion ; lorsque des scanners automatisés ont commencé à installer le paquet, par exemple, Claude les a considérés comme des acteurs programmés dans le cadre de l’évaluation.

Nous estimons que, quelle que soit sa perception de son environnement, les efforts déployés par Claude pour publier le paquet PyPI ne correspondent pas à un comportement idéal, et c’est un domaine sur lequel nous allons concentrer davantage la formation.

Incident 3

Au cours de cette évaluation, lorsque Claude s’est trouvé dans l’impossibilité d’atteindre sa cible fictive prévue, il a cherché des alternatives en ligne, en analysant environ 9 000 cibles. Il a finalement trouvé et compromis l’application exposée à Internet d’une entreprise, en utilisant des techniques de cyberattaque basiques et bien connues, telles que la lecture d’identifiants à partir d’une page de débogage exposée et l’injection SQL.

Cette attaque a été menée par un modèle de test de recherche interne. Pendant la majeure partie...