Fable d’Anthropic : quand un modèle cybersécurité refuse de faire de la cybersécurité

Anthropic a annoncé Fable avec une ambition claire : un modèle d’IA spécialement conçu pour la cybersécurité, capable d’aider les professionnels à analyser des vulnérabilités, comprendre des malwares, automatiser des tâches de pentest. Les chercheurs en sécurité ont levé les yeux de leur terminal avec une curiosité sincère. Un LLM qui comprend vraiment leurs besoins, sans les traiter comme des criminels à chaque requête un peu sensible ? Enfin.

La réalité a refroidi l’enthousiasme. Depuis la sortie de Fable, la communauté sécurité fait remonter des retours qui se ressemblent tous : le modèle refuse d’aider sur des tâches que tout pentest junior exécute en première semaine. CTF, reverse engineering, analyse de shellcode, simulation d’attaque sur environnement de test — rejet. Parfois avec un message d’explication poli, parfois sans. Dans les deux cas : inutile.

Ce n’est pas la première fois qu’un éditeur d’IA promet un outil « pour les pros de la sécu » et livre quelque chose de tellement bridé que ChatGPT gratuit fait mieux. Mais là, c’est Anthropic — l’acteur qui se positionne justement comme le plus sérieux sur la sécurité et l’alignement des LLMs. Le décalage est particulièrement piquant.

Fable, le modèle cybersécurité d’Anthropic — c’est quoi exactement ?

Fable est un modèle Claude adapté et fine-tuné pour les cas d’usage liés à la sécurité informatique. L’idée de départ est solide : la sécurité offensive et défensive nécessite une expertise technique très précise, que les modèles généralistes gèrent mal. Comprendre un rapport CVE complexe, générer des règles Snort ou Sigma, analyser un binaire suspect, automatiser un scan de surface d’attaque — ce sont des compétences qui demandent un contexte métier fort, et les modèles généralistes s’en sortent souvent avec des réponses trop vagues ou trop frileuses.

Anthropic a donc entraîné Fable sur des datasets spécialisés, avec la promesse d’un modèle qui « comprend » la sécurité mieux qu’un Claude standard. En théorie, c’est exactement ce dont les équipes de red team, les CERT, les chercheurs en vulnérabilités et les auditeurs ont besoin. Le modèle est accessible via API avec un processus de vérification pour filtrer les accès — une approche raisonnable en soi, puisque l’objectif est de le réserver aux professionnels légitimes.

Le problème, c’est que le processus de vérification ne semble pas modifier le comportement du modèle une fois dans la place. Un chercheur vérifié et un utilisateur lambda se retrouvent face aux mêmes refus. La vérification d’identité ressemble alors à une case cochée pour des raisons juridiques plutôt qu’à une vraie décision de conception produit.

Ce que le modèle refuse de faire — et pourquoi c’est un problème concret

Les retours qui circulent sur Hacker News, X et dans les forums spécialisés convergent sur les mêmes points. Fable refuse systématiquement d’aider sur plusieurs tâches du quotidien en sécurité offensive :

• La génération ou l’analyse de shellcode, même dans un contexte déclaré de formation
• Les questions liées à l’exploitation de CVEs connues et déjà patchées
• L’aide sur des challenges CTF impliquant du reverse engineering ou de la pwn
• La simulation d’attaques sur des environnements déclarés comme des labs de test
• L’explication détaillée de techniques d’évasion d’antivirus

Pour un lecteur extérieur à la sécu, ça peut sembler prudent. Pour un pentest professionnel ou un chercheur en vulnérabilités, c’est exactement le cœur du métier. Un auditeur qui ne peut pas parler de shellcode ou d’exploitation de CVE, c’est comme un médecin urgentiste à qui on interdit de nommer les pathologies parce que les termes font peur aux non-initiés.

Le problème de fond : ces techniques sont documentées publiquement depuis des années. Les faire refuser par un modèle « spécialisé » ne protège personne — les acteurs malveillants ont d’autres outils, d’autres canaux, d’autres modèles. Ce que ces guardrails font concrètement, c’est pénaliser uniquement les gens qui font le travail légalement et qui auraient besoin d’un outil fiable pour le faire bien.

Le paradoxe du modèle de sécurité qui ne fait pas confiance à la sécurité

Il y a quelque chose d’absurde dans la situation. Anthropic a investi des ressources importantes pour construire un modèle dédié à la cybersécurité. Il a mis en place un processus de vérification pour s’assurer que les utilisateurs sont des professionnels. Et ensuite, il garde les mêmes guardrails restrictifs qu’un modèle grand public. C’est comme construire une voiture de course avec le limitateur de vitesse d’une citadine, puis s’étonner que les pilotes ne veuillent pas la conduire.

Ça pose une vraie question sur la conception des systèmes de sécurité des LLMs. Les guardrails actuels sont généralement binaires : une catégorie de prompt est jugée risquée, elle est bloquée. Peu importe le contexte, peu importe l’identité vérifiée de l’utilisateur, peu importe si la question concerne un environnement isolé ou de la recherche académique. C’est une approche qui a du sens pour un modèle grand public face à des millions d’utilisateurs anonymes. C’est une approche qui n’a aucun sens pour un outil professionnel dont les utilisateurs ont été préfiltrés.

Un modèle de sécurité qui refuse de parler de sécurité offensive, c’est un détecteur d’incendie qui refuse de mentionner le feu.

La confiance ne se décrète pas avec un badge « utilisateur vérifié » si le comportement du modèle ne change pas derrière. Ce que les chercheurs pointent du doigt, c’est une incohérence de design : on leur demande de s’authentifier et de justifier leur usage légitime, puis on leur sert exactement la même expérience qu’à n’importe qui. Le signal envoyé est clair — et pas très engageant.

La concurrence qui n’a pas ces scrupules

Pendant ce temps, d’autres acteurs occupent le terrain. Des modèles moins connus mais moins bridés font leur chemin dans les équipes de red team. WormGPT et ses dérivés existent depuis un moment pour les acteurs malveillants — c’est un fait établi depuis 2023. Du côté des professionnels légitimes, certains se tournent vers des modèles open source comme Llama ou Mistral, déployés localement, sur lesquels ils peuvent ajuster eux-mêmes les guardrails selon leur contexte d’usage réel.

C’est là que le calcul d’Anthropic devient discutable. Des guardrails trop restrictifs sur Fable ne vont pas empêcher les mauvais acteurs de trouver d’autres outils. En revanche, ils poussent les bons acteurs — ceux qui auraient pu légitimement payer pour un outil sérieux — vers des alternatives moins contrôlées. Le résultat net est exactement l’inverse de ce qu’on cherche à obtenir sur le plan de la sécurité globale de l’écosystème.

Il y a aussi la question de la crédibilité institutionnelle. Si les équipes sécurité des grandes entreprises et des organismes publics ne peuvent pas utiliser Fable pour leur travail quotidien, elles ne vont pas attendre qu’Anthropic règle ses filtres lors d’une prochaine mise à jour. Elles passent à autre chose, et Fable devient une curiosité de conférence plutôt qu’un outil de production.

Peut-on vraiment concevoir un modèle offensif responsable ?

La vraie question sous-jacente : peut-on construire un LLM vraiment utile pour la sécurité offensive sans créer un risque systémique ? La réponse honnête est probablement oui — mais pas avec l’approche actuelle d’Anthropic. Plusieurs pistes sérieuses existent et méritent d’être explorées plutôt que contournées.

La première, c’est le contexte d’exécution : un modèle déployé dans un environnement sandboxé, sans accès réseau sortant, avec des logs d’audit complets, peut légitimement fonctionner avec des permissions plus larges qu’un modèle accessible via API publique. La deuxième, c’est le niveau de vérification de l’utilisateur : pas juste un formulaire de validation en ligne, mais une vérification d’accréditation professionnelle réelle, similaire à ce qui existe dans les secteurs médicaux ou juridiques.

Des projets comme CyberSecEval de Meta ou les benchmarks offensifs de l’AI Safety Institute britannique travaillent précisément sur ces questions. La distinction fondamentale n’est pas « est-ce qu’on bloque tout ? » — c’est « est-ce qu’on peut mesurer et contrôler précisément les risques selon le contexte ? ». Cette nuance, c’est exactement ce qui manque à Fable aujourd’hui. Bloquer par défaut et ne jamais ouvrir, ce n’est pas de la prudence — c’est du design paresseux.

Mon avis tranché : Anthropic a fait une erreur de conception, pas de communication

Fable a été construit avec la mentalité d’un modèle grand public à qui on a collé un label « cybersécurité » dessus. C’est une erreur de conception, pas de communication. Les guardrails d’un outil professionnel doivent être pensés par et pour des professionnels — pas calqués sur ce qu’on impose à un utilisateur anonyme qui pourrait être n’importe qui. Cette erreur n’est pas anodine : elle signale qu’Anthropic n’a pas vraiment impliqué les praticiens dans la boucle de design, ou qu’elle a laissé l’équipe sécurité/légale prendre le dessus sur l’équipe produit.

Ce qui m’interpelle davantage, c’est la dynamique de marché qui se dessine. Anthropic a besoin du segment entreprise et sécurité pour asseoir sa crédibilité commerciale face à OpenAI et Google. Mais si les équipes red team finissent toutes sur des modèles open source auto-hébergés parce que les solutions commerciales sont trop frileuses, Anthropic perd à la fois la valeur business et l’influence sur les standards de sécurité du secteur. Ce n’est pas un scénario gagnant pour personne — sauf peut-être pour Meta, qui continue de distribuer Llama librement.

Mon pari : Anthropic va corriger le tir dans les prochains mois, parce que ne pas le faire serait trop coûteux en termes de crédibilité. Mais le vrai test ne sera pas un communiqué de presse annonçant des « guardrails affinés » — ce sera le moment où un chercheur en sécurité pourra enfin demander à Fable d’analyser un shellcode connu sans se faire éconduire comme un gamin qui a tapé « hack » dans Google. En attendant, les chercheurs ont d’autres outils, et Fable a un problème d’adoption qu’aucune update de prompt system ne réglera seule.