La cybersécurité comme preuve de travail

Le UK AI Security Institute a publié une évaluation indépendante de Claude Mythos Preview sur des tâches de cybersécurité.¹ Le chiffre marquant : Mythos a réalisé une simulation d’attaque réseau d’entreprise en 32 étapes lors de 3 tentatives sur 10. Aucun autre modèle n’a 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 requalifient la cybersécurité : non plus un problème de compétences, mais un problème de calcul.

L’implication est inconfortable. Défendre un système exige désormais de dépenser plus de tokens pour découvrir les failles que les attaquants n’en dépenseront pour 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 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 lors de 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 plages 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 toutes les plages testées » 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 de défense, ni pénalités en cas de déclenchement d’alertes.¹ L’évaluation s’applique aux « systèmes d’entreprise faiblement défendus et vulnérables » — pas aux environnements de production renforcés avec SOC et IDS. Mythos a également échoué sur le range « Cooling Tower », axé sur les technologies opérationnelles.¹

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’eux réalise une intrusion d’entreprise en 32 étapes lors de 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 réseaux d’entreprise. La question est de savoir quand le taux de réussite franchira le seuil où l’automatisation deviendra é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 paraissent é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. Lancez la même chaîne d’attaque 100 fois au lieu de 10, et le nombre attendu de pénétrations réussies passe de 3 à 30 — une multiplication par 10 pour environ 1,25 million de dollars en tokens. Coûteux 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 les failles que les attaquants n’en dépenseront à les exploiter ».² La sécurité devient une course au budget de tokens. Dans le cadre posé par Breunig, les défenseurs doivent surpasser les attaquants en découverte automatisée de failles, 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 de failles tournant en continu jusqu’à épuisement du budget. La sécurité d’un système devient fonction du nombre de tokens que l’équipe brûle à tenter de le casser avant le déploiement.

« Être ingénieux ne rapporte aucun point », écrit Breunig. « On gagne en payant plus. »²

La loi de Linus acquiert une dimension tokens

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

Les preuves corroborent cette extension. Les travaux de Carlini chez Anthropic, que j’ai couverts dans When Your Agent Finds a Vulnerability, ont mis au jour une vulnérabilité du noyau Linux vieille de 23 ans à l’aide d’un script bash de 10 lignes et de Claude Code. Project Glasswing a généralisé cette approche avec Mythos pour découvrir des milliers de zero-days sur tous les principaux systèmes d’exploitation et navigateurs. L’évaluation de l’AISI apporte désormais une confirmation indépendante de cette capacité.

Simon Willison ajoute une observation qui mérite attention : la revue de sécurité pilotée par l’IA accroît la valeur des bibliothèques open source, car les tokens dépensés pour les sécuriser 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 la base d’utilisateurs.

Breunig cite le produit de revue de code de Anthropic à 15-20 $ par revue comme un point de référence sur la tarification actuelle.² Il mentionne également les incidents de supply chain LiteLLM et Axios dans le contexte de la sécurité des dépendances — des 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 auparavant au grand jour — 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 modifie considérablement le calcul. Une chaîne d’attaque en 32 étapes contre un système sans surveillance, sans alertes et sans réponse aux incidents est un problème fondamentalement différent de la même chaîne contre un SOC opérationnel. 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é est une occasion pour la défense 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 véritable adversaire 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 technologies opérationnelles.¹ 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 est resté bloqué sur les portions IT de ce range, donc l’échec n’indique pas nécessairement une faible capacité spécifique à l’OT — néanmoins, les capacités du modèle ne sont clairement pas uniformes d’un domaine à l’autre. 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 augmentent. 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 d’un revers de main parce que les ranges manquaient de défense active font un pari contre la loi de Moore appliquée à l’inférence.

Implications opérationnelles pour les praticiens

Pour quiconque exécute des agents IA en production — et je fais tourner des agents autonomes de nuit via le Ralph Loop avec 95 hooks comme infrastructure de sécurité — le cadrage en preuve de travail change la façon de penser la défense.

Les hooks de sécurité sont une dépense minimale, pas suffisante. Mes 95 hooks encadrent ce que les agents peuvent faire : blocage des force pushes, validation des identifiants, application des sandboxes. Ces hooks empêchent mes propres agents de causer des dommages. Ils ne font rien contre un attaquant externe qui dépense 100 millions de tokens pour sonder les systèmes avec lesquels ces agents interagissent. L’infrastructure de hooks est nécessaire mais insuffisante.

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 à cocher. Un exercice d’épuisement du budget de tokens. Lancez la découverte automatisée de failles jusqu’à épuisement du budget, corrigez ce qui remonte, recommencez.

Le 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 réussissent 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 tout de même introduire des vulnérabilités subtiles qui ne se révèlent que sous une revue automatisée adversariale. 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 fait ou ne fait pas l’objet d’une revue de sécurité automatisée par quelqu’un. 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 cadrage en preuve de travail rend l’économie de la sécurité explicite d’une manière que les modèles fondés sur l’expertise n’ont jamais permis. Sous l’ancien modèle, la qualité de la sécurité était fonction de qui vous embauchiez et de leur niveau de compétence. Sous 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, prioriser les correctifs et prendre les décisions architecturales. Mais la phase de découverte, celle où les vulnérabilités sont trouvées, est de plus en plus un problème de calcul. Et les problèmes de calcul ont une propriété connue : l’entité disposant du plus gros budget l’emporte.

Le parallèle avec la preuve de travail des cryptomonnaies est instructif, même s’il est imparfait. Les mineurs de Bitcoin brûlent de l’électricité pour sécuriser la chaîne. Les défenseurs brûlent 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 disposant d’un budget supérieur peut surpasser la défense. La différence : la difficulté du minage Bitcoin s’ajuste automatiquement. Les budgets de tokens de sécurité exigent un jugement humain sur ce qui est suffisant.

Pour les organisations bien financées, la voie est claire. Ajoutez la découverte autonome de failles au pipeline de déploiement. Définissez 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, vous devez vous appuyer sur une infrastructure partagée — revue de sécurité open source, analyse fournie 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 mener à bien des attaques de réseaux 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 pour tous ceux qui l’utilisent.

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 à brûler ?

Citations