Retour au blogIA

Jailbreaks IA en entreprise : le framework anti-contournement d'Anthropic

CZSyn
3 juillet 2026
5 min

Anthropic détaille les classifieurs cyber de Fable 5 et un barème de sévérité des jailbreaks IA. Ce qu'une équipe française peut en tirer pour ses agents.

classifier@fable-5 ~ cyber-safeguards
$ classify --request "generate ransomware payload"
PROHIBITED USEBLOCK
Prohibited useblock
High-risk dual useblock
Low-risk dual usemonitor, parfois block
Benign useallow + monitoring

Le 2 juillet 2026, Anthropic a publié un billet détaillant les garde-fous cybersécurité de Claude Fable 5, ainsi qu'une première ébauche de framework pour mesurer la sévérité des jailbreaks IA. L'entreprise y expose noir sur blanc ce que ses classifieurs de sécurité bloquent, surveillent ou laissent passer, et propose un vocabulaire commun pour discuter du risque des contournements de garde-fous avec les gouvernements et le reste de l'industrie.

Pour les équipes qui déploient déjà des agents LLM en production, ce document dépasse largement le cas Anthropic. C'est, à notre connaissance, l'une des grilles de lecture les plus détaillées jamais publiées par un éditeur de modèle sur la manière de trier les usages sensibles. Voici ce qu'il faut en retenir, et comment le transposer à vos propres garde-fous.

Fable 5 et le problème du double usage

Pour rappel, Claude Fable 5 a été redéployé et est désormais disponible pour tous les utilisateurs dans le monde. Ce nouveau billet vient compléter ce redéploiement sur deux points précis : le détail des classifieurs de sécurité cyber embarqués avec le modèle, et une proposition de barème pour classer la gravité d'un jailbreak, c'est à dire une manière détournée de formuler une requête pour contourner les protections d'un modèle et débloquer un comportement normalement refusé.

Le point de départ d'Anthropic est simple à énoncer, plus difficile à mettre en oeuvre : en cybersécurité, presque toutes les capacités sont à double usage. Scanner un code source pour trouver des vulnérabilités est utile à un défenseur, mais c'est aussi la première étape d'une attaque. Anthropic ne bloque donc pas tout ce qui touche à la cybersécurité. Ses classifieurs trient les requêtes en quatre catégories, du plus clairement dangereux au plus clairement inoffensif :

  • Usage prohibé : ransomware, wipers, sabotage de processus physiques (énergie, eau, transport, dispositifs médicaux), contournement d'antivirus et d'EDR, développement de malware, infrastructures de commande-et-contrôle, attaques sur le backbone Internet (BGP, DNS, autorités de certification). Peu d'utilité défensive, fort potentiel de dégâts : bloqué systématiquement.
  • Dual use à haut risque : pentest, red teaming, escalade de privilèges, développement d'exploits, évasion de conteneurs, tests d'intrusion sur des systèmes industriels (SCADA, PLC). Ce sont des activités légitimes du quotidien d'un professionnel de la sécurité, mais elles imitent une attaque. Anthropic les bloque par défaut, faute de moyen fiable de vérifier qui est réellement autorisé à les mener.
  • Dual use à faible risque : usages majoritairement défensifs mais qui peuvent aussi servir un attaquant. Surveillés, et parfois bloqués par prudence.
  • Usage bénin : ne cause aucun tort. Autorisé, avec une simple surveillance en arrière-plan.

La marge de sécurité, ou comment accepter des faux positifs par choix

Le concept le plus réutilisable de ce billet est celui de marge de sécurité ("safety margin"). Anthropic explique qu'une partie des usages bénins et des usages dual use à faible risque sont volontairement bloqués, par excès de prudence, pour être certain de ne jamais laisser passer un usage réellement dangereux. Cette marge peut être élargie ou resserrée : pour Fable 5, Anthropic indique l'avoir fixée plus large que sur ses modèles précédents, au prix d'un taux de faux positifs plus élevé sur des requêtes parfaitement légitimes.

C'est une décision de produit assumée, et c'est exactement le type d'arbitrage que toute équipe qui construit ses propres garde-fous doit trancher explicitement, plutôt que de le laisser se décider tout seul au fil des tickets de support.

Un barème commun pour parler de gravité des jailbreaks

Le deuxième volet du billet est une ébauche de framework de sévérité des jailbreaks, construit avec les partenaires Glasswing d'Anthropic. Le constat de départ : un jailbreak peut débloquer un comportement mineur et sans grande conséquence, ou au contraire ouvrir un très large éventail de sorties dangereuses, et il n'existe aujourd'hui aucun vocabulaire partagé pour distinguer les deux. Anthropic propose ce premier brouillon comme base de discussion avec le monde académique, l'industrie et les régulateurs, et sollicite les retours à l'adresse [email protected].

En parallèle, Anthropic a ouvert un programme sur HackerOne permettant à des chercheurs en sécurité de soumettre des jailbreaks cyber qu'ils découvrent sur Fable 5. C'est une boucle de retour externe, en plus des classifieurs, de la formation du modèle à la sécurité, du contrôle d'accès et de la surveillance hors ligne mentionnés dans le billet comme couches complémentaires de défense.

Ce que ça change pour vos propres garde-fous en production

Peu d'équipes françaises ont les moyens d'entraîner leurs propres classifieurs de sécurité comme Anthropic. Mais la logique derrière ce billet reste applicable à l'échelle d'une PME ou d'une DSI qui expose un agent LLM à des utilisateurs internes ou externes :

  • Cartographiez vos usages sensibles en catégories, pas en tout-ou-rien. Un agent qui répond à des questions RH n'a pas le même profil de risque qu'un agent qui exécute des commandes sur votre infrastructure. Documenter ce qui est bloqué, surveillé ou autorisé par type de tâche évite les décisions ad hoc et donne une base pour justifier vos choix face à un client ou un auditeur.
  • Fixez une marge de sécurité explicite et assumée. Décidez, par écrit, si vous préférez plus de faux positifs (blocages gênants mais sûrs) ou plus de faux négatifs (fluide mais risqué), et ajustez selon la criticité réelle de l'agent concerné.
  • Testez vos garde-fous avec des tentatives de contournement réelles. Le red teaming n'est pas réservé aux laboratoires d'IA. Une session régulière où quelqu'un tente activement de faire sortir votre agent de son cadre (prompts déguisés, jeux de rôle, encodages) révèle des trous qu'aucune revue de code ne trouvera.
  • Journalisez les tentatives de contournement, pas seulement les incidents. Une requête bloquée ou suspecte est un signal utile même quand elle échoue. Un monitoring qui ne regarde que les incidents confirmés passe à côté des signaux faibles d'un utilisateur qui teste vos limites.
  • Prévoyez un canal de signalement. Vous n'avez pas besoin d'un programme HackerOne pour vous en inspirer : une adresse ou un canal dédié où un client, un partenaire ou un pentester externe peut vous signaler un contournement qu'il a trouvé vaut largement l'investissement.

Notre lecture chez CZSyn

Sur les projets où nous intégrons des agents IA pour des clients, la sécurité se résume trop souvent à faire confiance aux garde-fous du fournisseur de modèle. Ce billet d'Anthropic est utile précisément parce qu'il montre que même l'éditeur le plus avancé sur le sujet traite la question comme un arbitrage permanent entre faux positifs et faux négatifs, pas comme un problème qu'on résout une fois pour toutes.

La vraie leçon à emporter n'est pas la liste précise de ce que Fable 5 bloque, c'est la méthode : catégoriser les usages selon leur potentiel de nuisance réel plutôt que selon leur proximité avec un mot-clé sensible, documenter la marge de sécurité choisie, et construire une boucle de test et de signalement continue. Une PME qui déploie un agent IA en contact avec des clients ou des données sensibles gagnerait à se poser les mêmes questions qu'Anthropic, à son échelle, avant le premier incident plutôt qu'après.

Vous déployez un agent IA et vous n'êtes pas sûr de vos garde-fous ?

Nous auditons la sécurité de vos agents LLM en production : classification des usages, tests adversariaux, monitoring des contournements. Audit gratuit sous 24h.

29 AVIS 5/5 · +200 PROJETS LIVRÉS · RÉPONSE SOUS 2H

Sources primaires

Un projet en tête ?

Discutons de votre projet et voyons comment nous pouvons vous aider.

Nous contacter