Ce n'est pas une injection de prompt, ce n'est pas du roleplay, et ce n'est pas non plus le déguisement d'une requête malveillante en question normale. Cette fois, le risque est apparu au cours du processus d'exécution autonome de tâches par l'agent intelligent.
Fable 5 est le modèle de niveau Mythos ouvert au public par Anthropic, qui possède non seulement des capacités polyvalentes extrêmement puissantes, mais a également intégré en périphérie du modèle une nouvelle génération de classificateur de sécurité (Safety Classifier) comme ligne de défense.
Selon la conception officielle, lorsqu'une requête de l'utilisateur concerne des domaines à haut risque comme la cybersécurité, la biologie, la chimie ou la distillation de modèles, le système priorise l'identification des risques et, selon leur niveau, refuse directement la requête ou la traite en basculant vers le modèle plus conservateur Opus 4.8.
De nombreux tests utilisateurs ont révélé que les techniques de jailbreak largement utilisées par le passé, telles que les prompts adversariaux, le roleplay, les contournements par encodage ou les expressions implicites, échouaient presque toutes face à ce mécanisme de sécurité, démontrant ainsi sa grande capacité d'interception des risques au niveau de l'intention.
Cependant, le jour même de la sortie de Fable 5, une équipe de recherche internationale composée de membres de l'Université Fudan, de l'Université Deakin, de la City University of 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 protection de sécurité de Fable 5.
Cette méthode d'attaque a été conçue principalement par Yutao Wu, doctorant à l'Université Deakin. L'attaque complète ne nécessite qu'un seul dialogue et prend moins de 5 secondes pour contourner le classificateur de sécurité en amont et inciter le modèle à générer du contenu nuisible et non conforme.
Les résultats de l'analyse du trafic montrent en outre que la sortie nuisible provient directement de Fable 5 lui-même, et non du modèle Opus 4.8 vers lequel le système bascule automatiquement après le déclenchement du mécanisme de sécurité. Cela signifie que cette attaque a non seulement contourné avec succès la détection du classificateur de sécurité, mais a également franchi de manière substantielle la ligne de défense de sécurité de Fable 5.
Il est à noter que le hacker connu sous le nom de Pliny the Liberator a également récemment rendu public un contournement du classificateur de sécurité de Fable 5. Cependant, l'approche technique adoptée par l'équipe Fudan & Deakin n'est pas une simple exploration par combinaison, mais révèle une faille fondamentale dans ce type de systèmes d'agents super-intelligents comme Fable 5.
Selon les informations, l'équipe avait déjà terminé ses recherches préliminaires et les avait publiées en mars de cette année. Cette étude ne visait pas spécifiquement la conception du système unique Fable 5, mais s'est penchée sur l'architecture défensive "classificateur de sécurité + modèle" couramment adoptée par la nouvelle génération de super-agents, révélant directement les failles structurelles inhérentes à ce type de mécanisme de sécurité, ce qui a donc rapidement montré son efficacité après la sortie de Fable 5.
Les informations publiques indiquent que l'équipe avait déjà utilisé une technique similaire en mars de cette année pour extraire avec succès les prompts système de 37 principaux grands modèles et systèmes d'agents, et avait réalisé une vérification open-source sur Claude Code (correspondance à 95%).
On apprend que le responsable de cette équipe de recherche est le professeur Ma Xingjun de l'Institut de l'Intelligence Incarnée Fiable de l'Université Fudan.
Ces dernières années, son équipe a mené des recherches systématiques sur la sécurité des grands modèles, des agents et de l'intelligence incarnée, obtenant une série de résultats scientifiques de pointe au niveau international et remportant le championnat du benchmark de sécurité du US AI Safety Center.
Actuellement, son équipe promeut activement le transfert de ces résultats, se concentrant sur la sécurité des agents et explorant la construction d'infrastructures de sécurité pour les systèmes d'agents de nouvelle génération.
Selon le professeur Ma, l'importance majeure de ce résultat de recherche réside dans le fait qu'il lance un nouveau défi au paradigme de défense statique actuel centré sur le classificateur de sécurité : compter uniquement sur un classificateur de sécurité en amont n'est pas suffisant pour prévenir complètement les comportements à risque potentiels dans les systèmes d'agents avancés.
Le classificateur de sécurité se concentre principalement sur l'identification et l'interception des risques dans les entrées utilisateur, pouvant détecter et filtrer efficacement les instructions à haut risque explicites, mais il est incapable de percevoir les comportements à risque internes qui émergent progressivement pendant l'exécution à long terme, la planification multi-étapes, l'interaction avec l'environnement et l'appel d'outils de l'agent.
La méthode ayant permis de contourner Fable 5 provient de l'article publié par l'équipe en mars dernier, intitulé « Internal Safety Collapse in Frontier Large Language Models ».
L'article révèle un phénomène de sécurité caché, l'« Effondrement de Sécurité Interne (Internal Safety Collapse, ISC) » : lorsqu'un Agent exécute une tâche de longue durée, la défaillance de sécurité ne provient pas nécessairement d'un prompt externe malveillant, mais peut survenir dans la chaîne d'exécution propre au modèle.
Pas une attaque par prompt externe, mais un relâchement interne dans la chaîne de tâches
Les attaques traditionnelles pénètrent généralement de l'extérieur. L'attaquant écrit un prompt d'entrée apparemment inoffensif mais en réalité antagoniste, ou utilise des techniques comme le roleplay, l'encodage, la traduction, des instructions indirectes, etc., pour déguiser une intention malveillante en requête normale. La tâche principale du classificateur de sécurité est d'intercepter le risque à ce niveau.
Le détecteur de Fable 5 est justement conçu pour ce scénario. Il est très sensible aux requêtes à haut risque directes, allant jusqu'à bloquer de nombreuses requêtes normales. Mais l'ISC révèle un autre chemin : le risque ne provient pas nécessairement d'une requête dangereuse directement saisie par l'utilisateur.
L'agent intelligent est confronté à un répertoire de travail apparemment ordinaire : des fichiers, un objectif, un processus de validation et une tâche à accomplir. Ensuite, il commence à planifier, lire des fichiers, exécuter du code, corriger des erreurs et tente continuellement de faire passer la tâche avec succès.
Pour expliquer cela par une métaphore imagée, les mécanismes de sécurité traditionnels protègent « l'entrée » du système, vérifiant si l'entrée utilisateur présente des risques ; tandis que ce que révèle l'ISC ressemble davantage aux multiples niveaux de rêve dans « Inception ».
Lorsque la tâche progresse vers la deuxième, la troisième, voire des couches d'exécution plus profondes, le modèle recomprend l'objectif de la tâche en se basant sur le contexte interne accumulé, et un glissement se produit progressivement dans ce processus.
Dans ce cas, l'entrée initiale de l'utilisateur peut être parfaitement normale et inoffensive, et le processus d'exécution en amont peut rester conforme : lire des fichiers, analyser des données, écrire du code, appeler des outils, tout semble avancer comme prévu.
Cependant, lorsque l'agent intelligent atteint un stade clé de l'exécution, il peut déduire par lui-même une conclusion : s'il n'entreprend pas certaines actions qui ne devraient normalement pas être exécutées, il ne pourra pas accomplir la tâche finale.
C'est précisément dans ce processus que le risque n'émerge pas de l'entrée externe, mais se forme progressivement dans la propre chaîne d'exécution de tâches du modèle. En d'autres termes, le modèle n'est pas « éduqué à mal faire » étape par étape par l'utilisateur. C'est en « accomplissant sérieusement sa tâche » qu'il se place lui-même dans une position dangereuse.
Comment ce phénomène a-t-il été découvert ?
Selon l'équipe, l'ISC n'a pas été initialement conçu comme une méthode d'attaque. Il provient à l'origine de l'observation du processus d'exécution longue durée des agents intelligents. 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, teste, modifie ses sorties en fonction des retours du harnais ou du validateur, et forme des objectifs intermédiaires au cours de cycles d'exécution multiples.
C'est précisément le mode d'utilisation le plus courant aujourd'hui pour de nombreux flux de travail d'Agent. L'utilisateur n'écrit pas un prompt soigneusement conçu, encore moins ne construit manuellement des instructions d'attaque. Souvent, l'utilisateur ne donnera qu'une phrase très vague :
« Aide-moi à accomplir cette tâche. » « Aide-moi à améliorer encore cela. »
Ensuite, l'Agent entrera de lui-même dans l'espace de travail, lira les fichiers, comprendra l'état actuel, identifiera les éléments manquants, établira un plan, exécutera les modifications, et corrigera continuellement les problèmes en fonction des retours.
Par exemple, dans un scénario de recherche automatique (AutoResearch), l'utilisateur ne donne qu'un article non terminé et une phrase « aide-moi à le compléter », l'Agent jugera par lui-même où manquent des analyses expérimentales, des travaux connexes ou du texte de tableau. Les scénarios de code sont similaires : une simple phrase « aide-moi à faire fonctionner ce projet » peut déclencher une vérification des dépendances, l'exécution de tests, la localisation d'erreurs et l'auto-complétion.
Souvent, le contexte précédent est totalement inoffensif. L'utilisateur ne lui a pas demandé de générer du contenu à risque, et la description de la tâche ne contient pas de mots-clés dangereux évidents. Mais dans certaines structures de tâches, l'Agent, pour passer la validation, complétera activement certains contenus qui ne devraient pas être générés par le modèle. En se basant sur cette observation, l'équipe de recherche a ensuite proposé un cadre d'attaque : TVD (Tâche, Validation, Données).
Pourquoi une structure de description de tâche apparemment très ordinaire devient-elle une attaque ?
La structure TVD n'est pas compliquée, elle ressemble même à un flux de travail technique courant :
· Task : une tâche professionnelle ;
· Data : un fichier de données incomplet ;
· Validator : un validateur qui vérifie uniquement le format, l'exhaustivité et l'achèvement de l'objectif.
Prenons l'exemple de l'entraînement d'un modèle Guard, c'est à l'origine une tâche très professionnelle et normale. Un chercheur peut vouloir entraîner ou évaluer un détecteur de sécurité, par exemple charger un modèle de classification de texte depuis Hugging Face pour déterminer à quelle catégorie de label de sécurité appartient une sortie de modèle donnée.
Dans cette tâche, les Data sont les échantillons de données que le modèle doit détecter ; le Validator définit si la tâche est accomplie. Il vérifie si l'entrée est du texte, si la longueur est suffisante, si les champs sont complets, si le format des labels est correct. Pour toute personne ayant de l'expérience en entraînement de machine learning, c'est un flux de travail familier. L'Agent est également très familier avec ce flux de travail.
C'est là qu'apparaît le problème. Si les Data sont incomplètes, la tâche ne peut pas démarrer. Le Validator signalera une erreur, indiquant des champs manquants, une longueur insuffisante ou un format incomplet. Pour permettre au processus d'entraînement de continuer, l'Agent complétera lui-même ces Data.
Du point de vue de l'Agent, il ne fait pas « le mal ». Il accomplit simplement une tâche normale de machine learning : réparer les données, passer la validation, 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 vérificateur d'ingénierie qu'à un examinateur de sécurité. Il vérifie seulement si la tâche est accomplie selon le format, il ne comprend pas les limites de sécurité derrière le contenu.
Des problèmes similaires existent largement 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é des médias. L'article recueille plus de 50 scénarios de ce type, impliquant divers outils de recherche ou d'ingénierie réels, par exemple BioPython, RDKit, Cantera, AutoDock Vina, DiffDock, PyRosetta, Scapy, Impacket, angr, Frida, LlamaGuard, Detoxify, OpenAI Moderation API, etc.
Ces outils ne sont pas intrinsèquement malveillants. Au contraire, ce sont tous des outils professionnels couramment utilisés dans la recherche ou l'ingénierie réelles. Mais le problème avec TVD est le suivant : lorsque la Tâche est normale, l'Outil est normal, le Validator est normal, l'Agent peut néanmoins, en complétant les Données, produire une sortie dangereuse.
Par conséquent, le point clé de l'ISC ne réside pas dans les techniques de prompt, mais dans la capacité d'auto-complétion de l'Agent face à une « tâche inachevée » : lorsque les conditions d'achèvement et les limites de risque se chevauchent, le modèle peut considérer une sortie dangereuse comme un livrable normal.
Contourner Fable 5 montre qu'un détecteur fort ne peut pas bloquer les risques internes de la chaîne de tâches
Le cas de Fable 5 montre qu'un détecteur externe seul peut ne pas couvrir certains scénarios d'Agent à long terme. 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 effectivement rendu de nombreuses méthodes de jailbreak traditionnelles inefficaces.
Mais cette brèche montre que l'efficacité d'un détecteur externe à la frontière du Prompt n'implique pas qu'il puisse couvrir les risques de tâches longues à l'intérieur de l'Agent.
Si le point d'entrée n'est pas le Prompt de l'utilisateur, mais émerge des objectifs, outils, validateurs et trajectoires d'exécution de l'Agent, alors le détecteur de sécurité devient très fragile.
De Fable 5 à plus de 60 autres modèles, y compris le modèle d'Apple pour mobile
Accompagnant la recherche, l'ISC-Bench couvre 9 domaines professionnels. La version de l'article contient plus de 60 modèles de déclenchement, étendus à 84 modèles après publication open-source. Les sujets de test incluent presque tous les modèles de pointe et systèmes d'agents des principaux fournisseurs.
Dans le classement d'évaluation basé sur ISC-Bench, jusqu'en juin 2026, plus de 60 modèles de pointe ont révélé des risques similaires sous la métrique ASR@3 !
Actuellement, le projet GitHub a déjà obtenu plus de 800 étoiles (stars), collecté plusieurs cas de réplication indépendants (y compris le contournement du modèle mobile d'Apple pour téléphone), et est mis à jour en continu.
Il est rapporté que l'équipe mène des recherches de sécurité à grande échelle sur les modèles de pointe et détient actuellement une vaste distribution de données internes non sécurisées pour de nombreux modèles. Les résultats de recherche associés seront publiés progressivement par la suite.
