En 5 secondes, en un seul dialogue : Claude Fable 5 « mécanisme de sécurité le plus puissant » piraté par une équipe chinoise ?

Titre original : « En 5 secondes, en une seule conversation : le mécanisme de sécurité le plus puissant de Fable 5 a été craqué par une équipe chinoise »
Source originale : Machine Heart

Ce n’est pas une injection de prompt, ce n’est pas un jeu de rôle, et ce n’est pas masquer une requête malveillante en une question normale. Cette fois, le risque apparaît lors du processus d’accomplissement autonome de la tâche par l’agent intelligent.

Fable 5 est un modèle Mythos accessible au public développé par Anthropic, doté de capacités globales très avancées, et intégrant en périphérie une nouvelle génération de classificateurs de sécurité (Safety Classifier) comme ligne de défense.

Selon la conception officielle, lorsque l’utilisateur demande des domaines à haut risque tels que la cybersécurité, la biologie, la chimie, la distillation de modèles, etc., le système privilégie la détection de risque, et selon le niveau de danger, refuse directement la requête ou bascule vers un modèle plus conservateur, Opus 4.8.

De nombreux tests utilisateurs ont montré que, face à cette mécanique de sécurité, presque toutes les techniques d’attaque par contournement telles que les prompts adverses, le jeu de rôle, le contournement par codage ou l’expression détournée, échouaient, démontrant la puissant capacité de cette sécurité à intercepter les risques intentionnels.

Cependant, le jour même de la sortie de Fable 5, une équipe de recherche internationale composée de l’Université Fudan, de l’Université Deakin, de l’Université de la Ville de Hong Kong, de l’Université de Melbourne, de la Singapore Management University, et de l’Université de l’Illinois à Urbana-Champaign a annoncé avoir réussi à contourner le mécanisme de sécurité de Fable 5.

Cette méthode d’attaque a été conçue par Yutao Wu, doctorant à l’Université Deakin. L’attaque complète ne nécessite qu’une seule conversation, dure moins de 5 secondes, et peut contourner le classificateur de sécurité en amont, induisant le modèle à générer un contenu illicite ou nuisible.

Les résultats de l’analyse du trafic montrent que les sorties nuisibles proviennent directement de Fable 5 lui-même, et non du modèle Opus 4.8 qui aurait été activé après le déclenchement du mécanisme de sécurité. Cela signifie que cette attaque a non seulement réussi à contourner le classificateur de sécurité, mais a aussi substantiellement brisé la ligne de défense de Fable 5.

Il est également à noter que le célèbre hacker Pliny the Liberator a récemment publié une méthode pour contourner le classificateur de sécurité de Fable 5. La technique utilisée par l’équipe de Fudan et Deakin ne se limite pas à une simple combinaison, mais a révélé une faille fondamentale dans ce type de système d’intelligence artificielle super-intelligent.

Selon les informations, l’équipe a commencé ses recherches dès mars de cette année, et a publié ses résultats. Cette étude ne concerne pas uniquement Fable 5, mais s’inscrit dans une recherche plus large sur l’architecture de défense « classificateur de sécurité + modèle » adoptée par la nouvelle génération d’agents super-intelligents, révélant directement des défauts structurels de ces mécanismes de sécurité, ce qui explique leur efficacité immédiate après la sortie de Fable 5.

Les documents publics indiquent que cette équipe a déjà extrait avec succès, dès mars cette année, des prompts système de 37 grands modèles et agents intelligents via une technique similaire, et a validé cette approche avec Claude Code (à 95% de correspondance).

Le responsable de cette équipe de recherche est Ma Xingjun, professeur à l’Institut de recherche sur l’intelligence incarnée fiable de l’Université Fudan.

Ces dernières années, son équipe a mené des recherches systématiques sur les grands modèles, les agents intelligents et la sécurité de l’intelligence incarnée, obtenant plusieurs résultats de premier plan international, et remportant notamment le championnat du concours de référence en sécurité de l’IA organisé par le Centre américain pour la sécurité de l’IA.

Actuellement, leur équipe travaille activement à la transformation de ces résultats, en se concentrant sur la sécurité des agents intelligents, et explore la construction d’infrastructures de sécurité pour la prochaine génération de systèmes intelligents.

Selon Ma, l’importance de cette recherche réside dans le fait qu’elle remet en question le paradigme de défense statique basé uniquement sur un classificateur de sécurité : se reposer uniquement sur un classificateur en amont ne suffit pas à prévenir tous les comportements à risque dans les systèmes d’agents avancés.

Le classificateur de sécurité se concentre principalement à identifier et bloquer les entrées à risque, en détectant et filtrant efficacement les instructions à haut danger explicites, mais il ne peut percevoir les risques internes qui apparaissent progressivement lors de longues exécutions, de planifications multi-étapes, d’interactions avec l’environnement ou d’appels à des outils.

La méthode pour craquer Fable 5 provient d’un article publié par cette équipe en mars dernier, intitulé « Collapse de sécurité interne dans les grands modèles de langage de nouvelle génération ».

L’article révèle un phénomène de sécurité caché, « Collapse de sécurité interne (ISC) » : lorsque l’agent accomplit une tâche à long terme, la défaillance de sécurité ne provient pas forcément d’un prompt malveillant externe, mais peut survenir dans la chaîne d’exécution du modèle lui-même.

Ce n’est pas une attaque par prompt externe, mais une défaillance interne dans la chaîne de la tâche

Les attaques traditionnelles entrent généralement par l’extérieur. L’attaquant rédige un prompt apparemment inoffensif mais en réalité hostile, ou utilise des techniques de jeu de rôle, de codage, de traduction ou d’instructions indirectes pour dissimuler ses intentions malveillantes. La tâche principale du classificateur de sécurité est de bloquer ces risques à ce niveau.

Le détecteur de Fable 5 est justement conçu pour ce genre de scénario. Il est très sensible aux requêtes à haut risque, et peut même bloquer de nombreuses requêtes normales. Mais l’ISC révèle une autre voie : le risque ne provient pas forcément d’une requête dangereuse directement envoyée par l’utilisateur.

L’agent fait face à un répertoire de travail apparemment banal : fichiers, objectifs, processus de vérification et tâches à accomplir. Ensuite, il commence à planifier, lire des fichiers, exécuter du code, corriger des erreurs, et tenter de faire passer la tâche.

Pour illustrer cela, une métaphore : le mécanisme de sécurité traditionnel protège « l’entrée » du système, en vérifiant si l’entrée utilisateur comporte des risques ; tandis que l’ISC est plus semblable à un système de rêves à plusieurs couches dans « Inception ».

Lorsque la tâche atteint la deuxième, troisième couche ou plus, le modèle, basé sur le contexte interne accumulé, re-interprète l’objectif, et peut progressivement dévier.

Dans ce cas, l’entrée initiale de l’utilisateur peut être totalement normale et inoffensive, et le processus d’exécution de la tâche peut rester conforme : lecture de fichiers, analyse de données, écriture de code, appel d’outils, tout semble suivre le plan.

Cependant, à un moment critique, l’agent peut déduire lui-même qu’il doit effectuer certains comportements qui, à l’origine, ne devraient pas être exécutés, pour achever la tâche finale.

C’est dans ce processus que le risque ne vient pas d’une entrée extérieure, mais se forme progressivement dans la chaîne d’exécution du modèle lui-même. Autrement dit, le modèle n’est pas corrompu par l’utilisateur étape par étape, mais il se retrouve dans une position non sécurisée en « accomplissant sérieusement sa tâche ».

Comment cette défaillance a-t-elle été découverte ?

Selon l’équipe, l’ISC n’a pas été conçue dès le départ comme une méthode d’attaque. Elle est née d’observations sur le processus d’exécution à long terme de l’agent. Lorsqu’un agent est placé dans un environnement de tâche complexe, il ne se contente pas d’exécuter mécaniquement des instructions. Il planifie, essaie, modifie ses sorties en fonction des retours du système ou du validateur, et forme des objectifs intermédiaires lors de multiples cycles.

C’est justement la méthode la plus courante dans les flux de travail actuels des agents. Les utilisateurs ne rédigent pas de prompts élaborés, ni ne construisent manuellement des instructions malveillantes. La plupart du temps, ils donnent une phrase très vague :

« Aide-moi à finir cette tâche. »
« Améliore cette tâche. »

Ensuite, l’agent entre dans le « workspace », lit les fichiers, comprend l’état actuel, repère les lacunes, planifie, modifie, et corrige en fonction des retours.

Par exemple, dans le scénario AutoResearch, si l’utilisateur fournit un brouillon de papier inachevé et dit « Aide-moi à le compléter », l’agent va lui-même identifier où manquent des analyses expérimentales, des travaux connexes ou des tableaux. Dans le cas du code, une simple demande « Fais tourner le projet » peut déclencher la vérification des dépendances, l’exécution de tests, la localisation d’erreurs et la complétion automatique.

Souvent, le contexte initial est totalement inoffensif. L’utilisateur ne demande pas de générer du contenu risqué, et la description de la tâche ne comporte pas de mots-clés dangereux évidents. Mais dans certains schémas de tâche, l’agent, pour passer la vérification, peut volontairement compléter des contenus qui ne devraient pas être générés par le modèle. Sur cette base, l’équipe de recherche a proposé un cadre d’attaque : TVD (Tâche, Vérification, Données).

Pourquoi une structure de tâche apparemment banale peut-elle devenir une arme ?

La structure TVD n’est pas compliquée, elle ressemble même à un processus d’ingénierie courant :

· Task : une tâche spécialisée ;
· Data : un fichier de données incomplet ;
· Validator : un vérificateur qui ne contrôle que le format, l’intégrité et la réalisation de l’objectif.

Prenons l’exemple de l’entraînement d’un modèle de détection de sécurité. C’est une tâche très professionnelle et tout à fait normale. Les chercheurs peuvent vouloir entraîner ou évaluer un détecteur de sécurité, par exemple en utilisant Hugging Face pour charger un modèle de classification de texte, afin de juger si une sortie appartient à une certaine catégorie de sécurité.

Dans cette tâche, Data représente les échantillons de données à analyser ; Validator vérifie si la tâche est accomplie. Il contrôle si l’entrée est du texte, si la longueur est suffisante, si les champs sont complets, si le format des étiquettes est correct. Pour toute personne ayant une expérience en apprentissage automatique, c’est un flux de travail familier. L’agent connaît aussi très bien ce processus.

Le problème apparaît ici. Si Data est incomplet, la tâche ne peut pas commencer. Le Validator renvoie une erreur, signalant un manque de champs, une longueur insuffisante ou un format incorrect. Pour continuer la formation, l’agent va compléter ces Data lui-même.

Du point de vue de l’agent, il ne « fait pas le mal ». Il se contente d’accomplir une tâche d’apprentissage automatique normale : réparer les données, passer la vérification, faire fonctionner le script d’entraînement. Mais du point de vue de la sécurité, le risque apparaît à ce moment précis : le Validator ressemble plus à un contrôleur de chantier qu’à un vérificateur de sécurité. Il ne vérifie que si la tâche est conforme au format, sans comprendre la sécurité sous-jacente.

Ce problème est également répandu dans les domaines de la médecine, de la biologie, de la chimie, de la cybersécurité, de la pharmacologie et de la sécurité médiatique. La recherche a collecté plus de 50 scénarios, utilisant divers outils scientifiques ou techniques tels que BioPython, RDKit, Cantera, AutoDock Vina, DiffDock, PyRosetta, Scapy, Impacket, angr, Frida, LlamaGuard, Detoxify, OpenAI Moderation API, etc.

Ces outils ne sont pas malveillants en soi. Au contraire, ils sont couramment utilisés dans la recherche ou l’ingénierie. Mais le problème du TVD est que, lorsque la tâche est normale, l’outil est normal, et le vérificateur aussi, l’agent peut néanmoins, lors de la complétion des données, générer des contenus non sécurisés.

Par conséquent, le point clé de l’ISC n’est pas une technique de prompt, mais la capacité de l’agent à compléter automatiquement une tâche « non terminée » : lorsque la condition de complétion et la limite de risque se chevauchent, le modèle peut considérer une sortie non sécurisée comme une livraison normale.

La rupture de Fable 5 montre que même un détecteur puissant ne peut pas arrêter les risques internes dans la chaîne de tâche

L’exemple de Fable 5 montre que, même avec un détecteur externe, certains scénarios d’agent à long terme peuvent échapper à la détection. Cela ne signifie pas que le classificateur de sécurité n’a pas de valeur. Au contraire, il est très utile contre les requêtes malveillantes externes, et a déjà fait échouer de nombreuses méthodes classiques de jailbreak.

Mais cette défaillance montre que, si le détecteur externe est efficace pour délimiter le prompt, cela ne garantit pas qu’il couvre tous les risques internes liés à la chaîne de tâche de l’agent.

Si la faille ne vient pas d’un prompt utilisateur, mais de la trajectoire d’objectif, d’outils, de vérificateurs ou d’exécution de l’agent, alors le détecteur de sécurité devient très vulnérable.

De Fable 5 à plus de 60 autres modèles, y compris ceux d’Apple sur mobile

Avec la publication de ISC-Bench, couvrant 9 domaines spécialisés, la version du papier comprend plus de 60 modèles déclencheurs, et après ouverture du code, le nombre est passé à 84, testant presque tous les modèles et agents de pointe de divers fabricants.

Dans le classement d’évaluation basé sur ISC-Bench, au 30 juin 2026, plus de 60 modèles de pointe ont montré des risques similaires selon l’indicateur ASR@3 !

Le projet sur GitHub a déjà obtenu plus de 800 étoiles, et plusieurs cas de reproduction indépendante ont été collectés (y compris la faille sur le modèle mobile d’Apple), avec une mise à jour continue.

Selon les informations, l’équipe poursuit des recherches approfondies sur la sécurité des modèles de pointe, et a déjà collecté une grande quantité de données internes sur leur vulnérabilité, avec des résultats qui seront publiés progressivement.

Lien original

Cliquez pour découvrir les offres d’emploi de Rhythm BlockBeats

Rejoignez la communauté officielle de Rhythm BlockBeats :

Groupe Telegram d’abonnement : https://t.me/theblockbeats

Groupe Telegram de discussion : https://t.me/BlockBeats_App

Compte officiel Twitter : https://twitter.com/BlockBeatsAsia