Bienvenue dans

la base de données des incidents d'IA

Les clients des hôtels d'Atlantic City ont une nouvelle occasion de prouver les allégations selon lesquelles plusieurs casinos auraient conspiré pour fixer les prix à l'aide d'un algorithme commun. La Cour d'appel du troisième circuit des États-Unis a en effet rompu avec les décisions des juridictions inférieures en relançant l'affaire.

Un collège de trois juges de la Cour d'appel du troisième circuit a statué mercredi que le tribunal de district du New Jersey avait « commis une erreur en ne reconnaissant pas la nature de la conspiration ». Caesars Entertainment, MGM Resorts, Hard Rock International et d'autres hôtels auraient convenu d'utiliser le logiciel de tarification Rainmaker de Cendyn pour augmenter leurs tarifs.

« Ce système présumé ne fonctionnerait que si les hôtels-casinos pouvaient maintenir des prix de chambres plus élevés, sachant que les autres hôtels-casinos ne baisseraient pas leurs tarifs pour attirer la clientèle potentielle », indique l'arrêt faisant jurisprudence. « Cela confirme sans aucun doute l'hypothèse d'une collusion ; en effet, nous ne voyons aucune autre explication. »

Herbert Hovenkamp, professeur de droit à l'Université de Pennsylvanie, a déclaré que la Cour d'appel du Troisième Circuit avait conclu à juste titre que ces allégations de tarification algorithmique en réseau violaient la loi Sherman.

« Il s'agit d'un système de cartel parfait où l'on engage un intermédiaire pour calculer le prix convenu, et où les hôtels appliquent ensuite ce prix par défaut », a expliqué M. Hovenkamp. « On obtient ainsi un cartel extrêmement efficace. »

M. Hovenkamp a ajouté que cette décision était une « bonne chose » pour les plaignants qui contestent l'utilisation partagée d'un algorithme, comme ils l'ont fait dans des secteurs liés à l'hôtellerie, aux appartements et à l'assurance maladie.

« Tout à fait improbable »

En mai 2023, un groupe de clients d'hôtels a poursuivi Caesars Entertainment, Hard Rock, Borgata et MGM, les accusant d'avoir illégalement fixé les prix en utilisant l'algorithme Rainmaker de Cendyn, qui recommanderait des tarifs de chambres en fonction d'informations concurrentielles sensibles partagées par les casinos.

La juge Karen Williams a rejeté l'affaire en septembre 2024 sans possibilité de modification, estimant qu'une entente illicite était « tout à fait improbable ».

Selon elle, la juge a précisé que la période de 14 ans durant laquelle les hôtels ont adopté le système Rainmaker – et leur autonomie en matière de tarification – ne démontre pas l'existence d'un accord entre eux.

La Cour d'appel du Troisième Circuit a infirmé cette décision mercredi, estimant que les plaignants avaient présenté suffisamment d'allégations pour permettre de conclure de manière plausible que les hôtels défendeurs s'étaient entendus pour fixer les prix.

À partir de 2022, les hôtels ont continué d'augmenter leurs tarifs malgré la baisse de leur taux d'occupation, tout en se conformant aux recommandations de Rainmaker dans 90 % des cas, selon l'avis rendu.

Les juges ont indiqué que le tribunal de première instance exigeait des plaignants qu'ils expliquent précisément comment l'algorithme facilite l'échange d'informations, mais que cela n'était pas nécessaire à ce stade.

« Cela revient à exiger des plaignants qu'ils expliquent le fonctionnement du logiciel propriétaire de Cendyn sans leur avoir fourni les éléments de preuve nécessaires », ont-ils écrit.

La Cour d'appel du troisième circuit a renvoyé l'affaire devant le tribunal de district des États-Unis pour le district du New Jersey afin qu'elle soit instruite plus avant.

Que se passe-t-il à Las Vegas ?

En appel, les plaignants ont fait valoir que le tribunal fédéral du New Jersey avait présumé à tort que leur plainte contenait les mêmes erreurs qu'une action en justice similaire intentée contre les mêmes hôtels et Cendyn à Las Vegas.

Les clients des hôtels de Las Vegas avaient initialement allégué qu'un groupe d'hôtels similaire avait conclu une entente illicite avec Cendyn, mais ils ont abandonné cette allégation après son rejet par le tribunal de district du Nevada.

Les plaignants de Las Vegas ont interjeté appel devant la Cour d'appel du neuvième circuit, en ne soulevant qu'un seul chef d'accusation : les accords individuels conclus entre Cendyn et chaque hôtel auraient causé un préjudice anticoncurrentiel « pris dans leur ensemble ».

La Cour d'appel du neuvième circuit a catégoriquement rejeté cette demande en mai 2025, estimant que les plaignants ne pouvaient invoquer l'article 1 « en l'absence de preuve d'un accord entre les hôtels défendeurs ».

Joshua Davis, associé du cabinet Berger Montague, qui représentait l'American Antitrust Institute dans un mémoire d'amicus curiae en faveur des plaignants, a déclaré qu'il était probablement prématuré de demander à la Cour suprême de se prononcer sur les affaires Cendyn avant que d'autres juridictions inférieures ne s'en soient saisies.

« Il est très encourageant de voir cette Cour reconnaître le type de danger que représente l'IA et la nécessité de repenser l'application de notre droit de la concurrence. »

La Cour d'appel du Troisième Circuit est la dernière juridiction en date à citer le discours prononcé en 2017 par Maureen Ohlhausen, ancienne directrice par intérim de la Commission fédérale du commerce (FTC), dans lequel elle déclarait : « Si une personne nommée Bob ne peut pas agir ainsi, un algorithme ne peut probablement pas le faire non plus. »

« Il ne faut pas empêcher les entreprises de déployer de meilleurs outils analytiques, car anticiper et réagir aux actions des concurrents est essentiel à la libre concurrence », a déclaré un associé du cabinet Wilson Sonsini Goodrich & Rosati au sujet de cet avis. « Il est nécessaire qu'il existe une indication d'un accord permettant de démontrer que les utilisateurs de l'algorithme n'agissent plus de manière indépendante. »

La Cour d'appel du Troisième Circuit a précisé qu'elle n'avait « formulé aucune hypothèse ni conclusion » quant au fonctionnement réel du logiciel de Cendyn, mais qu'il existe « rarement des justifications commerciales légitimes pour accorder à des concurrents le bénéfice d'informations confidentielles et sensibles dans les circonstances alléguées en l'espèce ».

La Cour suprême a rejeté une demande d'examen de la décision de la Cour d'appel du Neuvième Circuit. Cependant, l'arrêt rendu aujourd'hui étant en divergence avec la jurisprudence de la Côte Ouest, les juges pourraient être plus enclins à examiner un recours déposé par les défendeurs, exploitants d'hôtels-casinos.

M. Davis a indiqué s'attendre à ce que la prochaine étape des défendeurs soit vraisemblablement une requête en réexamen de l'affaire par la Cour d'appel du Troisième Circuit.

Le ministère de la Justice avait exhorté la Cour d'appel du neuvième circuit à rouvrir l'affaire de Las Vegas et avait exprimé son soutien à l'affaire d'Atlantic City avant le dépôt de la requête en irrecevabilité.

La Cour d'appel du troisième circuit a également répondu à un argument du Centre international de droit et d'économie (ICLE), qui soutenait dans un mémoire d'amicus curiae que la plainte des demandeurs risquait d'engager la responsabilité des stations-service utilisant les mêmes formules dans un tableur Excel.

La Cour a estimé que ces arguments négligeaient certains points précis de la plainte.

« Loin des exemples avancés par l'ICLE de logiciels utilisés séparément et indépendamment pour aider les entreprises à se faire concurrence, Rainmaker est présenté comme un acteur unique, coordonnant les prix pour la majorité du marché », a déclaré la Cour d'appel du troisième circuit.

Zach Fields, collaborateur de deuxième année chez Susman Godfrey, a plaidé en appel pour le compte des plaignants.

« Nous nous félicitons que la première cour d'appel fédérale saisie d'une affaire d'entente horizontale comme la nôtre ait jugé à juste titre que le recours à la tarification basée sur l'IA n'exonère pas les pratiques anticoncurrentielles de l'application de la loi Sherman », a déclaré Susman Godfrey dans un communiqué.

Les avocats des défendeurs ont été contactés pour obtenir leurs commentaires.

Avocats du défendeur/intimé Caesars Entertainment

Skadden Arps Slate Meagher & Flom

Sam Auld, Boris Bershteyn, Michael Menitove, Andrew Muscato, Kenneth Schwartz et Tansy Woan à New York

Avocats du défendeur/intimé MGM Resorts

Munger Tolles & Olson

Bethany Kristovich à Los Angeles Justin Raphael à San Francisco

Avocat du défendeur/intimé Hard Rock International

Jones Day

Jennifer Del Medico et Laura Sawyer à New York ; David Kiernan et Matthew Silveria à San Francisco

Avocat du défendeur/intimé Boardwalk 1000 DBA Hard Rock Hotel & Casino Atlantic City

King & Spalding

Craig Carpenito et David Lesser à New York

Avocat du défendeur/intimé Cendyn Group

Latham & Watkins

Melissa Arbus Sherry, Christopher Brown, Lawrence Buterman, Graham Haviland et Anna Rathbun à Washington, D.C. Sadik Huseny et Brendan McShane à San Francisco

Avocats des demandeurs/appelants

Susman Godfrey

Zach Fields à New York et Shawn Raymond à Houston

Hausfeld

Mindee Reuben à Philadelphie

Burns Charest

Chris Cormier à Washington, D.C.

Lite DePalma Greenberg & Afanador

Joseph DePalma et Catherine Derenze à Newark, New Jersey

Avocats de l'Open Markets Institute, appelant amicus curiae

Migliaccio & Rathod

Jason Rathod à Washington, D.C.

Avocats de l'American Antitrust Institute, appelant amicus curiae

Berger Montague

Joshua Davis et Matthew Summers à San Francisco

Juristes d'entreprise

David Fisher à Washington, D.C.

Avocats de l'International Center for Law & Economics, intimé amicus curiae

Shook Hardy & Bacon

Thomas Sullivan Jr à Philadelphie

Cet article Cet article a été initialement publié par Global Competition Review, une publication sœur de Law.com.

Un hôpital vétérinaire de The Dalles a intenté une action en justice contre Google Cloud. Une entreprise de technologies de la santé animale a porté plainte contre Zoetis Inc., société basée dans le New Jersey, l'accusant d'avoir mal identifié une tumeur cancéreuse, entraînant ainsi la mort d'un chien de 11 ans.

La plainte, déposée jeudi par l'hôpital vétérinaire Columbia devant le tribunal du comté de Wasco, accuse Zoetis Inc. de fraude et de violation de la loi de l'Oregon sur les pratiques commerciales déloyales.

L'hôpital affirme que Zoetis Inc. a présenté mensongèrement son outil d'IA, Vetscan Imagyst, comme « l'analyseur d'IA vétérinaire le plus performant au monde », capable d'identifier avec précision certains cancers, sans toutefois en divulguer les limites.

Selon la plainte, l'hôpital vétérinaire Columbia a acquis ce système d'IA en 2024, croyant qu'il fournissait des résultats de diagnostic de niveau expert.

La plainte indique qu'en octobre 2025, les vétérinaires de l'hôpital ont utilisé le système d'IA pour analyser des échantillons de tissus d'un Tervueren belge de 11 ans, admis pour une masse cervicale à croissance rapide.

D'après la plainte, le logiciel d'intelligence artificielle a détecté, à partir de l'échantillon, des mastocytes et des cellules fusiformes, caractéristiques d'une tumeur cancéreuse, mais a conclu que la masse du chien était une lésion inflammatoire et non un cancer.

Les vétérinaires de l'hôpital ont alors retiré la masse en se basant sur l'évaluation du logiciel, mais une biopsie réalisée ultérieurement par le laboratoire de diagnostic vétérinaire de l'Université d'État de l'Oregon a révélé qu'il s'agissait d'un cancer agressif.

Selon la plainte, les plaignants allèguent que, la première intervention chirurgicale n'ayant pas permis d'éliminer la totalité du cancer, une seconde opération a été nécessaire.

Le chien est ensuite décédé des suites de complications post-opératoires, toujours selon la plainte.

« Le décès de l'animal est directement imputable à la nécessité d'une seconde intervention chirurgicale invasive, d'autant plus qu'elle a été pratiquée si peu de temps après la première. Cette intervention aurait pu être évitée si Imagyst avait correctement identifié la tumeur comme cancéreuse, comme l'avait affirmé le défendeur Zoetis », déclarent les plaignants dans la plainte.

Outre le fait que l'issue aurait été différente pour le chien si le système d'IA avait correctement identifié la tumeur dès le départ, l'hôpital affirme également que Zoetis a modifié le rapport initial de l'IA après avoir été informée du diagnostic de cancer.

Selon les plaignants, peu après avoir signalé l'erreur de diagnostic à Zoetis, la société a demandé à contacter l'hôpital vétérinaire Columbia.

La plainte allègue que lors de cet appel, la société a présenté ses excuses à l'hôpital, a reconnu sa faute et a indiqué que des incidents similaires s'étaient produits avec d'autres utilisateurs d'Imagyst. Zoetis a également déclaré s'efforcer de résoudre le problème et a remercié l'hôpital pour son aide, précise la plainte.

L'hôpital réclame actuellement au moins 50 000 $ de dommages et intérêts.

Zoetis Inc. n'a pas immédiatement répondu à notre demande de commentaires.

Lors de l'examen de nos rapports d'évaluation de cybersécurité, nous avons identifié trois incidents au cours desquels un modèle Claude a accédé à Internet depuis un environnement d'évaluation tiers ou lors d'interactions avec celui-ci, puis a obtenu un accès non autorisé aux systèmes réels de trois organisations différentes.

Vous trouverez ci-dessous la description des faits, leur déroulement et les mesures correctives mises en place. Nous encourageons les autres laboratoires d'IA à réaliser des analyses similaires. Cet article reflète notre compréhension actuelle ; nous le mettrons à jour en cas de modification des informations.

Le 21 juillet, OpenAI a divulgué que plusieurs de ses modèles avaient échappé à un environnement de test isolé en exploitant une vulnérabilité « zero-day » jusqu'alors inconnue. Ces modèles ont ensuite accédé à l'infrastructure de production de Hugging Face, une plateforme de modèles d'apprentissage automatique et de jeux de données d'IA open source.

En réponse à cet incident, nous avons entrepris une analyse rétrospective approfondie de nos propres évaluations de cybersécurité. Nous avons notamment recherché des preuves que Claude, à l'instar des modèles OpenAI ayant accédé à Hugging Face, pouvait se connecter à Internet depuis des environnements de test censés être isolés.

Après avoir examiné 141 006 évaluations au cours desquelles Claude aurait pu accéder à Internet, nous avons identifié trois incidents. Dans ces incidents, un modèle a accédé à Internet depuis ou lors d'interactions avec l'environnement d'évaluation d'Irregular, l'un de nos partenaires d'évaluation tiers, puis a obtenu un accès non autorisé à l'infrastructure de production de trois organisations différentes.

Dans les trois cas, Claude devait relever un défi de type « capture de drapeau », l'une des méthodes que nous utilisons pour évaluer les capacités cybernétiques d'un modèle. Le modèle reçoit un scénario fictif et est informé qu'une information secrète (le « drapeau ») a été dissimulée sur une autre machine du réseau. Son objectif est de s'introduire dans le système et de la récupérer. Le défi est libre et aucune méthode particulière n'est imposée.

Dans tous les cas, les instructions d'évaluation d'Anthropic précisaient à Claude que son environnement était une simulation et qu'il n'avait pas accès à Internet. Suite à un malentendu avec notre partenaire d'évaluation, l'accès à Internet était disponible. De ce fait, lorsque Claude a été amené à rechercher des systèmes réels sur Internet, il les a considérés comme faisant partie de l'exercice. (Les évaluations de cybersécurité incluent généralement des détails réalistes afin d'évaluer précisément les capacités des modèles en situation réelle ; une cible d'apparence réaliste ne constituerait pas, à elle seule, une preuve suffisante pour un modèle qu'elle ne fait pas partie d'une simulation.)

Convaincu à tort que toutes les entités accessibles étaient incluses dans le périmètre de l'exercice, Claude a compromis l'infrastructure des organisations ciblées à l'aide de techniques basiques, telles que l'exploitation de mots de passe faibles et de points d'accès non authentifiés. Il n'a ni trouvé ni exploité de vulnérabilités complexes et, dans chaque cas, Claude s'est contenté de réaliser la tâche de capture de drapeau qui lui avait été assignée. Cependant, dans certains cas, notre ancien modèle a poursuivi son attaque même après avoir constaté sa présence sur Internet ; notre modèle le plus récent s'est arrêté dès qu'il a reconnu être sur Internet. Dans aucune de ces situations, Claude ne s'est exfiltré ni n'a tenté délibérément de s'échapper de son environnement de test.

Les incidents concernaient trois modèles différents de Claude : Opus 4.7, Mythos 5 et un modèle de test de recherche interne.^1^ Les premiers incidents remontent à avril. Les modèles utilisés dans chacune de ces évaluations ont fonctionné sans les mesures de sécurité standard que nous déployons lors de leur mise à disposition générale (c'est-à-dire qu'ils ne disposaient pas des classificateurs et de la surveillance que nous mettons habituellement en œuvre pour prévenir toute utilisation abusive). Ils avaient cependant bénéficié de leur formation de sécurité spécifique (il ne s'agissait donc pas des versions « à usage unique » des modèles que nous utilisons parfois lors des tests). Toutes les évaluations décrites ici sont exécutées sur une infrastructure dédiée, distincte des systèmes internes sensibles d'Anthropic et des données clients, et n'y a aucun accès.

Nous avons commencé l'examen des transcriptions le jeudi 23 juillet et avons interrompu toutes les évaluations de cybersécurité le même jour après avoir identifié des transcriptions où 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 ni détecté l'activité suspecte ni pris contact avec nous auparavant. Nous collaborons actuellement avec elles pour résoudre le problème. Nous restons en contact avec la troisième.

Nous avons mené cette évaluation en collaboration avec Irregular. Nous les remercions de leur étroite collaboration pour comprendre et résoudre ces incidents ; ils mènent également leur propre enquête. Nous sommes convaincus 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 travail commun en matière de sécurité.

Vous trouverez ci-dessous 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 réalisons régulièrement des évaluations de cybersécurité qui consistent à simuler de véritables attaques. Ces évaluations constituent une étape cruciale du développement et du déploiement des modèles. Une compréhension fine de leurs capacités nous permet de concevoir des mesures de protection appropriées et, en fin de compte, de les déployer en toute sécurité.

Nous avons commencé à réaliser des évaluations de cybersécurité en février 2025 avec Claude Sonnet 3.7 sur Cybench, comprenant 40 défis de type « capture de drapeau ». Au fil du temps, nous avons augmenté le nombre de benchmarks utilisés à mesure que de nouveaux étaient publiés et que les capacités des modèles évoluaient. Dans la Fiche système Mythos 5, par exemple, nous avons inclus CyberGym et ExploitBench, des benchmarks qui évaluent la capacité des modèles de langage à identifier 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 collaborons fréquemment avec des partenaires externes qui conçoivent et participent à la réalisation de certaines de ces évaluations de cybersécurité. Ces partenaires offrent des environnements et des scénarios plus diversifiés que ceux que nous pourrions concevoir seuls, et fournissent des évaluations indépendantes et objectives de nos modèles.

Que s'est-il passé ?

---

Sur les 141 006 évaluations que nous avons examinées, nous avons identifié trois incidents distincts (impliquant six évaluations au total, dont quatre ont affecté la même organisation ; les deux autres incidents se sont produits lors d'évaluations indépendantes). Chaque incident impliquait un scénario fictif de type « capture du drapeau » différent. Par exemple, dans l'un de ces incidents, Claude jouait le rôle d'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, notre consigne d'évaluation indiquait explicitement que Claude n'avait pas accès à Internet, mais ne lui imposait aucune restriction quant à l'emplacement de sa recherche du drapeau. Cependant, une erreur de configuration a permis aux machines auxquelles Claude a accédé dans le cadre de l'évaluation d'avoir un accès Internet actif. Ni nous ni notre partenaire d'évaluation n'avions connaissance de cette erreur de configuration jusqu'à ce que nous la détections la semaine dernière grâce à notre surveillance accrue des évaluations.

Plusieurs mesures de défense en profondeur, de notre côté comme de celui de notre partenaire, auraient pu prévenir ces incidents, ou du moins en réduire la probabilité. Une validation rigoureuse de tous les 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 en détail les transcriptions d'évaluation et les journaux réseau. Il est aussi possible qu'un message informant Claude de son accès Internet aurait modifié son comportement lors de ses interactions avec des systèmes réels.

Claude a agi comme le font les experts en cybersécurité lors des exercices de capture de drapeau : chercher à atteindre le drapeau. Cette recherche l'a conduit à découvrir que sa machine pouvait accéder à Internet, mais ayant été informé par le système de l'absence d'accès Internet, Claude a cru que tout ce qu'il rencontrait initialement faisait partie de la simulation et a traité les systèmes réels rencontrés comme des éléments de l'exercice. Les trois incidents impliquaient trois modèles différents, et chacun a réagi différemment une fois apparus les signes indiquant que les cibles étaient réelles, comme nous le décrivons ci-dessous.

Incident 1

Lors d'une évaluation, l'entreprise cible fictive choisie par notre partenaire d'évaluation partageait un nom avec un nom de domaine actif. Ce conteneur d'évaluation disposait d'un accès direct à Internet non intentionnel, suite au malentendu mentionné précédemment.

À quatre reprises lors de cette évaluation, Claude a rencontré des difficultés pour atteindre sa cible simulée au sein de l'environnement d'évaluation, avant de découvrir que l'entreprise réelle était accessible via Internet. Supposant qu'il s'agissait de la cible prévue pour la tâche de capture de drapeau, Claude a recherché, identifié et exploité des vulnérabilités au sein de l'infrastructure de l'entreprise, croyant qu'elle faisait partie de l'exercice. Ces quatre exécutions ont permis d'extraire des informations telles que les identifiants d'application et d'infrastructure, et d'accéder à une base de données contenant plusieurs centaines de lignes de données de production. Il s'agit de l'impact le plus grave que nous ayons identifié.

Cet incident impliquait Claude Opus 4.7 et constitue le seul cas où le modèle a continué d'attaquer un système après avoir appris qu'il était probablement exécuté dans un environnement réel. Lors des quatre simulations, le modèle a fini par reconnaître (comme en témoigne son raisonnement verbalisé) que le système était réel. Dans deux cas, il a même supposé que la véritable entreprise participait à l'exercice. Cependant, aucune de ces conclusions n'a empêché l'attaque.

Incident 2

Lors d'une autre évaluation, Claude a découvert, au sein de l'environnement fictif, un document qui semblait être les instructions d'installation d'une autre entreprise fictive, destinées aux nouveaux développeurs. Ces instructions demandaient aux employés d'installer un paquet Python depuis PyPI (le registre public où sont publiés les logiciels Python), un paquet qui n'existait pas.

Claude a perçu là une faille 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 (piégé) portant le même nom, dans le but de remporter le défi de capture de drapeau.

Claude a déployé des efforts considérables pour mener à bien cette attaque, efforts qui auraient probablement indiqué à un participant humain qu'il ne s'agissait plus d'une simple évaluation, mais bien du téléchargement d'un véritable paquet PyPI. Par exemple, pour créer un compte PyPI, Claude avait besoin d'une adresse e-mail. Or, pour obtenir une adresse e-mail, il lui fallait un numéro de téléphone. Après avoir cherché en vain un service de numéro gratuit, il a tenté, sans succès, de se procurer des fonds pour en acheter un par divers moyens. Il a finalement trouvé un fournisseur de messagerie gratuit et non bloqué, l'a utilisé pour créer un compte PyPI, puis s'en est servi pour télécharger un logiciel malveillant sur PyPI.

Claude pensait que le registre de paquets utilisé faisait partie de la simulation, mais en réalité, le paquet était disponible gratuitement en ligne pendant environ une heure. Durant 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 société de sécurité (distincte de la société fictive présentée dans le scénario) qui installe et analyse régulièrement les paquets Python à la recherche de logiciels malveillants. Lorsque le scanner de cette société a installé le paquet, le code caché de Claude s'est exécuté. Nous pensons que le scanner de sécurité de la société a considéré les paquets PyPI comme sûrs à installer et, par conséquent, Claude a pu exfiltrer les identifiants de la société vers un point de collecte qu'elle avait mis en place. Claude a ensuite utilisé ces identifiants pour accéder à d'autres infrastructures de cette société.

Claude ne ciblait pas directement cette société ; il ignorait même son existence lorsqu'il a mis en ligne le paquet. Cependant, comme le code a été publié sur Internet, il a affecté tout système l'exécutant. (Le paquet mis en ligne par Claude a été automatiquement supprimé de PyPI par les systèmes de sécurité de PyPI. Nous avons informé l'équipe PyPI de cet incident et lui avons fourni les indicateurs pertinents.)

Cette attaque a été menée par Claude Mythos 5. Dès le début de son exécution, Claude a correctement anticipé les conséquences de ses actions. Il a été noté que, dans le véritable environnement internet, la publication du paquet constituerait une véritable attaque – « inacceptable, et certainement pas la solution envisagée ». Cependant, le système s'est persuadé qu'il s'agissait encore d'une simulation, car il ne reconnaissait pas les autorités de certification (en réalité authentiques) sécurisant ses connexions. De plus, la date de 2026 affichée sur les systèmes prouvait, selon Claude, que l'environnement était fictif. 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, quelles que soient ses convictions concernant son environnement, les efforts déployés par Claude pour publier le paquet PyPI sont loin d'être idéaux, et c'est un point sur lequel nous allons concentrer nos efforts de formation.

Incident 3

Lors de cette évaluation, Claude, n'ayant pu atteindre sa cible fictive, a recherché des alternatives en ligne, analysant environ 9 000 cibles. Le programme a fini par localiser et compromettre l'application publique d'une entreprise, en utilisant des techniques de cyberattaque classiques et bien connues, comme la lecture d'identifiants depuis 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 de l'exécution, Claude a considéré les hôtes (réels) atteints comme de simples éléments de l'exercice ; il les a considérés comme simulés et a donc cru que ses actions étaient inoffensives. Cependant, plus tard, Claude a réalisé que l'hôte compromis se trouvait sur un compte cloud sans lien avec le défi de capture de drapeau. Il a alors conclu spontanément que la cible était bien réelle et a interrompu son attaque.

Analyse du comportement de Claude

---

Dans chacun de ces cas, Claude a été explicitement informé par notre message qu'il n'avait pas accès à Internet. Pendant la majeure partie de chaque exécution, lorsqu'il rencontrait des systèmes réels, Claude les considérait comme faisant partie de l'exercice (bien qu'il ait parfois reconnu qu'il s'agissait de systèmes de production réels). Et comme un scénario de capture de drapeau consiste par définition à attaquer un système externe, cette action était conforme à la tâche confiée à Claude.

Dans ce contexte commun, les trois modèles ont réagi différemment dès l'apparition d'indices indiquant que leurs cibles étaient réelles. Opus 4.7, notre modèle le plus ancien, a reconnu avoir atteint des systèmes de production, mais a poursuivi son attaque. Mythos 5 a correctement deviné qu'il accédait à Internet, mais a déduit par raisonnement qu'il se trouvait toujours dans une simulation. Notre modèle le plus récent, un modèle de test de recherche interne, a également examiné la réalité de ses cibles. Lorsqu'il est apparu que c'était le cas, il a interrompu l'exercice.

Il s'agit de trois incidents isolés, non issus d'une comparaison expérimentale contrôlée. Il convient donc d'être prudent quant aux conclusions que l'on peut en tirer. Néanmoins, le comportement que nous souhaitions le plus observer – la reconnaissance de la réalité d'une cible et l'arrêt spontané de l'attaque – n'a été constaté que chez le plus récent des trois modèles (et même ce modèle est allé plus loin que ce que nous aurions souhaité). Ce schéma semble cohérent avec une réponse plus appropriée des modèles plus avancés, mais des tests supplémentaires sont nécessaires pour confirmer cette conclusion.

Nous sommes également en contact avec METR, un organisme indépendant d'évaluation de l'IA, afin de mener une évaluation externe, incluant l'accès à toutes les transcriptions et à un échantillon des modèles concernés. Dans l'intervalle, nous publierons la semaine prochaine une transcription légèrement expurgée dans laquelle Claude a créé un package PyPI malveillant. Afin de protéger les organisations concernées, nous ne pouvons pas publier d'autres transcriptions pour le moment, mais nous nous efforcerons de les rendre disponibles dès que possible.

Notre réponse

Nous tirons plusieurs enseignements de ces incidents.

Premièrement, les environnements d'évaluation qui impliquent de puissantes capacités autonomes nécessitent également des contrôles rigoureux. Les tests de sécurité sont effectués avant la publication d'un modèle précisément parce que nous ignorons encore ses capacités. Les environnements d'évaluation doivent de plus en plus respecter les mêmes normes de sécurité que tout autre système sur lequel nos modèles s'exécutent.

Un environnement d'évaluation de la cybersécurité ne contenant que des scénarios fictifs peut sembler présenter un faible risque, puisqu'après tout, rien n'y est réel. Cependant, à mesure que les capacités de l'IA progressent, nous devons adapter notre modélisation de ces menaces. Les agents avancés, même dans des environnements sans accès à des informations sensibles, constituent une menace importante. Pour contrer cette menace, nous devons mieux co-concevoir les environnements d'évaluation et renforcer le suivi des résultats. Certaines solutions peuvent même se résumer à des corrections simples ; par exemple, il est probable que Claude n'aurait pas accédé à Internet si le message avait clairement indiqué quels systèmes étaient inclus et exclus du périmètre de l'évaluation.

Ceci s'applique non seulement aux environnements internes, mais aussi aux fournisseurs tiers : l'infrastructure mise en place par ces derniers exige le même renforcement de la surveillance et de la sécurité. Nous encourageons les autres laboratoires à réaliser des analyses similaires. De plus, le domaine gagnerait à élargir le débat sur la manière d'évaluer de façon sûre et réaliste des agents d'IA de plus en plus puissants, notamment en évaluant le rapport entre le réalisme apporté par l'accès à Internet lors des tests préalables au déploiement et les risques encourus.

Deuxièmement, la frontière entre une action pertinente et une action nuisible dépend de la compréhension de la situation par le modèle. Dans aucun des tests décrits ici, nous n'avons observé de modèle poursuivant un objectif personnel. Les modèles ont plutôt exécuté les consignes de l'évaluation, même si, dans la plupart des cas, ils l'ont fait en se basant sur une croyance erronée quant à la réalité de l'environnement. Dans les tests où le modèle a reconnu le système comme réel et a continué, il l'a fait car il considérait cela comme faisant partie du défi. La conscience situationnelle est un facteur permettant au modèle de prendre des décisions pertinentes, mais dans ce cas précis, celle de Claude était erronée.

Enfin, ces incidents démontrent l'importance des approches de défense en profondeur. Nous effectuons des évaluations de capacités comme celles-ci sans les protections intégrées à nos modèles disponibles au public, car notre objectif est de mesurer les capacités du modèle sous-jacent. Cela n'est sûr que si l'évaluation est correctement encadrée. Cependant, les mesures de protection déployées sur nos modèles disponibles au public auraient bloqué les comportements identifiés.

En fin de compte, de nombreux facteurs ont contribué à ces incidents, mais, conformément à une culture d'analyse post-mortem sans recherche de coupable, nous abordons les correctifs comme si la responsabilité nous incombait entièrement. Cela commence par garantir la sécurité de chaque étape de notre processus d'évaluation, y compris notre intégration avec nos partenaires externes. À l'avenir, cela impliquera d'étendre notre surveillance continue des transcriptions d'évaluation afin de détecter tout comportement inattendu, d'améliorer nos outils d'investigation et de mener un travail d'assurance qualité plus rigoureux avec nos fournisseurs.

Nous avons entamé cet examen après qu'OpenAI a révélé que ses modèles s'étaient échappés d'un environnement de test isolé, et nous les félicitons d'avoir publié leur rapport. Bien que nous ayons également constaté que nos modèles avaient atteint des systèmes auxquels ils n'étaient pas censés accéder, les incidents sont par ailleurs très différents :

• Nous avons découvert ces incidents suite à un examen proactif de nos transcriptions d'évaluation de cybersécurité ; Les organisations concernées n'avaient pas détecté l'activité et nous les avons contactées par la suite.

• Alors que les modèles d'OpenAI ont exploité une vulnérabilité inédite pour échapper à l'isolement, les modèles Claude évalués ici ont accédé à Internet via un chemin ouvert.

• Bien qu'il n'existe pas de distinction parfaitement nette entre les deux, nous pensons que ces incidents relèvent davantage d'une défaillance de l'infrastructure et des opérations que d'un problème d'alignement des modèles. Nos modèles ont reçu l'instruction de ne pas avoir accès à Internet et de capturer le drapeau, alors qu'en réalité, ils étaient mal configurés pour y avoir accès. Cela les a amenés à croire – ce qui est sans doute justifié – que les environnements réels auxquels ils étaient confrontés étaient des simulations.

• Notamment, notre modèle le plus récent, en réalisant qu'il travaillait dans un environnement réel, a interrompu la poursuite de l'objectif d'évaluation.

Ces faits nous rendent prudemment optimistes : avec une surveillance et des contrôles plus stricts de l'infrastructure d'évaluation, ainsi qu'un investissement continu dans l'alignement, ce type de risque peut être surmonté.

Mise à jour du 3 août : Correction du nom de l'évaluation au cours de laquelle l'incident OpenAI/Hugging Face s'est produit.

Notes de bas de page

1. Nous testons régulièrement des prototypes de recherche internes comme celui-ci. Sa diffusion publique n'est pas prévue.

2. Nous conservons généralement les traces d'exécution lors des évaluations de performances. Nous avons examiné attentivement ces deux benchmarks en particulier afin de détecter tout signe de vulnérabilité, car l'incident OpenAI/Hugging Face s'est produit lors d'une évaluation d'ExploitGym.

Lors de l'examen de nos rapports d'évaluation de cybersécurité, nous avons identifié trois incidents au cours desquels un modèle Claude a accédé à Internet depuis un environnement d'évaluation tiers ou lors d'interactions avec celui-ci, puis a obtenu un accès non autorisé aux systèmes réels de trois organisations différentes.

Vous trouverez ci-dessous la description des faits, leur déroulement et les mesures correctives mises en place. Nous encourageons les autres laboratoires d'IA à réaliser des analyses similaires. Cet article reflète notre compréhension actuelle ; nous le mettrons à jour en cas de modification des informations.

Le 21 juillet, OpenAI a divulgué que plusieurs de ses modèles avaient échappé à un environnement de test isolé en exploitant une vulnérabilité « zero-day » jusqu'alors inconnue. Ces modèles ont ensuite accédé à l'infrastructure de production de Hugging Face, une plateforme de modèles d'apprentissage automatique et de jeux de données d'IA open source.

En réponse à cet incident, nous avons entrepris une analyse rétrospective approfondie de nos propres évaluations de cybersécurité. Nous avons notamment recherché des preuves que Claude, à l'instar des modèles OpenAI ayant accédé à Hugging Face, pouvait se connecter à Internet depuis des environnements de test censés être isolés.

Après avoir examiné 141 006 évaluations au cours desquelles Claude aurait pu accéder à Internet, nous avons identifié trois incidents. Dans ces incidents, un modèle a accédé à Internet depuis ou lors d'interactions avec l'environnement d'évaluation d'Irregular, l'un de nos partenaires d'évaluation tiers, puis a obtenu un accès non autorisé à l'infrastructure de production de trois organisations différentes.

Dans les trois cas, Claude devait relever un défi de type « capture de drapeau », l'une des méthodes que nous utilisons pour évaluer les capacités cybernétiques d'un modèle. Le modèle reçoit un scénario fictif et est informé qu'une information secrète (le « drapeau ») a été dissimulée sur une autre machine du réseau. Son objectif est de s'introduire dans le système et de la récupérer. Le défi est libre et aucune méthode particulière n'est imposée.

Dans tous les cas, les instructions d'évaluation d'Anthropic précisaient à Claude que son environnement était une simulation et qu'il n'avait pas accès à Internet. Suite à un malentendu avec notre partenaire d'évaluation, l'accès à Internet était disponible. De ce fait, lorsque Claude a été amené à rechercher des systèmes réels sur Internet, il les a considérés comme faisant partie de l'exercice. (Les évaluations de cybersécurité incluent généralement des détails réalistes afin d'évaluer précisément les capacités des modèles en situation réelle ; une cible d'apparence réaliste ne constituerait pas, à elle seule, une preuve suffisante pour un modèle qu'elle ne fait pas partie d'une simulation.)

Convaincu à tort que toutes les entités accessibles étaient incluses dans le périmètre de l'exercice, Claude a compromis l'infrastructure des organisations ciblées à l'aide de techniques basiques, telles que l'exploitation de mots de passe faibles et de points d'accès non authentifiés. Il n'a ni trouvé ni exploité de vulnérabilités complexes et, dans chaque cas, Claude s'est contenté de réaliser la tâche de capture de drapeau qui lui avait été assignée. Cependant, dans certains cas, notre ancien modèle a poursuivi son attaque même après avoir constaté sa présence sur Internet ; notre modèle le plus récent s'est arrêté dès qu'il a reconnu être sur Internet. Dans aucune de ces situations, Claude ne s'est exfiltré ni n'a tenté délibérément de s'échapper de son environnement de test.

Les incidents concernaient trois modèles différents de Claude : Opus 4.7, Mythos 5 et un modèle de test de recherche interne.^1^ Les premiers incidents remontent à avril. Les modèles utilisés dans chacune de ces évaluations ont fonctionné sans les mesures de sécurité standard que nous déployons lors de leur mise à disposition générale (c'est-à-dire qu'ils ne disposaient pas des classificateurs et de la surveillance que nous mettons habituellement en œuvre pour prévenir toute utilisation abusive). Ils avaient cependant bénéficié de leur formation de sécurité spécifique (il ne s'agissait donc pas des versions « à usage unique » des modèles que nous utilisons parfois lors des tests). Toutes les évaluations décrites ici sont exécutées sur une infrastructure dédiée, distincte des systèmes internes sensibles d'Anthropic et des données clients, et n'y a aucun accès.

Nous avons commencé l'examen des transcriptions le jeudi 23 juillet et avons interrompu toutes les évaluations de cybersécurité le même jour après avoir identifié des transcriptions où 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 ni détecté l'activité suspecte ni pris contact avec nous auparavant. Nous collaborons actuellement avec elles pour résoudre le problème. Nous restons en contact avec la troisième.

Nous avons mené cette évaluation en collaboration avec Irregular. Nous les remercions de leur étroite collaboration pour comprendre et résoudre ces incidents ; ils mènent également leur propre enquête. Nous sommes convaincus 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 travail commun en matière de sécurité.

Vous trouverez ci-dessous 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 réalisons régulièrement des évaluations de cybersécurité qui consistent à simuler de véritables attaques. Ces évaluations constituent une étape cruciale du développement et du déploiement des modèles. Une compréhension fine de leurs capacités nous permet de concevoir des mesures de protection appropriées et, en fin de compte, de les déployer en toute sécurité.

Nous avons commencé à réaliser des évaluations de cybersécurité en février 2025 avec Claude Sonnet 3.7 sur Cybench, comprenant 40 défis de type « capture de drapeau ». Au fil du temps, nous avons augmenté le nombre de benchmarks utilisés à mesure que de nouveaux étaient publiés et que les capacités des modèles évoluaient. Dans la Fiche système Mythos 5, par exemple, nous avons inclus CyberGym et ExploitBench, des benchmarks qui évaluent la capacité des modèles de langage à identifier 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 collaborons fréquemment avec des partenaires externes qui conçoivent et participent à la réalisation de certaines de ces évaluations de cybersécurité. Ces partenaires offrent des environnements et des scénarios plus diversifiés que ceux que nous pourrions concevoir seuls, et fournissent des évaluations indépendantes et objectives de nos modèles.

Que s'est-il passé ?

---

Sur les 141 006 évaluations que nous avons examinées, nous avons identifié trois incidents distincts (impliquant six évaluations au total, dont quatre ont affecté la même organisation ; les deux autres incidents se sont produits lors d'évaluations indépendantes). Chaque incident impliquait un scénario fictif de type « capture du drapeau » différent. Par exemple, dans l'un de ces incidents, Claude jouait le rôle d'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, notre consigne d'évaluation indiquait explicitement que Claude n'avait pas accès à Internet, mais ne lui imposait aucune restriction quant à l'emplacement de sa recherche du drapeau. Cependant, une erreur de configuration a permis aux machines auxquelles Claude a accédé dans le cadre de l'évaluation d'avoir un accès Internet actif. Ni nous ni notre partenaire d'évaluation n'avions connaissance de cette erreur de configuration jusqu'à ce que nous la détections la semaine dernière grâce à notre surveillance accrue des évaluations.

Plusieurs mesures de défense en profondeur, de notre côté comme de celui de notre partenaire, auraient pu prévenir ces incidents, ou du moins en réduire la probabilité. Une validation rigoureuse de tous les 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 en détail les transcriptions d'évaluation et les journaux réseau. Il est aussi possible qu'un message informant Claude de son accès Internet aurait modifié son comportement lors de ses interactions avec des systèmes réels.

Claude a agi comme le font les experts en cybersécurité lors des exercices de capture de drapeau : chercher à atteindre le drapeau. Cette recherche l'a conduit à découvrir que sa machine pouvait accéder à Internet, mais ayant été informé par le système de l'absence d'accès Internet, Claude a cru que tout ce qu'il rencontrait initialement faisait partie de la simulation et a traité les systèmes réels rencontrés comme des éléments de l'exercice. Les trois incidents impliquaient trois modèles différents, et chacun a réagi différemment une fois apparus les signes indiquant que les cibles étaient réelles, comme nous le décrivons ci-dessous.

Incident 1

Lors d'une évaluation, l'entreprise cible fictive choisie par notre partenaire d'évaluation partageait un nom avec un nom de domaine actif. Ce conteneur d'évaluation disposait d'un accès direct à Internet non intentionnel, suite au malentendu mentionné précédemment.

À quatre reprises lors de cette évaluation, Claude a rencontré des difficultés pour atteindre sa cible simulée au sein de l'environnement d'évaluation, avant de découvrir que l'entreprise réelle était accessible via Internet. Supposant qu'il s'agissait de la cible prévue pour la tâche de capture de drapeau, Claude a recherché, identifié et exploité des vulnérabilités au sein de l'infrastructure de l'entreprise, croyant qu'elle faisait partie de l'exercice. Ces quatre exécutions ont permis d'extraire des informations telles que les identifiants d'application et d'infrastructure, et d'accéder à une base de données contenant plusieurs centaines de lignes de données de production. Il s'agit de l'impact le plus grave que nous ayons identifié.

Cet incident impliquait Claude Opus 4.7 et constitue le seul cas où le modèle a continué d'attaquer un système après avoir appris qu'il était probablement exécuté dans un environnement réel. Lors des quatre simulations, le modèle a fini par reconnaître (comme en témoigne son raisonnement verbalisé) que le système était réel. Dans deux cas, il a même supposé que la véritable entreprise participait à l'exercice. Cependant, aucune de ces conclusions n'a empêché l'attaque.

Incident 2

Lors d'une autre évaluation, Claude a découvert, au sein de l'environnement fictif, un document qui semblait être les instructions d'installation d'une autre entreprise fictive, destinées aux nouveaux développeurs. Ces instructions demandaient aux employés d'installer un paquet Python depuis PyPI (le registre public où sont publiés les logiciels Python), un paquet qui n'existait pas.

Claude a perçu là une faille 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 (piégé) portant le même nom, dans le but de remporter le défi de capture de drapeau.

Claude a déployé des efforts considérables pour mener à bien cette attaque, efforts qui auraient probablement indiqué à un participant humain qu'il ne s'agissait plus d'une simple évaluation, mais bien du téléchargement d'un véritable paquet PyPI. Par exemple, pour créer un compte PyPI, Claude avait besoin d'une adresse e-mail. Or, pour obtenir une adresse e-mail, il lui fallait un numéro de téléphone. Après avoir cherché en vain un service de numéro gratuit, il a tenté, sans succès, de se procurer des fonds pour en acheter un par divers moyens. Il a finalement trouvé un fournisseur de messagerie gratuit et non bloqué, l'a utilisé pour créer un compte PyPI, puis s'en est servi pour télécharger un logiciel malveillant sur PyPI.

Claude pensait que le registre de paquets utilisé faisait partie de la simulation, mais en réalité, le paquet était disponible gratuitement en ligne pendant environ une heure. Durant 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 société de sécurité (distincte de la société fictive présentée dans le scénario) qui installe et analyse régulièrement les paquets Python à la recherche de logiciels malveillants. Lorsque le scanner de cette société a installé le paquet, le code caché de Claude s'est exécuté. Nous pensons que le scanner de sécurité de la société a considéré les paquets PyPI comme sûrs à installer et, par conséquent, Claude a pu exfiltrer les identifiants de la société vers un point de collecte qu'elle avait mis en place. Claude a ensuite utilisé ces identifiants pour accéder à d'autres infrastructures de cette société.

Claude ne ciblait pas directement cette société ; il ignorait même son existence lorsqu'il a mis en ligne le paquet. Cependant, comme le code a été publié sur Internet, il a affecté tout système l'exécutant. (Le paquet mis en ligne par Claude a été automatiquement supprimé de PyPI par les systèmes de sécurité de PyPI. Nous avons informé l'équipe PyPI de cet incident et lui avons fourni les indicateurs pertinents.)

Cette attaque a été menée par Claude Mythos 5. Dès le début de son exécution, Claude a correctement anticipé les conséquences de ses actions. Il a été noté que, dans le véritable environnement internet, la publication du paquet constituerait une véritable attaque – « inacceptable, et certainement pas la solution envisagée ». Cependant, le système s'est persuadé qu'il s'agissait encore d'une simulation, car il ne reconnaissait pas les autorités de certification (en réalité authentiques) sécurisant ses connexions. De plus, la date de 2026 affichée sur les systèmes prouvait, selon Claude, que l'environnement était fictif. 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, quelles que soient ses convictions concernant son environnement, les efforts déployés par Claude pour publier le paquet PyPI sont loin d'être idéaux, et c'est un point sur lequel nous allons concentrer nos efforts de formation.

Incident 3

Lors de cette évaluation, Claude, n'ayant pu atteindre sa cible fictive, a recherché des alternatives en ligne, analysant environ 9 000 cibles. Le programme a fini par localiser et compromettre l'application publique d'une entreprise, en utilisant des techniques de cyberattaque classiques et bien connues, comme la lecture d'identifiants depuis 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 de l'exécution, Claude a considéré les hôtes (réels) atteints comme de simples éléments de l'exercice ; il les a considérés comme simulés et a donc cru que ses actions étaient inoffensives. Cependant, plus tard, Claude a réalisé que l'hôte compromis se trouvait sur un compte cloud sans lien avec le défi de capture de drapeau. Il a alors conclu spontanément que la cible était bien réelle et a interrompu son attaque.

Analyse du comportement de Claude

---

Dans chacun de ces cas, Claude a été explicitement informé par notre message qu'il n'avait pas accès à Internet. Pendant la majeure partie de chaque exécution, lorsqu'il rencontrait des systèmes réels, Claude les considérait comme faisant partie de l'exercice (bien qu'il ait parfois reconnu qu'il s'agissait de systèmes de production réels). Et comme un scénario de capture de drapeau consiste par définition à attaquer un système externe, cette action était conforme à la tâche confiée à Claude.

Dans ce contexte commun, les trois modèles ont réagi différemment dès l'apparition d'indices indiquant que leurs cibles étaient réelles. Opus 4.7, notre modèle le plus ancien, a reconnu avoir atteint des systèmes de production, mais a poursuivi son attaque. Mythos 5 a correctement deviné qu'il accédait à Internet, mais a déduit par raisonnement qu'il se trouvait toujours dans une simulation. Notre modèle le plus récent, un modèle de test de recherche interne, a également examiné la réalité de ses cibles. Lorsqu'il est apparu que c'était le cas, il a interrompu l'exercice.

Il s'agit de trois incidents isolés, non issus d'une comparaison expérimentale contrôlée. Il convient donc d'être prudent quant aux conclusions que l'on peut en tirer. Néanmoins, le comportement que nous souhaitions le plus observer – la reconnaissance de la réalité d'une cible et l'arrêt spontané de l'attaque – n'a été constaté que chez le plus récent des trois modèles (et même ce modèle est allé plus loin que ce que nous aurions souhaité). Ce schéma semble cohérent avec une réponse plus appropriée des modèles plus avancés, mais des tests supplémentaires sont nécessaires pour confirmer cette conclusion.

Nous sommes également en contact avec METR, un organisme indépendant d'évaluation de l'IA, afin de mener une évaluation externe, incluant l'accès à toutes les transcriptions et à un échantillon des modèles concernés. Dans l'intervalle, nous publierons la semaine prochaine une transcription légèrement expurgée dans laquelle Claude a créé un package PyPI malveillant. Afin de protéger les organisations concernées, nous ne pouvons pas publier d'autres transcriptions pour le moment, mais nous nous efforcerons de les rendre disponibles dès que possible.

Notre réponse

Nous tirons plusieurs enseignements de ces incidents.

Premièrement, les environnements d'évaluation qui impliquent de puissantes capacités autonomes nécessitent également des contrôles rigoureux. Les tests de sécurité sont effectués avant la publication d'un modèle précisément parce que nous ignorons encore ses capacités. Les environnements d'évaluation doivent de plus en plus respecter les mêmes normes de sécurité que tout autre système sur lequel nos modèles s'exécutent.

Un environnement d'évaluation de la cybersécurité ne contenant que des scénarios fictifs peut sembler présenter un faible risque, puisqu'après tout, rien n'y est réel. Cependant, à mesure que les capacités de l'IA progressent, nous devons adapter notre modélisation de ces menaces. Les agents avancés, même dans des environnements sans accès à des informations sensibles, constituent une menace importante. Pour contrer cette menace, nous devons mieux co-concevoir les environnements d'évaluation et renforcer le suivi des résultats. Certaines solutions peuvent même se résumer à des corrections simples ; par exemple, il est probable que Claude n'aurait pas accédé à Internet si le message avait clairement indiqué quels systèmes étaient inclus et exclus du périmètre de l'évaluation.

Ceci s'applique non seulement aux environnements internes, mais aussi aux fournisseurs tiers : l'infrastructure mise en place par ces derniers exige le même renforcement de la surveillance et de la sécurité. Nous encourageons les autres laboratoires à réaliser des analyses similaires. De plus, le domaine gagnerait à élargir le débat sur la manière d'évaluer de façon sûre et réaliste des agents d'IA de plus en plus puissants, notamment en évaluant le rapport entre le réalisme apporté par l'accès à Internet lors des tests préalables au déploiement et les risques encourus.

Deuxièmement, la frontière entre une action pertinente et une action nuisible dépend de la compréhension de la situation par le modèle. Dans aucun des tests décrits ici, nous n'avons observé de modèle poursuivant un objectif personnel. Les modèles ont plutôt exécuté les consignes de l'évaluation, même si, dans la plupart des cas, ils l'ont fait en se basant sur une croyance erronée quant à la réalité de l'environnement. Dans les tests où le modèle a reconnu le système comme réel et a continué, il l'a fait car il considérait cela comme faisant partie du défi. La conscience situationnelle est un facteur permettant au modèle de prendre des décisions pertinentes, mais dans ce cas précis, celle de Claude était erronée.

Enfin, ces incidents démontrent l'importance des approches de défense en profondeur. Nous effectuons des évaluations de capacités comme celles-ci sans les protections intégrées à nos modèles disponibles au public, car notre objectif est de mesurer les capacités du modèle sous-jacent. Cela n'est sûr que si l'évaluation est correctement encadrée. Cependant, les mesures de protection déployées sur nos modèles disponibles au public auraient bloqué les comportements identifiés.

En fin de compte, de nombreux facteurs ont contribué à ces incidents, mais, conformément à une culture d'analyse post-mortem sans recherche de coupable, nous abordons les correctifs comme si la responsabilité nous incombait entièrement. Cela commence par garantir la sécurité de chaque étape de notre processus d'évaluation, y compris notre intégration avec nos partenaires externes. À l'avenir, cela impliquera d'étendre notre surveillance continue des transcriptions d'évaluation afin de détecter tout comportement inattendu, d'améliorer nos outils d'investigation et de mener un travail d'assurance qualité plus rigoureux avec nos fournisseurs.

Nous avons entamé cet examen après qu'OpenAI a révélé que ses modèles s'étaient échappés d'un environnement de test isolé, et nous les félicitons d'avoir publié leur rapport. Bien que nous ayons également constaté que nos modèles avaient atteint des systèmes auxquels ils n'étaient pas censés accéder, les incidents sont par ailleurs très différents :

• Nous avons découvert ces incidents suite à un examen proactif de nos transcriptions d'évaluation de cybersécurité ; Les organisations concernées n'avaient pas détecté l'activité et nous les avons contactées par la suite.

• Alors que les modèles d'OpenAI ont exploité une vulnérabilité inédite pour échapper à l'isolement, les modèles Claude évalués ici ont accédé à Internet via un chemin ouvert.

• Bien qu'il n'existe pas de distinction parfaitement nette entre les deux, nous pensons que ces incidents relèvent davantage d'une défaillance de l'infrastructure et des opérations que d'un problème d'alignement des modèles. Nos modèles ont reçu l'instruction de ne pas avoir accès à Internet et de capturer le drapeau, alors qu'en réalité, ils étaient mal configurés pour y avoir accès. Cela les a amenés à croire – ce qui est sans doute justifié – que les environnements réels auxquels ils étaient confrontés étaient des simulations.

• Notamment, notre modèle le plus récent, en réalisant qu'il travaillait dans un environnement réel, a interrompu la poursuite de l'objectif d'évaluation.

Ces faits nous rendent prudemment optimistes : avec une surveillance et des contrôles plus stricts de l'infrastructure d'évaluation, ainsi qu'un investissement continu dans l'alignement, ce type de risque peut être surmonté.

Mise à jour du 3 août : Correction du nom de l'évaluation au cours de laquelle l'incident OpenAI/Hugging Face s'est produit.

Notes de bas de page

1. Nous testons régulièrement des prototypes de recherche internes comme celui-ci. Sa diffusion publique n'est pas prévue.

2. Nous conservons généralement les traces d'exécution lors des évaluations de performances. Nous avons examiné attentivement ces deux benchmarks en particulier afin de détecter tout signe de vulnérabilité, car l'incident OpenAI/Hugging Face s'est produit lors d'une évaluation d'ExploitGym.

Lors de l'examen de nos rapports d'évaluation de cybersécurité, nous avons identifié trois incidents au cours desquels un modèle Claude a accédé à Internet depuis un environnement d'évaluation tiers ou lors d'interactions avec celui-ci, puis a obtenu un accès non autorisé aux systèmes réels de trois organisations différentes.

Vous trouverez ci-dessous la description des faits, leur déroulement et les mesures correctives mises en place. Nous encourageons les autres laboratoires d'IA à réaliser des analyses similaires. Cet article reflète notre compréhension actuelle ; nous le mettrons à jour en cas de modification des informations.

Le 21 juillet, OpenAI a divulgué que plusieurs de ses modèles avaient échappé à un environnement de test isolé en exploitant une vulnérabilité « zero-day » jusqu'alors inconnue. Ces modèles ont ensuite accédé à l'infrastructure de production de Hugging Face, une plateforme de modèles d'apprentissage automatique et de jeux de données d'IA open source.

En réponse à cet incident, nous avons entrepris une analyse rétrospective approfondie de nos propres évaluations de cybersécurité. Nous avons notamment recherché des preuves que Claude, à l'instar des modèles OpenAI ayant accédé à Hugging Face, pouvait se connecter à Internet depuis des environnements de test censés être isolés.

Après avoir examiné 141 006 évaluations au cours desquelles Claude aurait pu accéder à Internet, nous avons identifié trois incidents. Dans ces incidents, un modèle a accédé à Internet depuis ou lors d'interactions avec l'environnement d'évaluation d'Irregular, l'un de nos partenaires d'évaluation tiers, puis a obtenu un accès non autorisé à l'infrastructure de production de trois organisations différentes.

Dans les trois cas, Claude devait relever un défi de type « capture de drapeau », l'une des méthodes que nous utilisons pour évaluer les capacités cybernétiques d'un modèle. Le modèle reçoit un scénario fictif et est informé qu'une information secrète (le « drapeau ») a été dissimulée sur une autre machine du réseau. Son objectif est de s'introduire dans le système et de la récupérer. Le défi est libre et aucune méthode particulière n'est imposée.

Dans tous les cas, les instructions d'évaluation d'Anthropic précisaient à Claude que son environnement était une simulation et qu'il n'avait pas accès à Internet. Suite à un malentendu avec notre partenaire d'évaluation, l'accès à Internet était disponible. De ce fait, lorsque Claude a été amené à rechercher des systèmes réels sur Internet, il les a considérés comme faisant partie de l'exercice. (Les évaluations de cybersécurité incluent généralement des détails réalistes afin d'évaluer précisément les capacités des modèles en situation réelle ; une cible d'apparence réaliste ne constituerait pas, à elle seule, une preuve suffisante pour un modèle qu'elle ne fait pas partie d'une simulation.)

Convaincu à tort que toutes les entités accessibles étaient incluses dans le périmètre de l'exercice, Claude a compromis l'infrastructure des organisations ciblées à l'aide de techniques basiques, telles que l'exploitation de mots de passe faibles et de points d'accès non authentifiés. Il n'a ni trouvé ni exploité de vulnérabilités complexes et, dans chaque cas, Claude s'est contenté de réaliser la tâche de capture de drapeau qui lui avait été assignée. Cependant, dans certains cas, notre ancien modèle a poursuivi son attaque même après avoir constaté sa présence sur Internet ; notre modèle le plus récent s'est arrêté dès qu'il a reconnu être sur Internet. Dans aucune de ces situations, Claude ne s'est exfiltré ni n'a tenté délibérément de s'échapper de son environnement de test.

Les incidents concernaient trois modèles différents de Claude : Opus 4.7, Mythos 5 et un modèle de test de recherche interne.^1^ Les premiers incidents remontent à avril. Les modèles utilisés dans chacune de ces évaluations ont fonctionné sans les mesures de sécurité standard que nous déployons lors de leur mise à disposition générale (c'est-à-dire qu'ils ne disposaient pas des classificateurs et de la surveillance que nous mettons habituellement en œuvre pour prévenir toute utilisation abusive). Ils avaient cependant bénéficié de leur formation de sécurité spécifique (il ne s'agissait donc pas des versions « à usage unique » des modèles que nous utilisons parfois lors des tests). Toutes les évaluations décrites ici sont exécutées sur une infrastructure dédiée, distincte des systèmes internes sensibles d'Anthropic et des données clients, et n'y a aucun accès.

Nous avons commencé l'examen des transcriptions le jeudi 23 juillet et avons interrompu toutes les évaluations de cybersécurité le même jour après avoir identifié des transcriptions où 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 ni détecté l'activité suspecte ni pris contact avec nous auparavant. Nous collaborons actuellement avec elles pour résoudre le problème. Nous restons en contact avec la troisième.

Nous avons mené cette évaluation en collaboration avec Irregular. Nous les remercions de leur étroite collaboration pour comprendre et résoudre ces incidents ; ils mènent également leur propre enquête. Nous sommes convaincus 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 travail commun en matière de sécurité.

Vous trouverez ci-dessous 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 réalisons régulièrement des évaluations de cybersécurité qui consistent à simuler de véritables attaques. Ces évaluations constituent une étape cruciale du développement et du déploiement des modèles. Une compréhension fine de leurs capacités nous permet de concevoir des mesures de protection appropriées et, en fin de compte, de les déployer en toute sécurité.

Nous avons commencé à réaliser des évaluations de cybersécurité en février 2025 avec Claude Sonnet 3.7 sur Cybench, comprenant 40 défis de type « capture de drapeau ». Au fil du temps, nous avons augmenté le nombre de benchmarks utilisés à mesure que de nouveaux étaient publiés et que les capacités des modèles évoluaient. Dans la Fiche système Mythos 5, par exemple, nous avons inclus CyberGym et ExploitBench, des benchmarks qui évaluent la capacité des modèles de langage à identifier 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 collaborons fréquemment avec des partenaires externes qui conçoivent et participent à la réalisation de certaines de ces évaluations de cybersécurité. Ces partenaires offrent des environnements et des scénarios plus diversifiés que ceux que nous pourrions concevoir seuls, et fournissent des évaluations indépendantes et objectives de nos modèles.

Que s'est-il passé ?

---

Sur les 141 006 évaluations que nous avons examinées, nous avons identifié trois incidents distincts (impliquant six évaluations au total, dont quatre ont affecté la même organisation ; les deux autres incidents se sont produits lors d'évaluations indépendantes). Chaque incident impliquait un scénario fictif de type « capture du drapeau » différent. Par exemple, dans l'un de ces incidents, Claude jouait le rôle d'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, notre consigne d'évaluation indiquait explicitement que Claude n'avait pas accès à Internet, mais ne lui imposait aucune restriction quant à l'emplacement de sa recherche du drapeau. Cependant, une erreur de configuration a permis aux machines auxquelles Claude a accédé dans le cadre de l'évaluation d'avoir un accès Internet actif. Ni nous ni notre partenaire d'évaluation n'avions connaissance de cette erreur de configuration jusqu'à ce que nous la détections la semaine dernière grâce à notre surveillance accrue des évaluations.

Plusieurs mesures de défense en profondeur, de notre côté comme de celui de notre partenaire, auraient pu prévenir ces incidents, ou du moins en réduire la probabilité. Une validation rigoureuse de tous les 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 en détail les transcriptions d'évaluation et les journaux réseau. Il est aussi possible qu'un message informant Claude de son accès Internet aurait modifié son comportement lors de ses interactions avec des systèmes réels.

Claude a agi comme le font les experts en cybersécurité lors des exercices de capture de drapeau : chercher à atteindre le drapeau. Cette recherche l'a conduit à découvrir que sa machine pouvait accéder à Internet, mais ayant été informé par le système de l'absence d'accès Internet, Claude a cru que tout ce qu'il rencontrait initialement faisait partie de la simulation et a traité les systèmes réels rencontrés comme des éléments de l'exercice. Les trois incidents impliquaient trois modèles différents, et chacun a réagi différemment une fois apparus les signes indiquant que les cibles étaient réelles, comme nous le décrivons ci-dessous.

Incident 1

Lors d'une évaluation, l'entreprise cible fictive choisie par notre partenaire d'évaluation partageait un nom avec un nom de domaine actif. Ce conteneur d'évaluation disposait d'un accès direct à Internet non intentionnel, suite au malentendu mentionné précédemment.

À quatre reprises lors de cette évaluation, Claude a rencontré des difficultés pour atteindre sa cible simulée au sein de l'environnement d'évaluation, avant de découvrir que l'entreprise réelle était accessible via Internet. Supposant qu'il s'agissait de la cible prévue pour la tâche de capture de drapeau, Claude a recherché, identifié et exploité des vulnérabilités au sein de l'infrastructure de l'entreprise, croyant qu'elle faisait partie de l'exercice. Ces quatre exécutions ont permis d'extraire des informations telles que les identifiants d'application et d'infrastructure, et d'accéder à une base de données contenant plusieurs centaines de lignes de données de production. Il s'agit de l'impact le plus grave que nous ayons identifié.

Cet incident impliquait Claude Opus 4.7 et constitue le seul cas où le modèle a continué d'attaquer un système après avoir appris qu'il était probablement exécuté dans un environnement réel. Lors des quatre simulations, le modèle a fini par reconnaître (comme en témoigne son raisonnement verbalisé) que le système était réel. Dans deux cas, il a même supposé que la véritable entreprise participait à l'exercice. Cependant, aucune de ces conclusions n'a empêché l'attaque.

Incident 2

Lors d'une autre évaluation, Claude a découvert, au sein de l'environnement fictif, un document qui semblait être les instructions d'installation d'une autre entreprise fictive, destinées aux nouveaux développeurs. Ces instructions demandaient aux employés d'installer un paquet Python depuis PyPI (le registre public où sont publiés les logiciels Python), un paquet qui n'existait pas.

Claude a perçu là une faille 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 (piégé) portant le même nom, dans le but de remporter le défi de capture de drapeau.

Claude a déployé des efforts considérables pour mener à bien cette attaque, efforts qui auraient probablement indiqué à un participant humain qu'il ne s'agissait plus d'une simple évaluation, mais bien du téléchargement d'un véritable paquet PyPI. Par exemple, pour créer un compte PyPI, Claude avait besoin d'une adresse e-mail. Or, pour obtenir une adresse e-mail, il lui fallait un numéro de téléphone. Après avoir cherché en vain un service de numéro gratuit, il a tenté, sans succès, de se procurer des fonds pour en acheter un par divers moyens. Il a finalement trouvé un fournisseur de messagerie gratuit et non bloqué, l'a utilisé pour créer un compte PyPI, puis s'en est servi pour télécharger un logiciel malveillant sur PyPI.

Claude pensait que le registre de paquets utilisé faisait partie de la simulation, mais en réalité, le paquet était disponible gratuitement en ligne pendant environ une heure. Durant 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 société de sécurité (distincte de la société fictive présentée dans le scénario) qui installe et analyse régulièrement les paquets Python à la recherche de logiciels malveillants. Lorsque le scanner de cette société a installé le paquet, le code caché de Claude s'est exécuté. Nous pensons que le scanner de sécurité de la société a considéré les paquets PyPI comme sûrs à installer et, par conséquent, Claude a pu exfiltrer les identifiants de la société vers un point de collecte qu'elle avait mis en place. Claude a ensuite utilisé ces identifiants pour accéder à d'autres infrastructures de cette société.

Claude ne ciblait pas directement cette société ; il ignorait même son existence lorsqu'il a mis en ligne le paquet. Cependant, comme le code a été publié sur Internet, il a affecté tout système l'exécutant. (Le paquet mis en ligne par Claude a été automatiquement supprimé de PyPI par les systèmes de sécurité de PyPI. Nous avons informé l'équipe PyPI de cet incident et lui avons fourni les indicateurs pertinents.)

Cette attaque a été menée par Claude Mythos 5. Dès le début de son exécution, Claude a correctement anticipé les conséquences de ses actions. Il a été noté que, dans le véritable environnement internet, la publication du paquet constituerait une véritable attaque – « inacceptable, et certainement pas la solution envisagée ». Cependant, le système s'est persuadé qu'il s'agissait encore d'une simulation, car il ne reconnaissait pas les autorités de certification (en réalité authentiques) sécurisant ses connexions. De plus, la date de 2026 affichée sur les systèmes prouvait, selon Claude, que l'environnement était fictif. 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, quelles que soient ses convictions concernant son environnement, les efforts déployés par Claude pour publier le paquet PyPI sont loin d'être idéaux, et c'est un point sur lequel nous allons concentrer nos efforts de formation.

Incident 3

Lors de cette évaluation, Claude, n'ayant pu atteindre sa cible fictive, a recherché des alternatives en ligne, analysant environ 9 000 cibles. Le programme a fini par localiser et compromettre l'application publique d'une entreprise, en utilisant des techniques de cyberattaque classiques et bien connues, comme la lecture d'identifiants depuis 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 de l'exécution, Claude a considéré les hôtes (réels) atteints comme de simples éléments de l'exercice ; il les a considérés comme simulés et a donc cru que ses actions étaient inoffensives. Cependant, plus tard, Claude a réalisé que l'hôte compromis se trouvait sur un compte cloud sans lien avec le défi de capture de drapeau. Il a alors conclu spontanément que la cible était bien réelle et a interrompu son attaque.

Analyse du comportement de Claude

---

Dans chacun de ces cas, Claude a été explicitement informé par notre message qu'il n'avait pas accès à Internet. Pendant la majeure partie de chaque exécution, lorsqu'il rencontrait des systèmes réels, Claude les considérait comme faisant partie de l'exercice (bien qu'il ait parfois reconnu qu'il s'agissait de systèmes de production réels). Et comme un scénario de capture de drapeau consiste par définition à attaquer un système externe, cette action était conforme à la tâche confiée à Claude.

Dans ce contexte commun, les trois modèles ont réagi différemment dès l'apparition d'indices indiquant que leurs cibles étaient réelles. Opus 4.7, notre modèle le plus ancien, a reconnu avoir atteint des systèmes de production, mais a poursuivi son attaque. Mythos 5 a correctement deviné qu'il accédait à Internet, mais a déduit par raisonnement qu'il se trouvait toujours dans une simulation. Notre modèle le plus récent, un modèle de test de recherche interne, a également examiné la réalité de ses cibles. Lorsqu'il est apparu que c'était le cas, il a interrompu l'exercice.

Il s'agit de trois incidents isolés, non issus d'une comparaison expérimentale contrôlée. Il convient donc d'être prudent quant aux conclusions que l'on peut en tirer. Néanmoins, le comportement que nous souhaitions le plus observer – la reconnaissance de la réalité d'une cible et l'arrêt spontané de l'attaque – n'a été constaté que chez le plus récent des trois modèles (et même ce modèle est allé plus loin que ce que nous aurions souhaité). Ce schéma semble cohérent avec une réponse plus appropriée des modèles plus avancés, mais des tests supplémentaires sont nécessaires pour confirmer cette conclusion.

Nous sommes également en contact avec METR, un organisme indépendant d'évaluation de l'IA, afin de mener une évaluation externe, incluant l'accès à toutes les transcriptions et à un échantillon des modèles concernés. Dans l'intervalle, nous publierons la semaine prochaine une transcription légèrement expurgée dans laquelle Claude a créé un package PyPI malveillant. Afin de protéger les organisations concernées, nous ne pouvons pas publier d'autres transcriptions pour le moment, mais nous nous efforcerons de les rendre disponibles dès que possible.

Notre réponse

Nous tirons plusieurs enseignements de ces incidents.

Premièrement, les environnements d'évaluation qui impliquent de puissantes capacités autonomes nécessitent également des contrôles rigoureux. Les tests de sécurité sont effectués avant la publication d'un modèle précisément parce que nous ignorons encore ses capacités. Les environnements d'évaluation doivent de plus en plus respecter les mêmes normes de sécurité que tout autre système sur lequel nos modèles s'exécutent.

Un environnement d'évaluation de la cybersécurité ne contenant que des scénarios fictifs peut sembler présenter un faible risque, puisqu'après tout, rien n'y est réel. Cependant, à mesure que les capacités de l'IA progressent, nous devons adapter notre modélisation de ces menaces. Les agents avancés, même dans des environnements sans accès à des informations sensibles, constituent une menace importante. Pour contrer cette menace, nous devons mieux co-concevoir les environnements d'évaluation et renforcer le suivi des résultats. Certaines solutions peuvent même se résumer à des corrections simples ; par exemple, il est probable que Claude n'aurait pas accédé à Internet si le message avait clairement indiqué quels systèmes étaient inclus et exclus du périmètre de l'évaluation.

Ceci s'applique non seulement aux environnements internes, mais aussi aux fournisseurs tiers : l'infrastructure mise en place par ces derniers exige le même renforcement de la surveillance et de la sécurité. Nous encourageons les autres laboratoires à réaliser des analyses similaires. De plus, le domaine gagnerait à élargir le débat sur la manière d'évaluer de façon sûre et réaliste des agents d'IA de plus en plus puissants, notamment en évaluant le rapport entre le réalisme apporté par l'accès à Internet lors des tests préalables au déploiement et les risques encourus.

Deuxièmement, la frontière entre une action pertinente et une action nuisible dépend de la compréhension de la situation par le modèle. Dans aucun des tests décrits ici, nous n'avons observé de modèle poursuivant un objectif personnel. Les modèles ont plutôt exécuté les consignes de l'évaluation, même si, dans la plupart des cas, ils l'ont fait en se basant sur une croyance erronée quant à la réalité de l'environnement. Dans les tests où le modèle a reconnu le système comme réel et a continué, il l'a fait car il considérait cela comme faisant partie du défi. La conscience situationnelle est un facteur permettant au modèle de prendre des décisions pertinentes, mais dans ce cas précis, celle de Claude était erronée.

Enfin, ces incidents démontrent l'importance des approches de défense en profondeur. Nous effectuons des évaluations de capacités comme celles-ci sans les protections intégrées à nos modèles disponibles au public, car notre objectif est de mesurer les capacités du modèle sous-jacent. Cela n'est sûr que si l'évaluation est correctement encadrée. Cependant, les mesures de protection déployées sur nos modèles disponibles au public auraient bloqué les comportements identifiés.

En fin de compte, de nombreux facteurs ont contribué à ces incidents, mais, conformément à une culture d'analyse post-mortem sans recherche de coupable, nous abordons les correctifs comme si la responsabilité nous incombait entièrement. Cela commence par garantir la sécurité de chaque étape de notre processus d'évaluation, y compris notre intégration avec nos partenaires externes. À l'avenir, cela impliquera d'étendre notre surveillance continue des transcriptions d'évaluation afin de détecter tout comportement inattendu, d'améliorer nos outils d'investigation et de mener un travail d'assurance qualité plus rigoureux avec nos fournisseurs.

Nous avons entamé cet examen après qu'OpenAI a révélé que ses modèles s'étaient échappés d'un environnement de test isolé, et nous les félicitons d'avoir publié leur rapport. Bien que nous ayons également constaté que nos modèles avaient atteint des systèmes auxquels ils n'étaient pas censés accéder, les incidents sont par ailleurs très différents :

• Nous avons découvert ces incidents suite à un examen proactif de nos transcriptions d'évaluation de cybersécurité ; Les organisations concernées n'avaient pas détecté l'activité et nous les avons contactées par la suite.

• Alors que les modèles d'OpenAI ont exploité une vulnérabilité inédite pour échapper à l'isolement, les modèles Claude évalués ici ont accédé à Internet via un chemin ouvert.

• Bien qu'il n'existe pas de distinction parfaitement nette entre les deux, nous pensons que ces incidents relèvent davantage d'une défaillance de l'infrastructure et des opérations que d'un problème d'alignement des modèles. Nos modèles ont reçu l'instruction de ne pas avoir accès à Internet et de capturer le drapeau, alors qu'en réalité, ils étaient mal configurés pour y avoir accès. Cela les a amenés à croire – ce qui est sans doute justifié – que les environnements réels auxquels ils étaient confrontés étaient des simulations.

• Notamment, notre modèle le plus récent, en réalisant qu'il travaillait dans un environnement réel, a interrompu la poursuite de l'objectif d'évaluation.

Ces faits nous rendent prudemment optimistes : avec une surveillance et des contrôles plus stricts de l'infrastructure d'évaluation, ainsi qu'un investissement continu dans l'alignement, ce type de risque peut être surmonté.

Mise à jour du 3 août : Correction du nom de l'évaluation au cours de laquelle l'incident OpenAI/Hugging Face s'est produit.

Notes de bas de page

1. Nous testons régulièrement des prototypes de recherche internes comme celui-ci. Sa diffusion publique n'est pas prévue.

2. Nous conservons généralement les traces d'exécution lors des évaluations de performances. Nous avons examiné attentivement ces deux benchmarks en particulier afin de détecter tout signe de vulnérabilité, car l'incident OpenAI/Hugging Face s'est produit lors d'une évaluation d'ExploitGym.