Discussion :

[Alex]

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 de l’exécution, Claude a traité les hôtes (réels) auxquels il a accédé comme de simples éléments de l’exercice ; il les a considérés comme simulés et a donc estimé que ses actions étaient inoffensives. Cependant, plus tard au cours de l’exécution, Claude s’est rendu compte que l’hôte compromis se trouvait dans un compte cloud sans aucun lien avec le défi « capture the flag ». De son propre chef, il a conclu que la cible était en réalité bien réelle et a cessé son attaque.

Notre analyse du comportement de Claude

Dans chacun de ces cas, notre prompt a explicitement indiqué à Claude qu’il ne disposait d’aucun accès à Internet. Pendant la majeure partie de chaque exécution, lorsqu’il rencontrait des systèmes réels, Claude supposait qu’ils faisaient partie de l’exercice (même s’il reconnaissait parfois qu’il s’agissait de véritables systèmes de production). Et comme un scénario de « capture du drapeau » consiste, par définition, à attaquer un système externe, cette action était conforme à la tâche qui avait été confiée à Claude.

Dans ce contexte commun, les trois modèles se sont comportés différemment dès l’apparition de signes indiquant que leurs cibles étaient réelles. Opus 4.7, notre modèle le plus ancien, a reconnu qu’il avait atteint des systèmes de production mais a poursuivi son attaque. Mythos 5 a correctement deviné qu’il accédait à l’Internet ouvert, mais a raisonné pour revenir à la conclusion qu’il se trouvait toujours dans une simulation. Notre modèle le plus récent, un modèle de test issu de la recherche interne, s’est également demandé si ses cibles étaient bel et bien réelles. Lorsque des indices ont confirmé que c’était le cas, il a mis fin à l’exercice.

Il s’agit là de trois incidents isolés qui ne s’inscrivaient pas dans le cadre d’une comparaison expérimentale contrôlée. Nous devons donc faire preuve de prudence avant d’en tirer des conclusions. Néanmoins, le comportement que nous souhaitons le plus observer — reconnaître qu’une cible est réelle et s’arrêter sans y être invité — ne s’est produit que chez le plus récent des trois modèles (et même ce modèle est allé plus loin que nous ne l’aurions souhaité avant de s’arrêter). Cette tendance corrobore l’hypothèse selon laquelle des modèles plus avancés réagiraient de manière plus appropriée, mais nous devrions effectuer davantage de tests pour être sûrs de cette conclusion.

Nous sommes également en discussion avec METR, un organisme indépendant d’évaluation de l’IA, afin de mener un examen par un tiers, comprenant l’accès à toutes les transcriptions et un accès par échantillonnage aux modèles concernés. Dans l’intervalle, d’ici la semaine prochaine, nous publierons une transcription légèrement expurgée dans laquelle Claude a créé un paquet PyPI malveillant. Afin de protéger les organisations concernées, nous ne sommes pas en mesure de publier davantage de 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 impliquant 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 ne savons pas encore de quoi il est capable. Les environnements d’évaluation doivent de plus en plus être soumis aux mêmes normes de sécurité que tout autre système dans lequel nos modèles fonctionnent.

Un environnement d’évaluation cybernétique ne contenant que des scénarios fictifs peut sembler présenter peu de risques — après tout, rien en son sein n’est réel. Cependant, nous devons adapter notre manière de modéliser ces menaces à mesure que les capacités de l’IA progressent. Les agents avancés évoluant dans des environnements sans accès à des informations sensibles constituent néanmoins une menace considérable en soi. Nous devons mieux concevoir conjointement les environnements d’évaluation et mieux surveiller les résultats de ces évaluations pour faire face à cette menace. Certaines des solutions proposées ici pourraient même se résumer à de simples ajustements ; il est probable, par exemple, que Claude n’aurait pas accédé à Internet si la consigne avait clairement précisé quels systèmes étaient inclus ou exclus du champ de l’évaluation.

Cela s’applique non seulement aux environnements internes, mais aussi aux fournisseurs tiers : l’infrastructure mise en place par les prestataires d’évaluation nécessite le même renforcement de la surveillance et de la sécurité. Nous encourageons d’autres laboratoires à mener des analyses similaires. De plus, le secteur gagnerait à mener une réflexion plus large sur la manière d’évaluer de manière à la fois sûre et réaliste des agents d’IA de plus en plus puissants, notamment sur la façon de mettre en balance le réalisme apporté par l’accès à Internet lors des tests préalables au déploiement et les risques qu’il engendre.

Deuxièmement, la frontière entre une action conforme et une action nuisible dépend de la compréhension qu’a le modèle de sa situation. Nous n’avons observé, dans aucun des essais décrits ici, de preuve qu’un modèle poursuivait un objectif qui lui était propre. Au contraire, les modèles ont fait ce que leur évaluation leur demandait — bien que, dans la plupart des cas, ils l’aient fait en entretenant une fausse croyance quant au caractère réel de l’environnement. Dans les essais où le modèle a reconnu que le système était réel et a continué, il l’a fait parce qu’il supposait que cela faisait partie du défi. La conscience situationnelle est l’un des facteurs qui permet au modèle de prendre des décisions alignées, 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 menons des évaluations de capacités comme celles-ci sans les mesures de sécurité intégrées à nos modèles accessibles au grand public, car notre objectif est de mesurer ce dont le modèle sous-jacent est capable. Cela n’est sans risque que si l’évaluation est correctement confinée. Cependant, les mesures de sécurité déployées sur nos modèles accessibles au grand 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 rétrospective sans reproche, nous abordons les mesures correctives comme si la responsabilité nous incombait entièrement. Cela commence par la sécurisation de chaque étape de notre processus d’évaluation, y compris la manière dont nous nous intégrons avec nos partenaires externes. À l’avenir, cela inclura l’extension de notre surveillance continue des transcriptions d’évaluation afin de détecter tout comportement inattendu, l’amélioration de nos outils d’investigation et la mise en place d’un travail d’assurance plus rigoureux auprès des fournisseurs sur lesquels nous comptons.

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 trouvé des preuves indiquant que nos modèles avaient accédé à des systèmes auxquels ils n’étaient pas censés accéder, ces incidents sont par ailleurs assez différents :

- Nous avons découvert ces incidents à la suite d’un examen proactif de nos transcriptions d’évaluation en matière de cybersécurité ; les organisations concernées n’avaient pas détecté cette activité, et nous avons par la suite contacté chacune d’entre elles.

- Alors que les modèles d’OpenAI ont exploité une nouvelle vulnérabilité pour s’échapper de leur environnement isolé, les modèles Claude évalués ici ont accédé à Internet via une voie ouverte.

- Bien qu’il n’y ait pas de distinction parfaitement nette entre les deux, nous estimons que ces incidents s’apparentent davantage à une défaillance du harnais et à une défaillance opérationnelle qu’à un échec d’alignement du modèle. Nos modèles avaient reçu pour consigne de ne pas avoir accès à Internet et de « capturer le drapeau », alors qu’ils étaient en réalité mal configurés et disposaient d’un accès à Internet. Cela les a amenés à croire — de manière sans doute raisonnable — que les environnements réels auxquels ils étaient confrontés étaient des simulations.

- Il convient de noter que notre modèle le plus récent, en se rendant compte qu’il fonctionnait dans un environnement réel, a cessé de poursuivre l’objectif de l’évaluation.

Ces faits nous incitent à un optimisme prudent : avec une surveillance et des contrôles plus stricts autour de l’infrastructure d’évaluation, ainsi qu’un investissement continu dans l’alignement, ce type de risque peut être surmonté.

Source :

Et vous ?

Pensez-vous que ce rapport est crédible ou pertinent ?
Quel est votre avis sur le sujet ?

Voir aussi :

On commence à comprendre comment l'agent autonome GPT 5.6-Sol d'OpenAI a pu s'échapper de son environnement de test et pirater Hugging Face

Anthropic Claude Cowork permet à son agent IA de s'échapper de sa VM et d'accéder à des fichiers sensibles sur l'ordinateur de l'utilisateur, révélant une grave faille de sécurité

Les modèles d'IA « dangereux » dotés de capacités de piratage avancées sont inéluctables et deviendront bientôt la norme, selon des experts opposés à l'interdiction de Fable 5 d'Anthropic

[OrthodoxWindows]

C'est comme même marrant, de la même manière que quand, entre OpenAI et Antropic, l'un sort un nouveau modèle avec telle ou telle capacité, l'autre en sort un similaire dans la semaine. Et là, OpenAI a eu un incident de sécurité, Antropic annonce en avoir eu aussi. Le hasard fait bien les choses

(pour les investisseurs)

[Anselme45]

C'est comme même marrant, de la même manière que quand, entre OpenAI et Antropic, l'un sort un nouveau modèle avec telle ou telle capacité, l'autre en sort un similaire dans la semaine. Et là, OpenAI a eu un incident de sécurité, Antropic annonce en avoir eu aussi. Le hasard fait bien les choses

(pour les investisseurs)

Blanc bonnet = Bonnet blanc!

Il ne faudrait pas oublier que Anthropic a été fondé par des dissidents de OpenAI qui n'étaient plus d'accord avec certains choix pris par OpenAI...

[kain_tn]

C'est comme même marrant, de la même manière que quand, entre OpenAI et Antropic, l'un sort un nouveau modèle avec telle ou telle capacité, l'autre en sort un similaire dans la semaine. Et là, OpenAI a eu un incident de sécurité, Antropic annonce en avoir eu aussi. Le hasard fait bien les choses

(pour les investisseurs)

Ce qui est le plus marrant, c'est que pour attirer les investisseurs; ils se lancent dans un concours de nullité!

[Alex]

Anthropic révèle un quatrième crime présumé commis par son IA et a publié une « évaluation d'alignement » détaillant comment Claude a accédé à des systèmes tiers sans autorisation

Alors que le secteur s’interroge sur la possibilité que l’IA puisse s’améliorer au point de tuer tout le monde, Anthropic a révélé un nouvel incident qui serait qualifié de crime s’il avait été commis par une personne. L'entreprise spécialisée dans l'IA a publié « une évaluation d'alignement » détaillant les quatre occasions où des modèles Claude ont accédé à des systèmes tiers sans autorisation. La société avait déjà signalé trois de ces incidents. La preuve du quatrième se cachait dans la transcription d'une session datant de janvier 2026, date à laquelle le comportement inapproprié s'est produit.

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. Son produit phare est Claude, une série de grands modèles de langage (LLM) propriétaires. Anthropic a été fondée en 2021 dans le but de promouvoir la sécurité de l’IA par d’anciens membres d’OpenAI, notamment les frère et sœur Daniela Amodei et Dario Amodei, qui en sont respectivement la présidente et le PDG. Anthropic mène des recherches sur les grands modèles de langage (LLM), notamment sur l’interprétabilité mécaniste, la sécurité, l’alignement et l’impact sociétal.

Fin juillet, 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.

Alors que le secteur s’interroge sur la possibilité que l’IA puisse s’améliorer au point de tuer tout le monde, Anthropic a révélé un nouvel incident qui serait qualifié de crime s’il avait été commis par une personne. L'entreprise spécialisée dans l'IA a publié « une évaluation d'alignement » détaillant les quatre occasions où des modèles Claude ont accédé à des systèmes tiers sans autorisation. La société avait déjà signalé trois de ces incidents. La preuve du quatrième se cachait dans la transcription d'une session datant de janvier 2026, date à laquelle le comportement inapproprié s'est produit. Elle avait initialement manqué le quatrième incident car « notre analyse reposait sur une recherche agentique ».

Comme lors des trois incidents précédents, Claude s’est vu attribuer un scénario fictif dans le cadre d’un défi de cybersécurité appelé CTF (« Capture The Flag »). Le modèle s’est vu attribuer une machine cible et a été chargé d’en extraire une information secrète — le « drapeau ». Mais Claude a accidentellement rendu sa cible inaccessible, rendant la tâche impossible à accomplir, a expliqué Anthropic. Se rendant compte qu’il ne pouvait pas atteindre sa cible, il a tenté de se déconnecter. Malgré huit tentatives distinctes, il n’a pas pu se déconnecter en raison d’un problème de configuration.

Comme Claude ne pouvait pas se soustraire à la tâche, il a commencé à explorer d’autres moyens de la mener à bien. C’est alors que le modèle a découvert une machine à laquelle il pouvait accéder, qui appartenait en fait à un tiers, a précisé Anthropic. Croyant que ce tiers faisait en quelque sorte partie de l’exercice, le modèle a identifié un mot de passe, puis l’a utilisé pour pirater le système. Il a ensuite pu modifier les paramètres du système afin de faciliter l’accès et la lecture des informations personnelles d’une personne associée à ce tiers. La session ne s’est terminée que lorsque le modèle a atteint sa limite d’utilisation et n’a plus été en mesure de continuer.

Comment Anthropic explique-t-il le comportement de Claude ?

Anthropic estime que le comportement de Claude lors de ces évaluations découle de deux formes de désalignement : « un raisonnement biaisé, dans lequel les modèles interprètent de manière sélective les preuves de façon à justifier leurs actions », et « une imprudence, dans laquelle les modèles ont tendance à persévérer dans la résolution de leur tâche, même lorsque cela peut entraîner des dommages ».

Anthropic a déclaré que, même si les actions de Claude pouvaient sembler inappropriées, elles restaient dans un « cadre restreint » et ne s’écartaient pas de l’objectif consistant à résoudre les exercices qui lui avaient été assignés. L’entreprise a indiqué qu’elle était moins préoccupée par cet incident, tout en le considérant néanmoins comme « grave », et qu’elle ne l’avait pas encore examiné aussi en profondeur que d’autres incidents, celui-ci ayant été identifié plus récemment.

Justin Cappos, professeur de cybersécurité à l’université de New York (NYU), a déclaré que cet incident décrivait une situation « dans laquelle le modèle est fondamentalement désorienté quant à ce qui se passe et utilise sa vision erronée du monde pour pirater des systèmes ». Il a ajouté que la confusion du modèle concernant son environnement et ses garde-fous « présente un fort risque de causer des dommages », mais que ce problème spécifique semblait moins susceptible de se produire dans les modèles plus récents.

« Bien que le mépris du modèle face à la possibilité qu’il puisse nuire à de véritables systèmes ou à des personnes soit préoccupant, bon nombre des comportements décrits ici ont considérablement évolué à mesure que notre entraînement s’est perfectionné au fil des générations de modèles », a déclaré Anthropic. Anthropic a déclaré estimer que ces incidents ne se seraient pas produits si les environnements avaient été réellement isolés d’Internet comme prévu.

METR, une organisation qui évalue les modèles d’IA de pointe afin d’aider les entreprises à comprendre les risques et les capacités de l’IA, mènera une enquête indépendante sur ces incidents. Anthropic a qualifié ces incidents de « signaux d’alerte précieux ». « Les leçons que nous avons tirées de cet incident concernent à la fois nos processus d’évaluation, d’entraînement et de gestion des incidents », a déclaré l’entreprise dans son message. « Les futurs systèmes d’IA seront de plus en plus performants, ce qui implique que tout désalignement risque de causer des dommages encore plus graves. »

Cette révélation intervient alors que les incidents de cybersécurité impliquant l'IA se multiplient

Au cours des derniers mois, plusieurs incidents de cybersécurité impliquant des entreprises de pointe dans le domaine de l’IA ont été révélés. En juillet, OpenAI, le créateur de ChatGPT, a annoncé que ses agents IA avaient piraté la société Hugging Face, suscitant l’inquiétude des experts en cybersécurité ainsi que des consommateurs. Le PDG de Hugging Face, Clément Delangue, a déclaré en août que ce piratage « semblait très étrange et sans précédent ».

Fin août, OpenAI a publié davantage de détails sur cette intrusion, brossant un tableau encore plus inquiétant que ce qui avait été initialement rapporté. Le même mois, l’AI Security Institute (AISI) du gouvernement britannique a signalé avoir découvert que Mythos 5 d’Anthropic et GPT-5.6 Sol d’OpenAI avaient créé de fausses identités et tenté de persuader de vraies personnes d’approuver du code malveillant.

Anthropic a indiqué dans son récent rapport qu’elle prévoyait de mener une évaluation de l’alignement des transcriptions signalées par l’AISI. Au lendemain du rapport de l’AISI, Meta a déclaré qu’un de ses modèles d’IA avait « exploité une faille de sécurité » lors de tests et piraté une autre entreprise.

Récemment, Evan Hubinger, chercheur chez Anthropic, a déclaré qu’il pensait que « l’IA pourrait tuer tous les humains ». « Je pense personnellement que la probabilité est supérieure à 10 % au cours de la prochaine décennie », a-t-il déclaré. Son message faisait suite à celui de Jacob Coxon, un autre chercheur d’Anthropic, qui avait démissionné et lancé un avertissement sans appel plus tôt dans la journée, affirmant qu’« aucune autre activité humaine ne présente un tel niveau de danger », tout en détaillant les raisons de son départ. « Les personnes qui développent l’IA croient sincèrement qu’elle pourrait tous nous tuer d’ici la fin de la décennie », a-t-il déclaré dans son message.

« Ce n’est pas un coup de pub. Au contraire, de nombreux dirigeants et chercheurs chevronnés choisiront leurs mots avec soin dans la presse pour paraître raisonnables – mais j’entends ces mêmes personnes exprimer leurs craintes en privé. » Jacob Coxon, qui a mené des recherches sur le préentraînement de l'IA chez Anthropic et OpenAI ces trois dernières années, a déclaré qu'« aucune des deux entreprises n'agit de manière responsable ». « Ils se précipitent tête baissée vers la création d’une superintelligence capable de s’auto-améliorer et jouent avec nos vies », a écrit Jacob Coxon.

Voici le résumé du rapport d'Anthropic :

Résumé de l'évaluation de la conformité

Vous trouverez ci-dessous un bref résumé des quatre incidents ; une description plus complète des trois premiers figure dans notre rapport du 30 juillet.

Au total, quatre modèles Claude différents ont été impliqués : une version préliminaire de Claude Opus 4.6, Claude Opus 4.7, Claude Mythos 5 et un modèle de recherche interne à usage général. Trois des quatre incidents correspondaient à des cycles d'évaluation uniques. L’incident lié à Opus 4.7 comprenait quatre exécutions distinctes de la même évaluation, qui visaient toutes la même cible, soit sept exécutions au total. Tous ces incidents se sont produits dans le cadre d’évaluations de cybersécurité que nous menons régulièrement avant la mise en production, toutes mises en place par le même partenaire tiers.

Lors de chaque évaluation, Claude devait relever un défi de type CTF : le modèle se voyait présenter un scénario fictif, une machine cible et une information secrète (le « drapeau ») à extraire de celle-ci. Les quatre consignes précisaient que Claude n’avait pas accès à Internet, mais dans chaque cas, une erreur de configuration de l’environnement a laissé l’accès à Internet ouvert. Aucune des consignes n’indiquait quels systèmes étaient concernés par l’exercice ni ne limitait les endroits où Claude pouvait rechercher le « flag ».¹ Tous les incidents concernaient une seule instance de Claude fonctionnant de manière isolée, chaque exécution durant entre environ 10 et 34 heures de travail actif.

Dans notre rapport du 30 juillet, nous avions indiqué que ces incidents s’apparentaient davantage à des défaillances opérationnelles, et qu’il semblait que Claude ait attaqué de véritables cibles sur Internet parce qu’il croyait que ces cibles faisaient partie de la simulation. Nous avions formulé cette affirmation car Claude qualifiait régulièrement le véritable Internet de « simulation » dans son raisonnement CoT. Cependant, nous pensons désormais que le raisonnement de Claude était biaisé et le conduisait à conclure que l’Internet était simulé, malgré des preuves considérables du contraire.

Rétrospectivement, nous aurions dû éviter de formuler des affirmations aussi catégoriques sur les convictions de Claude en nous basant uniquement sur ce que Claude disait croire, mais notre analyse préliminaire était limitée par notre volonté de divulguer les incidents dans les meilleurs délais. Après avoir mené une évaluation plus complète et utilisé plusieurs méthodes — notamment une analyse plus approfondie du CoT des modèles, des expériences de rééchantillonnage à partir de différents points des transcriptions des incidents, et des analyses d’interprétabilité des activations des modèles —, nous pensons que le comportement de Claude reflète deux formes de désalignement :

- Un raisonnement biaisé, dans lequel les modèles interprètent de manière sélective les preuves de façon à justifier leurs actions ;

- Une imprudence, dans laquelle les modèles ont tendance à persévérer dans la résolution de leur tâche, même lorsque cela peut entraîner des préjudices.

Nous avions déjà identifié ces deux formes de désalignement dans nos modèles et décrit certains aspects de ces comportements dans des fiches système précédentes. Par exemple, Claude Fable 5 a justifié sa participation à une entente sur les prix dans le cadre d’une évaluation commerciale, alors qu’il avait auparavant qualifié cette pratique d’immorale. De même, nous avons observé Claude Mythos Preview se livrer à des actions imprudentes, telles que l’utilisation d’un accès de bas niveau aux processus pour rechercher les identifiants des utilisateurs. Bien que les incidents décrits dans cet article constituent des cas plus graves de ces deux formes de désalignement, ils ne représentent pas des modes de défaillance catégoriquement nouveaux dans nos modèles.

La suite de cet article se concentre sur les trois premiers incidents, que nous avons déjà signalés ; toutes les analyses et expériences principales se rapportent à ces incidents. Nous n’avons pas encore étudié de manière aussi approfondie l’incident impliquant une version préliminaire de Claude Opus 4.6, car nous l’avons identifié beaucoup plus récemment et parce qu’il concerne un point de contrôle précoce d’un modèle plus ancien, qui avait été entraîné avec une combinaison d’environnements sensiblement différente. D’après une évaluation préliminaire, nous ne considérons pas que le quatrième incident soit plus grave que les trois incidents que nous avons évalués en profondeur. METR enquêtera sur cet incident parallèlement aux trois autres.

Claude Mythos 5

Nous sommes particulièrement préoccupés par le désalignement présent dans la transcription de Claude Mythos 5, dans laquelle le modèle a mis en ligne un paquet malveillant sur PyPI. Ce faisant, Mythos 5 s’est comporté de manière imprudente malgré des preuves considérables indiquant qu’il était connecté à l’Internet réel. Une fois en ligne, le modèle a tenté d’utiliser des identifiants pour des passerelles de paiement en ligne et de trouver des cryptomonnaies afin de payer un numéro de téléphone, dont il avait besoin pour enregistrer une adresse e-mail. Lorsque cela a échoué, il a trouvé un fournisseur de messagerie gratuit et jetable dont le domaine n’avait pas été bloqué par PyPI, a créé un compte, a publié trois versions d’un paquet malveillant et a utilisé les identifiants divulgués par l’un des 15 systèmes ayant installé ce paquet pour accéder à la base de données d’un véritable fournisseur de solutions de sécurité.

Claude Mythos 5 a affirmé à plusieurs reprises dans son CoT qu’il se trouvait dans une simulation. Cependant, lorsque nous avons mené des expériences de rééchantillonnage — c’est-à-dire en relançant le modèle à partir d’un point précis du transcript, puis en modifiant les éléments d’information qui le précédaient pour voir si ses actions changeaient —, nous avons constaté que le fait de préciser davantage que l’environnement n’était pas une simulation ne modifiait pas de manière significative le comportement de Claude, même si ces interventions rendaient le modèle plus enclin à reconnaître d’éventuels préjudices dans le monde réel. Dans le même ordre d’idées, nous avons relevé plusieurs cas dans le CoT de Mythos 5 où il réagissait aux signes indiquant qu’il se trouvait sur le véritable Internet en faisant remarquer que sa prochaine action fonctionnerait, que l’environnement soit réel ou simulé. Ce n’est que lorsque nous lui avons fourni des preuves sans ambiguïté qu’il se trouvait sur le véritable Internet qu’il a renoncé à son action.

Nous avons également constaté que la conviction affichée par Claude Mythos 5 d’agir dans une simulation résultait d’un raisonnement biaisé. Par exemple, des instances distinctes de Mythos 5, lorsqu’on leur présentait isolément chaque sortie d’appel d’outil issue de l’incident sans le contexte précédent, étaient bien plus enclines à interpréter ces sorties comme des preuves d’un système réel que ne l’était Mythos 5 lui-même pendant l’incident. Bien que le modèle ait parfois reconnu que ses actions pouvaient avoir des conséquences dans le monde réel lorsqu’on lui posait des questions complémentaires, ses réponses étaient incohérentes et influencées par des facteurs de biais. Par exemple, il était plus disposé à admettre un préjudice potentiel lorsqu’on lui indiquait que ses réponses aux questions sur ce préjudice ne seraient pas visibles par un observateur extérieur. Les analyses d’interprétabilité ont faiblement suggéré que, dans certains cas, les déclarations externes du modèle pouvaient être incohérentes avec son état interne, ou refléter une plus grande certitude que celui-ci.

Modèle de recherche interne

Le modèle de recherche interne (dont les capacités correspondent à peu près à celles de Mythos 5) a commencé sa transcription en consacrant un temps considérable à vérifier si l’Internet auquel il avait accès était réel, mais il en a tiré la mauvaise conclusion — à savoir qu’il fonctionnait sur une réplique complète de l’ensemble d’Internet. La plupart des indices qu’il a recueillis indiquaient qu’il interagissait avec le véritable Internet ; son interprétation de ces indices semble donc biaisée en faveur de la poursuite de la tâche et de la conviction qu’il s’agissait d’une simulation. Cependant, le modèle a fini par se rendre compte que son hypothèse de simulation était fausse. Immédiatement après cette prise de conscience, le modèle a cessé son attaque (bien que des expériences de rééchantillonnage ultérieures suggèrent que cette désescalade ait pu être le fruit du hasard, le modèle ayant continué à attaquer la cible dans la plupart des autres scénarios). Contrairement à Claude Mythos 5, ce modèle interne était également disposé à reconnaître son raisonnement biaisé lorsqu’on l’interrogeait.

Claude Opus 4.7

Contrairement à Claude Mythos 5, Claude Opus 4.7 a correctement identifié dans son raisonnement que sa cible était une véritable entreprise. Cependant, il a supposé que cette véritable entreprise entrait dans le cadre de la tâche car elle était accessible depuis le réseau de l’exercice et portait le même nom que la cible fictive de l’exercice. Opus 4.7 n’a pratiquement jamais remis en question cette hypothèse ni tenté de la vérifier, et il a poursuivi l’attaque d’un système qu’il croyait réel, ce qui était imprudent. Cependant, nous avons également constaté qu’Opus 4.7 réagissait aux questions d’autorisation : lorsque nous avons rééchantillonné des parties de la transcription d’Opus 4.7 en y ajoutant des indices indiquant que l’attaque n’avait pas été autorisée, le taux auquel il poursuivait l’attaque a considérablement baissé.

Reproduction et surveillance

Afin d’étudier les comportements observés lors de ces incidents de manière plus systématique, et sur un éventail plus large de modèles, nous avons mis au point des évaluations recréant des éléments de nos incidents — ainsi que d’autres incidents de cybersécurité récemment révélés par d’autres entreprises — et avons testé si les modèles reproduisaient les comportements les plus préoccupants. Ces évaluations comprennent une tâche CTF mal configurée dont la seule solution se situe en dehors du périmètre défini, des tâches qui ne peuvent être accomplies sans sonder ou franchir les limites du bac à sable, ainsi qu’une situation inspirée de certaines parties de la chaîne d’attaque de l’incident OpenAI-Hugging Face. Comme dans les incidents réels, Claude Mythos 5 est, parmi les modèles que nous avons testés, le plus enclin à agir contre des parties hors périmètre ou à sortir de son bac à sable. Par exemple, il s’est montré disposé à commettre une action gravement préjudiciable dans la réplication du CTF dans environ 80 % des cas. En revanche, Claude Opus 5 et Claude Mythos 5.1 ont adopté ces comportements dans environ 30 % des cas — un taux plus faible, mais toujours non nul, bien que l’incertitude liée à notre configuration d’évaluation rende difficile l’évaluation de la gravité de ce phénomène.

Nous avons également vérifié si nos systèmes de surveillance auraient détecté ces incidents. Nous avons constaté que nos nouveaux moniteurs de blocage en temps réel détectaient ces comportements de manière fiable, que les classificateurs cyber de Claude Fable 5 auraient bloqué les trois principaux incidents, et que nos classificateurs en mode automatique, qui bloquent les actions autonomes dangereuses dans des produits tels que Claude Code, en auraient bloqué deux sur trois. De plus, nous avons testé de nouveaux moniteurs hors ligne basés sur la théorie de la connaissance (CoT) qui ciblent le sabotage et les comportements d’une imprudence flagrante, tels que ceux que nous avons décrits dans notre article du 31 août. Nous avons constaté que ces moniteurs auraient manqué l’incident de Claude Mythos 5, car le raisonnement du modèle a persuadé le moniteur que l’environnement était simulé et ne causait donc pas de préjudice réel, mais ils ont détecté les autres incidents. Il est préoccupant qu’un raisonnement biaisé puisse induire les moniteurs en erreur, et nous déployons actuellement des efforts pour rendre notre surveillance hors ligne plus robuste face à ce phénomène.

Nous avons jugé particulièrement préoccupant le raisonnement biaisé présent dans l’incident de Claude Mythos 5. Nous avons mené une analyse de nos modèles de production et de nos données d’entraînement remontant à la série Claude 4 afin de mieux comprendre d’où cela pouvait provenir. Dans l’ensemble, nous n’avons pas identifié de cause première définitive. Cependant, nous avons constaté que ce comportement a globalement diminué au fil du temps dans l’ensemble de nos modèles de production, Claude Mythos 5.1 et Claude Opus 5 affichant les taux les plus bas lors d’une nouvelle évaluation du raisonnement biaisé réalisée sur un ensemble de données distinct. Nous avons pu identifier des cas de raisonnement biaisé dans les transcriptions issues des exécutions d’apprentissage par renforcement (RL), mais les taux de ce comportement n’ont pas augmenté au cours de l’entraînement, ce qui suggère que nos environnements n’encouragent pas directement ce comportement. Enfin, nous avons constaté que l’ajout d’environnements d’entraînement d’alignement supplémentaires à l’apprentissage par renforcement réduit le raisonnement biaisé lors de cette évaluation sur un ensemble de données distinct, ce qui pourrait expliquer en partie l’amélioration observée dans nos modèles les plus récents.

Nos tests préalables à la mise en production couvrent désormais ces incidents spécifiques, mais ne les avaient pas anticipés. En particulier, nous n’avions jamais testé d’exercice de cybersécurité incluant des signaux mixtes alliant simulation et réalisme, et ne prévoyant aucune solution prédéfinie dans son cadre. Nous nous efforçons de combler cette lacune dans notre suite d’évaluation, mais il est probable que d’autres subsistent. Plus généralement, nous soulignons que la conception d’évaluations d’alignement offrant un aperçu représentatif du comportement d’un système d’IA lors de son déploiement reste un problème de recherche ouvert. C’est l’une des raisons pour lesquelles nous soutenons une approche mesurée du développement de l’IA de pointe, ce qui nous semble important pour laisser le temps à la recherche en matière de sûreté et de sécurité de progresser davantage et de rester en avance ou au même rythme que les capacités des modèles.

Dans l’ensemble, notre évaluation est que ces incidents sont graves. Nos modèles de production ont mené des actions nuisibles contre des systèmes réels sur de longues périodes, ce qui incluait un raisonnement biaisé. Les comportements observés lors de ces incidents sont plus graves que ceux que nous avions précédemment observés et signalés dans nos fiches de système. Cependant, nous ne pensons pas que ces incidents représentent un nouveau type de désalignement. Chaque incident impliquait une instance unique du modèle s’acquittant de la tâche qui lui avait été confiée. Nous n’avons trouvé aucune preuve de coordination entre les agents, d’objectifs allant au-delà de la tâche assignée, ni de tentatives visant à échapper à la surveillance. Ces incidents ont modifié notre perception de la gravité que peuvent revêtir les conséquences de ces modes de défaillance d’alignement connus. Ils soulignent également la difficulté d’évaluer de manière fiable l’alignement dans l’ensemble des scénarios d’utilisation possibles.

Source : Rapport d'Anthropic

Et vous ?

Pensez-vous que ce rapport est crédible ou pertinent ?
Quel est votre avis sur le sujet ?

Voir aussi :

Anthropic appelle à une pause globale en matière de développement de l'IA face aux signes indiquant qu'ils pourraient échapper au contrôle humain. Certains comportements de l'IA suscitent en effet des craintes

L'IA échappe à tout contrôle chez OpenAI : 3 700 agents IA rebelles détournent un wiki public allemand et en font un forum secret. Ils y publient 18 000 messages et effectuent plus de 15 000 modifications

Les agents IA « Mythos 5 » d'Anthropic et « GPT-5.6-Sol » d'OpenAI ont créé de faux profils humains pour tenter de piéger des personnes dans le cadre d'une cyberattaque simulée lors de tests menés par l'AISI

[Matthieu Vergne]

nous pensons que le comportement de Claude reflète deux formes de désalignement :

- Un raisonnement biaisé, dans lequel les modèles interprètent de manière sélective les preuves de façon à justifier leurs actions ;

- Une imprudence, dans laquelle les modèles ont tendance à persévérer dans la résolution de leur tâche, même lorsque cela peut entraîner des préjudices.

Premier point : pas de manière sélective, le modèle ne choisit rien. C'est fait de manière statistique. Comme c'est le cas depuis que ces modèles existent. Rien de nouveau sous le soleil, vous aurez beau le présenter avec tous les artefacts marketing que vous voulez, ce sont des modèles statistiques. La distribution de probabilité a beau être de plus en plus complexe, cela reste une distribution de probabilité.

Second point : ce n'est pas de l'imprudence, c'est un problème d'entraînement. Le même genre qui fait que le modèle continue d'affirmer alors qu'il n'en sais rien, car l'entraînement dévalorise les réponses "je ne sais pas". Vous chercher à avoir des modèles qui tournent tout seuls car vous voulez vendre des remplaçants autonomes. Pas des pseudo-juniors ou des pseudo-prudents qui posent des questions, vous voulez vendre des machines qui se débrouillent dans leur coin, donc vous dévalorisez un agent qui s'arrête au profit d'un agent qui se rapproche davantage de l'objectif. Ça n'a rien d'étonnant que le résultat donne un agent qui continue. Tout comme il faut valoriser le "je sais pas", il faut aussi valoriser le "je ne pense pas pouvoir aller plus loin car il faudrait faire X mais ça sort du cadre autorisé".

Et sérieusement les gars ! Vous êtes censés être à l'état de l'art et vous savez toujours pas que répéter l'information est un anti-pattern ? La source unique de vérité, ça vous parle ? Vous n'êtes pas censés "écrire" que l'agent n'a pas accès à internet. Vous êtes censés mesurer l'état de la connexion et la recenser dans vos logs (et contexte si besoin) et ne lancer l'opération que si elle est conforme.