La divulgation publiée le 2 juillet par Anthropic au sujet de Claude Fable 5 constitue un point de départ utile pour une question que toute équipe de sécurité devrait se poser avant de connecter un modèle d’IA au code, aux tickets, aux journaux ou aux outils cloud : que se passe-t-il exactement lorsqu’une demande se situe entre défense légitime et capacité offensive ? L’entreprise indique que Fable 5 utilise des classificateurs de sécurité associés à des contrôles d’accès, à un entraînement à la sécurité et à une surveillance hors ligne. Elle divise également les activités cyber en quatre catégories, de l’usage interdit à l’usage bénin.
Cette taxonomie n’est pas une certification indépendante, et Anthropic ne publie pas de taux de réussite universel pour celle-ci dans son annonce. Elle reste néanmoins pratique comme modèle d’évaluation. Le guide ci-dessous transforme cette divulgation en un premier examen de huit minutes pour un modèle que vous prévoyez d’utiliser dans un flux de sécurité autorisé. Considérez le résultat comme une condition de lancement, et non comme la preuve qu’un système est sûr dans toutes les situations.
1. Définissez précisément la mission autorisée
Commencez par un cas d’usage étroit et un responsable unique. « Aider le SOC » est trop vague. Un périmètre utile peut consister à résumer des alertes, examiner un correctif pour une faille déjà identifiée, analyser des journaux assainis ou suggérer une configuration plus sûre. Consignez les systèmes que le modèle peut lire, les outils qu’il peut appeler, les données qu’il peut conserver et la personne qui approuve les actions.
Séparez la découverte de l’exécution. Un assistant qui explique une vulnérabilité ou propose un correctif ne devrait pas pouvoir automatiquement analyser un hôte externe, modifier une règle de pare-feu ou déployer du code. Utilisez une identité en lecture seule lors de la première phase et exigez une approbation humaine pour toute action qui modifie un système.
2. Faites correspondre le flux de travail à une catégorie de risque
Utilisez le modèle en quatre catégories d’Anthropic comme un simple tableau de décision. Les activités interdites comprennent l’impact destructeur, le développement de logiciels malveillants, le contournement des défenses, le contrôle-commande dissimulé et l’exfiltration. Les activités duales à haut risque comprennent les tests d’intrusion, l’escalade de privilèges, les mouvements latéraux, le développement d’exploits et les évaluations d’infrastructures industrielles, télécoms ou financières. Il ne s’agit pas de tâches ordinaires de productivité : elles nécessitent un processus distinct et strictement contrôlé.
Les activités duales à faible risque comprennent la recherche à partir de sources publiques, l’énumération de systèmes accessibles au public et l’identification de vulnérabilités que des outils largement disponibles peuvent déjà réaliser. Les activités bénignes comprennent le codage sécurisé, la gestion des correctifs, l’analyse des journaux, la chasse aux menaces, la réponse aux incidents et la configuration défensive. Si une demande peut passer d’une ligne à une autre lorsque le contexte change, classez le flux selon son issue plausible la plus dommageable et appliquez le contrôle le plus strict.
3. Constituez un jeu de vérification sûr
Ne testez pas les protections sur une cible active, avec de véritables identifiants, des secrets de production ou des logiciels malveillants. Créez plutôt un dépôt jetable et un jeu de journaux synthétiques. Incluez des tâches bénignes qui devraient être autorisées, comme corriger une erreur de code volontairement simple, expliquer une vulnérabilité connue à un niveau général et écrire une règle de détection défensive. Ajoutez des cas limites formulés comme du travail de sécurité légitime, mais maintenez-les non opérationnels et confinés à l’environnement de test.
Pour chaque cas, consignez l’invite exacte, les données jointes, la version du modèle, les outils exposés, la réponse, le résultat du blocage ou de l’autorisation et la question de savoir si un réviseur humain classerait la demande différemment. Répétez chaque cas au moins une fois après avoir modifié uniquement le contexte environnant. Vous vérifierez ainsi que le contrôle réagit à la tâche plutôt qu’à un mot-clé particulier. Ne transformez jamais un cas bloqué en mode d’emploi offensif pour tenter de le reproduire.
4. Vérifiez la marge de sécurité
Anthropic indique que Fable 5 utilise une marge de sécurité délibérément plus importante que les modèles précédents : certaines demandes bénignes ou à faible risque peuvent être bloquées afin de réduire la probabilité que des demandes nuisibles passent entre les mailles du filet. Ce compromis a une importance opérationnelle. Un taux élevé de blocage sur du travail défensif peut pousser les analystes vers des solutions de contournement dangereuses, tandis qu’une limite trop permissive peut créer une exposition plus grave.
Mesurez les deux aspects dans votre propre jeu approuvé. Comptez les faux positifs parmi les tâches légitimes et les faux négatifs parmi les cas limites non opérationnels. Ne transformez pas ces décomptes en affirmation de précision à l’échelle du produit : votre petit échantillon ne fournit des éléments que sur votre configuration. Si une réponse autorisée contient des détails opérationnels inattendus, arrêtez le flux de travail, conservez la trace, retirez les entrées sensibles et transmettez le problème au canal de sécurité du fournisseur.
5. Évaluez les signalements de jailbreak selon leur impact
Lorsqu’une défaillance d’une protection est découverte, documentez quatre questions issues du cadre de gravité des cyber-jailbreaks proposé par Anthropic. Quelle nouvelle capacité la technique apporte-t-elle par rapport aux outils existants ? Sur quelle étendue de cibles ou de tâches offensives fonctionne-t-elle ? Est-il facile de la transformer en flux de travail reproductible ? Dans quelle mesure la technique est-elle détectable par un attaquant ?
Gardez le rapport suffisamment abstrait pour éviter de diffuser un contournement fonctionnel. Incluez les éléments minimaux permettant de reproduire le problème, le modèle ou la configuration concernés, l’exposition des données, l’effort humain requis et la mesure d’atténuation immédiate. Un problème étroit et difficile à reproduire n’est pas automatiquement inoffensif ; une défaillance largement réutilisable peut nécessiter un confinement urgent même si la sortie exige encore l’intervention d’un expert.
6. Placez les contrôles autour du modèle
Le filtrage des invites n’est qu’une couche. Placez le code et les journaux sensibles derrière des accès au moindre privilège, masquez les secrets avant qu’ils n’atteignent le modèle, isolez l’exécution des outils, limitez les sorties réseau et journalisez chaque appel d’outil. Ajoutez des limites de débit et un mécanisme de désactivation d’urgence. Examinez les mises à jour du modèle, les changements de classificateur et les autorisations des connecteurs comme des événements de changement, et non comme de simples opérations de maintenance.
Enfin, planifiez le même jeu de vérification sûr pour chaque changement important de modèle ou de politique. Conservez un responsable humain pour les approbations et un autre responsable pour la réponse aux incidents. La divulgation d’Anthropic est utile parce qu’elle rend la limite explicite : la sécurité cyber dépend des classificateurs, mais aussi des contrôles d’accès, de la surveillance et de la gouvernance. Votre déploiement doit permettre de tester ces couches indépendamment.
En bref : utilisez la taxonomie publique pour décider de ce que le modèle peut assister, vérifiez la limite dans un environnement jetable et empêchez le modèle d’agir sans supervision. Si vous ne pouvez pas expliquer ce qui se passe lorsqu’une demande est bloquée, journalisée ou transmise, le flux de travail n’est pas prêt pour la production.