La cybersécurité comme preuve de travail : des attaques IA à 12 500 $ la tentative

La cybersécurité devient un problème de calcul, pas un problème de compétences. L’évaluation du UK AISI a montré que Claude Mythos réalisait une simulation d’attaque réseau d’entreprise en 32 étapes dans 3 tentatives sur 10, à 12 500 $ par exécution. La thèse de Drew Breunig : les défenseurs doivent dépenser plus que les attaquants en découverte automatisée d’exploits, sous peine de perdre par défaut.

L’UK AI Security Institute a publié une évaluation indépendante de Claude Mythos Preview sur des tâches de cybersécurité.¹ Le chiffre clé : Mythos a réalisé une simulation d’attaque réseau d’entreprise en 32 étapes dans 3 tentatives sur 10. Aucun autre modèle n’avait résolu la chaîne complète. Le lendemain, Drew Breunig a publié le corollaire économique : chacune de ces tentatives a coûté environ 12 500 $ en tokens.² Ensemble, ces deux analyses reformulent la cybersécurité non plus comme un problème de compétences, mais comme un problème de calcul.

L’implication est inconfortable. Dans le cadre posé par Breunig, défendre un système exige désormais de dépenser plus de tokens à découvrir des exploits que les attaquants n’en dépenseront à les exploiter.² La sécurité a toujours été asymétrique : les attaquants n’ont besoin que d’un seul chemin, les défenseurs doivent tous les couvrir. Les agents IA préservent cette asymétrie mais en déplacent l’axe. La ressource rare n’est plus l’expertise. La ressource rare, c’est le budget de calcul.

Ce que l’AISI a réellement mesuré

L’évaluation a utilisé deux approches de test : des défis capture-the-flag (CTF) et des simulations de cyber range.¹

Le cyber range déterminant, « The Last Ones » (TLO), simule une attaque réseau d’entreprise en 32 étapes. Un humain aurait besoin d’environ 20 heures pour la compléter.¹ Mythos a réalisé la chaîne complète dans 3 tentatives sur 10. Sur l’ensemble des 10 exécutions, Mythos a complété en moyenne 22 des 32 étapes. À titre de comparaison, Claude Opus 4.6 a atteint une moyenne de 16 étapes sur le même range.¹

Sur les tâches CTF de niveau expert, Mythos a réussi 73 % du temps.¹

Les budgets de tokens racontent leur propre histoire. L’AISI a testé des plafonds allant jusqu’à 2,5 millions de tokens pour les CTF non experts, 50 millions pour les CTF experts et 100 millions pour les simulations de cyber range.¹ L’évaluation note explicitement que « les modèles continuent de progresser avec des budgets de tokens accrus sur l’ensemble des budgets testés » et que l’AISI s’attend à ce que « les améliorations de performance se poursuivent au-delà » du plafond de 100 millions de tokens testé.¹

Plus de tokens, plus de progrès. Aucun plateau observé.

L’AISI a pris soin de circonscrire ses conclusions. Les cyber ranges ne comportaient ni défenseurs actifs, ni outils défensifs, ni pénalités pour le déclenchement d’alertes.¹ L’évaluation s’applique aux « systèmes d’entreprise faiblement défendus et vulnérables », pas aux environnements de production durcis disposant de SOC et d’IDS. Mythos a également échoué sur le range « Cooling Tower », axé sur la technologie opérationnelle.¹

Ces réserves comptent. Mais la trajectoire compte davantage. Les modèles précédents ne parvenaient pas à compléter la chaîne complète sur ces ranges.¹ Désormais, l’un d’entre eux réalise une intrusion réseau d’entreprise en 32 étapes dans 3 tentatives sur 10, et la courbe de performance s’infléchit vers le haut avec le calcul. La question n’est pas de savoir si l’IA peut pénétrer des systèmes faiblement défendus et vulnérables (l’AISI a démontré que oui). La question est de savoir quand le taux de réussite contre des environnements durcis franchira le seuil où l’automatisation devient économiquement rationnelle.

L’économie : 12 500 $ par tentative

L’analyse de Breunig convertit les résultats de l’AISI en dollars.² À 100 millions de tokens par tentative, une seule exécution de Mythos sur TLO coûte environ 12 500 $. Dix tentatives sur TLO coûtent 125 000 $.²

Ces chiffres semblent élevés isolément. Ils paraissent dérisoires rapportés au coût d’une compromission réseau d’entreprise en 32 étapes pour le défenseur. Le modèle atteint un taux de réussite de 30 % pour une fraction du coût, fonctionne à la demande, et le taux de réussite s’améliore avec le budget. Exécutez la même chaîne d’attaque 100 fois au lieu de 10 (en supposant des tentatives indépendantes et identiquement configurées contre une cible statique) et le nombre attendu de pénétrations réussies passe de 3 à 30, pour environ 1,25 million de dollars en tokens. Cher pour un chercheur individuel. Une erreur d’arrondi pour un acteur étatique.

La thèse centrale de Breunig : « pour durcir un système, il faut dépenser plus de tokens à découvrir des exploits que les attaquants n’en dépenseront à les exploiter ».² La sécurité devient une course au budget de tokens. Breunig soutient que les défenseurs doivent surpasser les attaquants en découverte automatisée d’exploits, sous peine de perdre par défaut.

Il propose un modèle en trois phases : développement, revue et durcissement.² Le développement construit le système. La revue détecte les classes de bugs connues. Le durcissement est la phase nouvelle : une découverte autonome d’exploits tournant en continu jusqu’à épuisement du budget. La sécurité d’un système devient fonction du nombre de tokens que l’équipe consomme à tenter de le casser avant le déploiement.

« On ne gagne pas de points pour l’ingéniosité », écrit Breunig. « On gagne en payant plus. »²

La loi de Linus acquiert une dimension de tokens

Breunig étend la loi de Linus — « avec suffisamment d’yeux, tous les bugs sont superficiels » — pour y inclure les tokens.² Suffisamment de cycles de revue automatisée, avec un budget de calcul suffisant, feront remonter des vulnérabilités que la revue humaine a manquées pendant des décennies.

Les preuves corroborent cette extension. Comme documenté dans When Your Agent Finds a Vulnerability, les travaux de Carlini chez Anthropic auraient permis de découvrir une vulnérabilité du noyau Linux vieille de 23 ans à l’aide d’un script bash de 10 lignes et de Claude Code.⁴ Comme documenté dans Project Glasswing, Anthropic a étendu cette approche avec Mythos pour découvrir ce qu’ils décrivent comme des milliers de zero-days à travers les principaux systèmes d’exploitation et navigateurs.⁵ L’évaluation de l’AISI apporte désormais une confirmation indépendante de cette capacité sous-jacente.

Simon Willison ajoute une observation qui mérite attention : la revue de sécurité pilotée par l’IA augmente la valeur des bibliothèques open source, car les tokens investis dans leur sécurisation profitent collectivement à tous les utilisateurs.³ Le code propriétaire supporte seul ses coûts de sécurité. Le code open source les amortit sur l’ensemble de sa base d’utilisateurs.

Breunig cite le produit de revue de code de Anthropic à 15-20 $ par revue comme point de référence tarifaire.² Il mentionne également les incidents de supply chain LiteLLM et Axios dans le contexte de la sécurité des dépendances, exemples du type de vulnérabilités de chaîne d’approvisionnement qui soulignent la nécessité d’une revue automatisée.²

La formule se cristallise : « Le code reste bon marché, sauf s’il doit être sécurisé. »² Chaque ligne de code dans un système de production porte une dette de sécurité implicite. Cette dette se dissimulait autrefois en pleine lumière, enfouie dans les salaires des équipes de sécurité et l’espoir probabiliste que la revue manuelle détecterait les bugs critiques. La sécurité par tokens rend le coût explicite et mesurable.

Ce que les réserves signifient réellement

Les réserves de l’AISI méritent une lecture attentive, pas un rejet.

L’absence de défenseurs actifs change considérablement l’équation. Une chaîne d’attaque en 32 étapes contre un système sans monitoring, sans alertes et sans réponse aux incidents est un problème fondamentalement différent de la même chaîne contre un SOC doté en personnel. Les réseaux d’entreprise réels disposent d’EDR, de segmentation réseau, de détection d’anomalies et d’analystes humains. Chaque alerte déclenchée par un attaquant automatisé offre à la défense une chance de réagir.

L’absence de pénalités pour le bruit signifie que le modèle peut tenter des approches par force brute qu’un attaquant humain éviterait. Un adversaire réel qui déclenche des centaines d’alertes IDS en une heure fait l’objet d’une investigation. Les ranges de l’AISI ne modélisaient pas cette boucle de rétroaction. Dans un réseau réel, le bruit coûte cher à l’attaquant. La furtivité contraint l’espace de recherche. Supprimez cette contrainte, et le problème devient strictement plus facile.

L’échec sur Cooling Tower est également instructif. Mythos a résolu le range TLO orienté IT mais a échoué sur le range de technologie opérationnelle.¹ Les environnements OT ont des protocoles différents, des contraintes différentes et des modes de défaillance différents. L’AISI note que le modèle s’est enlisé sur les portions IT de ce range, de sorte que l’échec n’indique pas nécessairement une faiblesse spécifique à l’OT, mais les capacités du modèle ne sont manifestement pas uniformes entre domaines. La pénétration de réseaux IT et les attaques de systèmes de contrôle industriel sont des problèmes distincts, et tirer des conclusions sur la maturité OT à partir de cette évaluation exige de la prudence.

Toutefois, les réserves ont aussi une date d’expiration. Les budgets de tokens évoluent à la hausse. Les capacités des modèles s’améliorent entre les évaluations. Le taux de réussite de 30 % contre des réseaux non défendus est le plancher, pas le plafond. L’AISI elle-même s’attend à ce que les performances s’améliorent au-delà des budgets testés.¹ Les défenseurs qui balaient les résultats sous prétexte que les ranges manquaient de défense active parient que la montée en puissance de l’inférence atteindra un plateau avant d’atteindre leurs défenses — un pari que les propres données de l’AISI, dans les plages testées, ne corroborent pas.

Implications opérationnelles pour les praticiens

Pour quiconque fait tourner des agents IA en production (et je fais tourner des agents autonomes la nuit via la Ralph Loop avec 95 hooks comme infrastructure de sécurité), le cadre de la preuve de travail change la manière de penser la défense.

Les hooks de sécurité sont une dépense minimale, pas suffisante. Mes 95 hooks contrôlent ce que les agents peuvent faire : bloquer les force pushes, valider les identifiants, imposer les sandboxes. Ces hooks empêchent mes propres agents de causer des dégâts. Ils ne font rien contre un attaquant externe qui dépense 100 millions de tokens à sonder les systèmes avec lesquels ces agents interagissent. L’infrastructure de hooks est nécessaire mais pas suffisante.

Les tests offensifs automatisés deviennent obligatoires. Le modèle en trois phases de Breunig (développement, revue, durcissement) implique que chaque pipeline de déploiement a besoin d’une phase adversariale où des agents IA tentent de casser le système avant sa mise en production. Pas un test de pénétration coché sur une liste. Un exercice d’épuisement du budget de tokens. Exécutez la découverte automatisée d’exploits jusqu’à épuisement du budget, corrigez ce qui remonte, recommencez.

La Ralph Loop a désormais un corollaire sécurité. J’ai écrit sur la dégradation itérative de la sécurité dans le contexte de la performance : des agents qui passent tous les tests tout en introduisant des ralentissements de 446x. Le même schéma s’applique à la sécurité. Un agent qui écrit du code correct, fonctionnel et bien testé peut néanmoins introduire des vulnérabilités subtiles qui ne se révèlent que sous une revue adversariale automatisée. La solution est identique : ajouter la porte manquante. Les benchmarks de performance détectent les régressions de performance. Le red-teaming automatisé détecte les régressions de sécurité.

Les dépendances open source méritent des budgets de tokens. L’observation de Willison sur le bénéfice collectif s’applique directement à la gestion des dépendances. Chaque bibliothèque open source dans une stack de production bénéficie soit d’une revue de sécurité automatisée de la part de quelqu’un, soit elle n’en bénéficie pas. Breunig cite les incidents de supply chain LiteLLM et Axios dans le contexte de la sécurité des dépendances, des cas où des vulnérabilités ont persisté dans des bibliothèques largement utilisées.² Les praticiens devraient évaluer leurs arbres de dépendances avec une nouvelle question : qui dépense des tokens pour la sécurité de cette bibliothèque ?

Le calcul inconfortable

Le cadre de la preuve de travail rend l’économie de la sécurité explicite d’une manière que les modèles fondés sur l’expertise ne permettaient pas. Dans l’ancien modèle, la qualité de la sécurité était fonction de qui vous recrutiez et de leur niveau de compétence. Dans le nouveau modèle, la qualité de la sécurité est fonction du nombre de tokens que vous dépensez à tenter de casser vos propres systèmes.

Le talent compte toujours : quelqu’un doit interpréter les résultats, hiérarchiser les correctifs et prendre les décisions architecturales. Mais la phase de découverte — celle où des agents automatisés font remonter les vulnérabilités — est de plus en plus un problème de calcul. Et dans les plages testées par l’AISI, les problèmes de calcul favorisent l’entité disposée à dépenser davantage.

Le parallèle avec la preuve de travail des cryptomonnaies est instructif, même s’il est imparfait. Les mineurs de Bitcoin consomment de l’électricité pour sécuriser la chaîne. Les défenseurs consomment des tokens pour sécuriser le système. Dans les deux cas, la garantie de sécurité est proportionnelle au calcul dépensé. Dans les deux cas, un attaquant disposé à dépenser plus de calcul prend l’avantage. La différence : la difficulté du minage Bitcoin s’ajuste automatiquement. Les budgets de tokens de sécurité requièrent un jugement humain sur ce qui est suffisant.

Pour les organisations bien financées, la voie est claire. Ajoutez la découverte autonome d’exploits au pipeline de déploiement. Fixez un budget de tokens proportionnel au profil de risque du système. Épuisez le budget. Corrigez ce qui remonte. Déployez.

Pour tous les autres, la voie est moins confortable. Si vous ne pouvez pas vous permettre de dépenser plus de tokens en défense que les attaquants n’en dépenseront en attaque, il faut compter sur l’infrastructure partagée : revue de sécurité open source, scanning fourni par les éditeurs, défense collective. L’équivalent sécuritaire de l’immunité collective. Et comme l’immunité collective, cela ne fonctionne que si suffisamment de participants contribuent. Profiter de la revue de sécurité open source sans contribuer de tokens en retour est une stratégie qui fonctionne jusqu’au jour où elle ne fonctionne plus.

L’évaluation de l’AISI a montré que les agents IA peuvent réaliser des attaques réseau d’entreprise. Breunig soutient que la défense est un problème de dépense. Willison a identifié le seul avantage structurel des défenseurs : l’infrastructure partagée amortit les coûts sur l’ensemble de ses utilisateurs.

La question pour chaque praticien est celle que les systèmes de preuve de travail ont toujours posée : combien de calcul êtes-vous prêt à consommer ?

FAQ

Que signifie « la cybersécurité comme preuve de travail » ?

L’expression reformule la cybersécurité non plus comme un problème de compétences, mais comme un problème de calcul. L’évaluation du UK AISI a montré que Claude Mythos peut réaliser une attaque réseau d’entreprise en 32 étapes dans 3 tentatives sur 10, à environ 12 500 $ par tentative. Défendre un système exige désormais de dépenser plus de tokens à découvrir des exploits que les attaquants n’en dépenseront à les exploiter. La qualité de la sécurité devient fonction du nombre de tokens consommés à tenter de casser ses propres systèmes avant le déploiement.

Quelles ont été les performances de Claude Mythos sur les tâches de cybersécurité ?

Mythos a réalisé la simulation complète « The Last Ones » d’attaque réseau d’entreprise en 32 étapes dans 3 tentatives sur 10, avec une moyenne de 22 des 32 étapes complétées sur l’ensemble des exécutions. Sur les tâches capture-the-flag de niveau expert, Mythos a réussi 73 % du temps. L’AISI a noté que les performances continuent de s’améliorer avec l’augmentation des budgets de tokens, sans plateau observé jusqu’au plafond de 100 millions de tokens testé.

Quelles sont les limites de l’évaluation de l’AISI ?

Les cyber ranges ne comportaient ni défenseurs actifs, ni outils défensifs, ni pénalités pour le déclenchement d’alertes. L’évaluation s’applique aux « systèmes d’entreprise faiblement défendus et vulnérables », pas aux environnements de production durcis disposant de SOC et d’IDS. Mythos a également échoué sur le range de technologie opérationnelle « Cooling Tower ». Les réseaux d’entreprise réels disposent d’EDR, de segmentation réseau, de détection d’anomalies et d’analystes humains que l’évaluation ne modélisait pas.

Que devraient faire les praticiens face à ces résultats ?

Déployez des PreToolUse hooks comme couche de sécurité minimale. Ajoutez des tests offensifs autonomes au pipeline de déploiement sous forme d’exercice d’épuisement du budget de tokens. Évaluez les dépendances open source avec une nouvelle question : qui dépense des tokens pour la sécurité de cette bibliothèque ? Le cadre de la preuve de travail signifie que chaque système de production a besoin d’une phase adversariale où des agents IA tentent de le casser avant le déploiement.

Citations