La couverture médiatique récente autour du dernier modèle d'Anthropic, Mythos, s'est presque entièrement concentrée sur ce qu'il pourrait faire pour les attaquants. Un brouillon de billet de blog ayant fuité, consulté par Fortune, décrit le modèle comme étant capable d'« exploiter les vulnérabilités d'une manière qui dépasse de loin les efforts des défenseurs ». À tel point qu'Anthropic déclare vouloir agir avec prudence et bien comprendre les « risques à court terme potentiels du modèle dans le domaine de la cybersécurité » avant de poursuivre.
Ce qui a suivi était prévisible : des gros titres sur « le cauchemar cybernétique imminent de l'IA », des fournisseurs de cybersécurité alertant sur la démocratisation des cyberattaques, et une acceptation générale que l'équilibre a basculé.
Sinistre, n'est-ce pas ?
Eh bien, à première vue, oui. Mais l'équilibre n'a pas basculé. Cette vision apocalyptique repose sur l'hypothèse que la capacité du modèle se traduit directement par un avantage pour l'attaquant. Mais nos données suggèrent le contraire.
L'hypothèse derrière le récit Mythos
En effet, nous savons que les modèles d'IA accéléreront les workflows d'attaque. Mais l'efficacité de ceux-ci dépend fortement du contexte système approfondi – un élément qui fait largement défaut aux attaquants.
Les capacités de cybersécurité attribuées à des modèles comme Mythos recoupent de manière significative ce que les systèmes d'IA réalisent déjà dans des environnements de test de sécurité contrôlés. Découverte de vulnérabilités, raisonnement sur le code, attaques en plusieurs étapes. Notre propre expérience de 1 000 tests d'intrusion (pentests) réels basés sur l'IA nous offre un aperçu de l'évolution des performances dans différentes conditions.
Le schéma est cohérent. Les tests en boîte blanche (whitebox), où le code source de l'application cible est disponible, ont révélé 7 fois plus de problèmes critiques et de gravité élevée et ont fonctionné avec une efficacité environ deux fois supérieure à celle des tests en boîte grise (greybox) avec un accès limité au code source. Cela suggère que l'efficacité de l'IA est très sensible au contexte, plutôt qu'à la seule capacité brute.
En pratique, ce contexte provient de la combinaison de l'analyse statique et dynamique. L'examen du code ou du comportement de manière isolée ne donne qu'une vue partielle. Lorsque les deux systèmes sont disponibles, ils peuvent relier le code écrit à son comportement en exécution, et la profondeur des découvertes change. Cela modifie également l'économie. Moins de tentatives (et donc de tokens) sont nécessaires pour identifier des problèmes significatifs.
Les réflexions actuelles autour de Mythos supposent que les attaquants bénéficieront davantage des derniers modèles de pointe. Mais en pratique, cela ne tient pas compte du fait que les attaquants sont ceux qui disposent d'un contexte limité. Ils déduisent les détails du système de l'extérieur, tandis que les défenseurs ont déjà accès au fonctionnement réel de ces systèmes.
Le contexte est la contrainte, plutôt que la capacité
En effet, une grande valeur est accordée à la manière dont les développeurs de modèles eux-mêmes décrivent la capacité ; la même chose s'est produite lorsqu'Anthropic a affirmé que Claude Opus 4.6 avait découvert plus de 500 vulnérabilités de gravité élevée dans des bibliothèques open source. Ces affirmations montrent ce que les modèles peuvent faire dans des conditions idéales. Mais on parle peu de l'évolution des performances lorsqu'ils fonctionnent sans visibilité complète du système.
La principale variable ici est le contexte. L'accès au code source et à la logique interne de l'application détermine ce que les agents de test peuvent évaluer de manière significative. La capacité seule ne se traduit pas en résultats. Sans un contexte de code statique et dynamique suffisant, même les modèles les plus avancés ne parviennent pas à surpasser les modèles open source légers en raison d'une compréhension incomplète du système qu'ils sondent.
Considérez la récente compromission d'Axios, l'un des packages les plus largement utilisés dans le registre NPM. L'attaquant n'a pas modifié le code source. Il a compromis un compte de mainteneur, ajouté une nouvelle dépendance et publié une mise à jour. L'attaque a fonctionné car il n'y avait pas de CVE connue à laquelle se référer, pas de modèle de code malveillant à signaler, pas de signature à détecter par un scanner. L'attaque a réussi parce que chaque outil de la chaîne manquait du contexte nécessaire pour voir ce qui avait réellement changé.
Une organisation ayant une visibilité approfondie sur son arbre de dépendances – connaissant non seulement les packages qu'elle utilise, mais aussi ce que ces packages font, comment ils se comportent et à quoi ressemble une mise à jour légitime – aurait eu une base pour remettre en question ce changement. Sans cela, aucune quantité de vitesse ou de capacité n'est utile. C'est pourquoi le cadrage actuel « l'IA favorise les attaquants » passe à côté de l'essentiel. C'est là que l'approche des tests basés sur l'IA commence à diverger. Avec un contexte complet couvrant le code et le comportement en runtime, ces outils agentiques privilégiés identifient des problèmes que les tests superficiels manquent tout simplement.
Et pourtant, rien de tout cela ne signifie que l'avantage contextuel du défenseur en matière de visibilité du code et du runtime est permanent. L'IA réduira bien sûr aussi le coût d'acquisition du contexte ; mais le discours actuel implique un changement d'équilibre du jour au lendemain. Construire une véritable compréhension du système est un travail lent et complexe, et bien que les modèles d'IA soient de plus en plus capables de déduire certains aspects du contexte, ils ne pourront jamais égaler la clarté qu'apporte l'accès au code source réel, aux API et aux identifiants/tokens d'application, ainsi que la capacité à analyser rapidement la logique métier interne à travers les composants d'application, les microservices et les intégrations qu'une organisation possède en interne.
Rétrospectivement, tout cela peut sembler évident, surtout à la lumière de la propension à publier du catastrophisme autour de la sécurité. Mais il faut parfois examiner de plus près ce qui nous est présenté pour réellement considérer l'impact réel. Le mantra général a été que les nouveaux modèles d'IA vont faire pencher la balance de manière drastique, ce qui est vrai dans une certaine mesure ; l'IA apportera rapidité, étendue et capacité aux attaquants, et un impact préjudiciable sera ressenti par ceux qui défendent les applications, les systèmes et l'infrastructure.
Mais la nuance est que l'efficacité dépend largement du contexte, et que ce contexte est inégalement distribué. Heureusement pour nous, il penche en faveur du défenseur. Ainsi, bien que les attaquants puissent bénéficier en premier des modèles d'IA de pointe émergents comme Mythos et Capybara, les défenseurs ont déjà l'avantage grâce à une connaissance approfondie et structurelle du fonctionnement réel de leur code. L'IA rend le contexte de sécurité des applications plus précieux que jamais. La question est de savoir si les défenseurs utiliseront l'avantage qu'ils détiennent déjà.
