120 000 caractères mis à nu ! Le system prompt de Claude Fable 5 révélé : que reste-t-il vraiment à la sécurité de l'IA ?

L'affaire Claude Fable 5 ressemble, à bien y regarder, à un déshabillage en public de toute l'industrie de la sécurité IA.

Selon plusieurs médias de sécurité chinois et plateformes d'agrégation, Claude Fable 5 — le modèle du niveau de Mythos qu'Anthropic a ouvert au public — aurait été percé par le jailbreaker elder_plinius au moyen d'une attaque multi-agents coordonnée ; l'intégralité de son system prompt interne aurait été compilée puis publiée sur GitHub, pour environ 120 000 caractères.

Plus grave encore : ce contenu divulgué ne serait pas un simple persona de personnage, mais comprendrait la logique centrale — contrôle de sécurité, classification des risques, limites de refus, appels d'outils, routage des stratégies. Autrement dit, si les reportages se confirment, c'est l'équivalent d'afficher le manuel de la console de sécurité d'un modèle IA de pointe sur la place publique.

Précisons d'emblée : cet article ne reproduira, n'extraitra ni n'enseignera l'usage de ce prompt divulgué. Nous parlons seulement de la raison pour laquelle c'est grave et de ce que cela signifie pour la sécurité de l'IA.

Remettons d'abord la chronologie de l'affaire en ordre

Claude Fable 5 est le nouveau modèle lancé par Anthropic début juin, vu de l'extérieur comme la version publique sécurisée de Mythos 5. Dans les reportages publics, Fable 5 est décrit comme une nouvelle génération de Claude dédiée au raisonnement complexe, aux tâches de longue durée et aux workflows professionnels.

Mais depuis son lancement, la controverse ne cesse.

Première controverse : des seuils de sécurité jugés trop hauts. Des reportages indiquent que Fable 5, par excès de prudence, refuse même de répondre à des questions élémentaires de biologie. Autrement dit, ce n'est pas un problème de capacité : le modèle est entravé par sa politique de sécurité.

Deuxième controverse : le deux-poids-deux-mesures de Microsoft. D'un côté, Fable 5 a été intégré à des services destinés aux clients ; de l'autre, son usage a été restreint en interne — pour des raisons, selon les informations, de sécurité des données et de risque lié aux sorties du modèle.

Troisième controverse, la plus explosive : un attaquant affirme avoir obtenu, via un jailbreak multi-agents coordonné, environ 120 000 caractères du system prompt, qu'il aurait publiés sur GitHub.

Ce qu'on peut lire aujourd'hui sur la page officielle d'Anthropic : le gouvernement américain a émis une directive de contrôle des exportations suspendant tout accès à Fable 5 et Mythos 5. Quant à cette fuite de prompt, l'éditeur ne l'a pas pleinement confirmée.

Pourquoi cette attaque fait peur : pas une percée isolée, mais une tactique de meute

Le jailbreak classique repose généralement sur un prompt magique : amener le modèle à ignorer les règles, à jouer un rôle, à découper les tâches, à contourner les refus.

Mais dans les reportages de cette affaire revient sans cesse une expression : la tactique de la meute de loups.

Autrement dit, l'attaquant ne fonce pas avec un seul prompt : il déploie plusieurs agents qui coordonnent leur attaque —

• un agent chargé de sonder les limites du modèle
• un agent chargé de générer des variantes de questions
• un agent chargé de détecter si les réponses divulguent des informations structurelles
• un agent chargé d'assembler les fragments de sortie en un document complet
• un agent chargé d'ajuster en continu la stratégie d'attaque

On passe ainsi du petit jeu du prompt à un système de red team automatisé.

Un attaquant humain fatigue après 100 essais ; un système d'attaque IA peut en tenter 100 000, et s'optimiser à chaque itération grâce aux retours. Plus un modèle de pointe est puissant, plus il est dangereux de l'employer comme orchestrateur d'attaque.

Et c'est là le véritable signal d'alerte de cette affaire : la force principale qui perce les systèmes de sécurité IA, c'est désormais l'IA elle-même.

À quel point une fuite de system prompt est-elle grave ?

Beaucoup demandent : ce n'est qu'un prompt, non ? Quelle importance s'il fuit ?

C'est un contresens sur les systèmes de grands modèles modernes. Le system prompt d'aujourd'hui n'est plus un simple « tu es un assistant serviable » : il s'apparente plutôt à un manuel de politique d'exécution, susceptible de contenir :

• l'identité du modèle et son style d'interaction
• les critères d'identification des contenus à haut risque
• les niveaux de classification de sécurité
• les gabarits de refus selon les scénarios de risque
• les limites d'appel des outils
• les stratégies de traitement des domaines sensibles — code, cybersécurité, biologie, chimie, etc.
• quand réorienter vers une réponse plus sûre
• quand refuser intégralement
• quand autoriser une explication de haut niveau

Une fois tout cela public, l'attaquant n'a plus besoin de deviner à l'aveugle.

Avant, attaquer un modèle revenait à crocheter une serrure dans le noir : sans connaître le mécanisme, on tâtonne. Après une fuite de system prompt, c'est comme obtenir le plan en coupe du cylindre. L'attaquant peut concevoir un contournement pour chaque règle et traquer méthodiquement les interstices.

Voilà pourquoi une fuite de prompt n'est pas un « problème d'image », mais un incident de sécurité bien réel.

Que signifient 120 000 caractères ?

120 000 caractères, cela correspond à peu près à un roman court, ou à plusieurs dizaines de pages de documentation de politique de sécurité.

Si cette ampleur se confirme, cela signifie que le contrôle de sécurité de Fable 5 ne se résume pas à quelques règles, mais constitue un véritable système de politiques complexe, vraisemblablement décliné en branches fines par domaine de risque : cybersécurité, biosécurité, chimie, manipulation psychologique, fraude financière, fuite de données personnelles, droits d'auteur, sujets politiquement sensibles, protection des mineurs, conseils médicaux, etc.

Il y a là deux paradoxes.

D'abord, l'ingénierie de sécurité d'Anthropic est réellement très fine — au point que nombre de limites sont explicitement définies ; c'est d'ailleurs la raison pour laquelle Fable 5 est apparu « prudent au point d'en être gênant » à son lancement.

Ensuite, plus les règles sont fines, plus leur divulgation expose la surface d'attaque : l'attaquant voit quelles catégories déclenchent un refus, quelles formulations passent, où se trouvent les zones grises.

Plus une politique de sécurité est complexe, plus elle ressemble à un vaste système logiciel. Or un système logiciel a des bugs ; un système de prompts a, lui aussi, ses failles logiques.

Ce n'est pas la première fois : la sécurité de l'IA entre dans l'ère des fuites

Depuis deux ans, ce genre d'incident se multiplie dans le monde de l'IA.

Des sources de Claude Code ont fuité ; des system prompts d'agents commerciaux ont été extraits ; des prompts cachés ont été récupérés via des extensions de navigateur ; des règles internes ont été soutirées en faisant dialoguer des modèles entre eux.

La raison est simple : les actifs centraux des produits de grands modèles se déplacent de plus en plus du code traditionnel vers les prompts, l'orchestration d'outils, le routage des politiques, les systèmes de mémoire et les règles de sécurité.

Autrefois, les entreprises craignaient la fuite de leur code source.

Aujourd'hui, les entreprises d'IA doivent redouter :

• la fuite du system prompt
• la fuite des schémas d'outils
• la fuite des politiques de sécurité
• la fuite des jeux d'évaluation internes
• la fuite des workflows d'agents
• la fuite de la mémoire et des préférences utilisateurs

Tout cela n'est pas du code au sens classique, mais cela détermine le comportement du produit. C'est le code source de la nouvelle ère.

Les conséquences pour les entreprises

Si vous n'êtes qu'un utilisateur ordinaire, tout cela n'est au pire qu'un gros ragot.

Mais si vous êtes responsable de la sécurité d'une entreprise, la donne change.

Les entreprises branchent des grands modèles sur le service client, l'audit de code, l'analyse de données, l'automatisation bureautique, les bases de connaissances internes, les processus financiers, voire les centres d'opérations de sécurité. Le modèle n'est plus un simple chatbot : c'est un acteur opérationnel doté de droits sur des outils.

Dès que le system prompt et les limites des outils sont exposés, l'attaquant peut construire des entrées bien plus précises pour faire mauvais usage des outils, soutirer des informations, contourner les validations ou déclencher des actions erronées.

Les scénarios d'agents sont les plus dangereux : un agent ne se contente pas de répondre, il manipule des fichiers, appelle des API, envoie des messages, interroge des bases de données, exécute des commandes. Une fois le system prompt divulgué, l'attaquant connaît sa logique de décomposition des tâches et ses règles de refus, et peut concevoir des chaînes d'attaque taillées pour ses faiblesses.

Les entreprises ne peuvent donc plus traiter le system prompt comme un « document interne » : il doit entrer dans le périmètre de la gestion des actifs de sécurité.

Comment les entreprises doivent se défendre

Un, ne faites pas reposer toute la sécurité sur le system prompt.

Un prompt peut contraindre un modèle, mais il ne doit pas être l'unique ligne de défense. La vraie sécurité doit descendre jusqu'aux droits sur les outils, aux passerelles API, aux couches d'accès aux données, aux journaux d'audit et aux validations humaines.

Deux, appliquer le principe du moindre privilège aux outils.

Ce qu'un agent peut lire, écrire, supprimer, et à qui il peut envoyer quoi : tout doit être explicitement autorisé. Ne lui accordez pas des droits d'administrateur globaux sous prétexte qu'il « semble intelligent ».

Trois, stratifier le system prompt.

N'empilez pas toutes les politiques dans un prompt unique et gigantesque. Séparez en couches — identité, tâche, outils, sécurité, audit — chargées dynamiquement selon le scénario. Ainsi, même si une couche fuit, l'attaquant n'obtient pas le panneau de contrôle complet.

Quatre, introduire une détection côté sorties.

Ne vous limitez pas à analyser les entrées utilisateurs : les sorties du modèle doivent aussi être passées au crible — détection d'informations sensibles, détection de comportements hors périmètre, blocage d'instructions dangereuses.

Cinq, automatiser la red team.

Puisque les attaquants emploient des meutes multi-agents, la défense doit elle aussi déployer des red teams multi-agents : faire régulièrement attaquer un groupe de modèles par un autre, générer automatiquement des cas de test, mettre à jour les défenses en continu.

Pourquoi je ne recommande pas de diffuser le texte original

Certains ne manqueront pas de dire : « donne le lien GitHub, qu'on voie ça tout de suite ».

Je le déconseille.

Un, le texte original contient peut-être des détails directement exploitables pour contourner les politiques de sécurité : le diffuser revient à aider davantage de monde à reproduire l'attaque.

Deux, son authenticité n'est pas confirmée officiellement ; toute rediffusion risque de faire passer pour des faits un contenu incomplet, voire contaminé.

Trois, pour les chercheurs, ce qui mérite vraiment l'étude, ce sont les points de défaillance de l'architecture de sécurité, pas le copier-coller du prompt divulgué par d'autres.

Ce dont le milieu de la sécurité devrait débattre, c'est de pourquoi la fuite a eu lieu, comment en réduire les dégâts et comment bâtir de nouvelles couches de protection — pas transformer ce prompt en simple spectacle en ligne.

La plus grande leçon de cette affaire

La fuite du system prompt de Claude Fable 5 ressemble, en surface, à un accroc isolé d'Anthropic ; en réalité, c'est un problème dont toute l'industrie de l'IA ne peut pas faire l'économie.

Nous confions aux grands modèles un nombre croissant de décisions, d'opérations et de frontières de sécurité ; or nombre des contrôles essentiels de ces systèmes reposent encore sur un médium fragile : le prompt en langage naturel.

Le langage naturel a l'avantage de la souplesse — et le défaut d'être trop souple. Il n'a ni le typage strict du code, ni l'explicité d'une liste de contrôle d'accès, ni l'isolement dur d'un bac à sable.

La sécurité de l'IA de demain ne peut donc pas reposer uniquement sur « des system prompts toujours plus longs ».

Les pistes réellement fiables sont :

• l'entraînement à la sécurité interne des modèles
• les moteurs de politiques externes
• les bacs à sable de droits sur les outils
• les journaux d'audit obligatoires
• l'isolement des informations confidentielles
• la validation croisée multi-modèles
• les tests de red team automatisés

Le system prompt peut être un volant, il ne doit pas être le frein.

Pour finir

Le plus ironique dans l'affaire Fable 5 : Anthropic s'est toujours posé en porte-étendard de la sécurité IA — et voilà que son modèle le plus sûr, à peine lancé, se retrouve au cœur d'une fuite présumée de system prompt.

Cela ne veut pas dire qu'Anthropic est à la traîne. C'est au contraire le signe que la sécurité de l'IA est entrée dans une phase bien plus difficile.

Avant, c'était l'humain qui attaquait l'IA.

Désormais, c'est l'IA qui organise l'IA pour attaquer l'IA.

Quand l'attaque, les politiques et le debriefing deviennent tous automatisés, défendre la place avec un simple prompt de sécurité de 120 000 caractères est une cause perdue.

L'ère des « Printemps et Automnes » de la sécurité de l'IA est terminée — celle des « Royaumes combattants » ne fait que commencer.