Ceci n'est pas une attaque

L'industrie simule l'attaque pour mesurer la défense. Elle simule la défense pour remplacer l'analyste. Elle simule l'architecture pour différer la conception. En avril 2026, trois études chiffrent l'écart entre la simulation et la chose.

La semaine du 4 août 2026, à Las Vegas, une dizaine d'éditeurs de sécurité ont présenté à la conférence Black Hat leurs nouveaux agents défensifs. Les formulations se ressemblent d'un stand à l'autre : anticiper les chemins d'attaque probables, prédire comment un adversaire enchaînerait ses techniques, émuler l'attaquant en continu, valider de façon autonome ce qui est réellement exploitable. Le même jour, l'un de ces éditeurs, qui vend un agent de pentest autonome censé prouver ce qui est exploitable, levait 250 millions de dollars¹. Le marché de la sécurité vend, cette année, des représentations de l'attaque de plus en plus fidèles, et il les vend comme de la sécurité².

Trois mois plus tôt, en avril, trois équipes de recherche sans lien entre elles publiaient trois études qui mesuraient, chacune sur son terrain, l'écart entre ces représentations et ce qu'elles prétendent mesurer. La première, à Sichuan University, fait tourner treize outils de pentest automatisé par intelligence artificielle sur un même jeu d'épreuves, et demande à quinze chercheurs de relire manuellement les 1 500 journaux d'exécution produits³. La seconde, chez Simbian AI, soumet onze modèles d'IA aux tâches d'un analyste SOC : retrouver les traces d'attaques dans des bases de 75 000 à 135 000 logs Windows⁴. La troisième, à Carnegie Mellon et Michigan, propose la première architecture de sécurité formelle pour MCP, le protocole qui permet aux IA d'utiliser des outils externes, et revendique 91 % de couverture théorique⁵.

Aucune de ces études ne cite les deux autres. Lues ensemble, elles racontent la même histoire. À chaque étage du stack, un outil produit un score, un chiffre de couverture, un tableau comparatif. Ce chiffre circule dans les slides, les benchmarks, les offres commerciales. Et à chaque étage, les auteurs eux-mêmes reconnaissent, dans les limitations de leurs propres papiers, que le chiffre ne mesure pas ce qu'il prétend mesurer.

L'industrie a un nom pour cela, mais elle l'applique toujours aux autres : le security theater.

10 milliards de tokens, zéro attaque

Le pentest automatisé par LLM est la promesse du moment. Au lieu d'envoyer un expert humain tester la résistance d'un système pendant une semaine, on envoie un agent IA qui lance des outils, analyse les résultats, adapte sa stratégie et produit un rapport. Des compétitions internationales (Tencent Security AI Hackathon, DARPA AIxCC) accélèrent la course. Les investisseurs suivent. Le marché du pentest atteindra 5 milliards de dollars en 2030, et la pénurie d'experts (2,8 millions de postes cyber non pourvus dans le monde) pousse à automatiser³.

Peng et al. font ce que personne n'avait encore fait : comparer treize de ces outils sur le même benchmark, dans les mêmes conditions, avec le même modèle d'IA sous-jacent. Dix milliards de tokens consommés. Plus de 2 500 dollars de coûts API. Quatre mois de relecture humaine. Les résultats contredisent quatre croyances du marché³.

Première croyance : plusieurs agents spécialisés coopèrent mieux qu'un agent seul. Faux. Trois architectures mono-agent finissent dans le top six. Les architectures multi-agent, censées apporter la spécialisation, dégradent la performance dans plusieurs cas par mauvaise coordination mémoire entre rôles³.

Seconde croyance : connecter l'agent à une base de connaissances l'aide. Souvent faux. Sur six outils équipés d'une base documentaire, trois progressent significativement quand on la retire. Cruiser passe de 42 à 57 points, LuaN1aoAgent de 83 à 90. Le mécanisme est visible dans les logs : l'agent récupère une information qui ne correspond pas à la cible, s'engage sur une fausse piste et ne revient plus en arrière³.

Troisième croyance : un outil spécialisé fait mieux qu'un outil généraliste. La plus brutale à encaisser. Les chercheurs ont configuré un Claude Code (un agent de programmation standard, pas un outil de sécurité) avec un terminal Kali Linux et un prompt de trois lignes. Résultat : 69 points. Six des treize outils spécialisés, développés par des équipes académiques entières, font moins bien. L'ingénierie de spécialisation n'ajoute presque rien. L'agent généraliste avec un accès shell fait l'essentiel du travail³.

Quatrième croyance : l'agent sait quand il a réussi. Faux. Le challenge 028 du benchmark est conçu pour tester la "flag hallucination" : l'agent fabrique un résultat plausible, le soumet comme preuve de succès, et déclare la victoire sans avoir résolu l'épreuve. Il ne distingue plus ce qu'il suppose de ce qu'il observe³.

Ce dernier point mérite qu'on s'y arrête. Un pentest existe pour produire une preuve vérifiable de vulnérabilité. Si l'outil de test invente ses propres preuves, il ne teste plus rien. Il produit des rapports qui ressemblent à des rapports.

Et les logs documentent un risque opérationnel immédiat. VulnBot installe flask-unsign sur la cible via pip. PentestGPT installe psycopg2-binary. Des dépendances tierces téléchargées depuis des registres publics, par un agent qui opère sur un système en mission, sans approbation, sans sandbox, sans whitelist de commandes. Sur un environnement de test, c'est un incident de reproductibilité. Sur un environnement de production, c'est une contamination de supply chain par la porte de service. Aucun des treize outils testés n'implémente de mécanisme d'arrêt sur opération dangereuse³.

Le constat de fond est simple. L'AutoPT fonctionne d'autant mieux qu'on lève les contraintes qui font la légitimité du test. Un vrai pentest exige un périmètre, une traçabilité, une non-destruction. L'agent IA ne gère rien de tout cela. Il fonctionne comme un attaquant sans les contraintes d'un testeur. Quand les contraintes sont levées, il performe. Quand elles sont imposées, il hallucine.

859 enquêtes, zéro succès complet

Le SOC autonome piloté par IA est la seconde promesse du moment. Un agent IA reçoit les logs bruts, identifie les événements suspects, reconstitue la chronologie de l'attaque et produit un rapport d'investigation. Les vendors le promettent depuis 2024, et les RSSI y voient une réponse à la pénurie d'analystes qualifiés.

Simbian teste cette promesse. Les auteurs soumettent onze modèles frontier (dont Claude Opus 4.6, GPT-5, Gemini 3.1 Pro) à une tâche précise : retrouver les traces d'attaques réelles dans des bases de logs Windows. 26 campagnes d'attaque différentes. Budget limité à 50 requêtes SQL par mission, comme un analyste qui ne peut pas tout fouiller. Les logs sont transformés par obfuscation pour empêcher les modèles de reconnaître des données déjà vues en entraînement⁴.

Le meilleur modèle, Claude Opus 4.6, retrouve la moitié des traces d'attaque (Coverage Score 0,55). Les dix autres oscillent entre 10 % et 44 %. Le seuil opérationnel fixé par Simbian (50 % de rappel sur chacune des 13 tactiques ATT&CK) n'est franchi par aucun modèle. Claude Opus 4.6 valide 7 tactiques sur 13. Les dix autres : zéro⁴.

Depuis la publication, Simbian a étendu son évaluation à seize modèles sur 1 144 exécutions, dont Opus 4.8, GPT-5.5 et GLM-5.2. Le verdict ne bouge pas : aucun des seize ne franchit le seuil. Les modèles plus récents n'y changent rien⁴.

Sur 859 missions, aucune n'est complète. Sur les campagnes les plus denses (5 000 à 6 000 traces attendues), Claude Opus 4.6 en identifie environ 150. Soit 3 % de rappel⁴.

Le détail le plus instructif est ce que les auteurs appellent l'attribution gap. Claude Opus 4.6 voit en moyenne 159 traces dans ses résultats SQL, mais n'en signale que 113 comme suspectes. L'agent croise la preuve et ne la reconnaît pas. L'évidence passe sous ses yeux et il ne la nomme pas⁴.

Et les modèles ne réussissent que là où la détection est triviale. Ils repèrent le PowerShell encodé (Defense Evasion), les clés de registre de persistance. Les mêmes signaux que les règles Sigma détectent depuis dix ans. Sur le vol de credentials, l'accès initial, le mouvement latéral et l'exfiltration, l'effondrement est uniforme⁴. Ce sont précisément les tactiques qui comptent face à un APT, et précisément celles qui distinguent un analyste d'un moteur de règles.

L'écart avec les benchmarks de connaissance déclarative est massif. Les mêmes modèles dépassent 80 % sur CyberMetric, SecBench et CTI-Bench, qui testent ce qu'ils savent réciter sur la sécurité. Ils plafonnent à 55 % quand on leur demande de retrouver un signal dans du bruit⁶. Savoir décrire le Kerberoasting et le retrouver dans 100 000 lignes de logs sont deux capacités sans rapport entre elles.

Les promesses "SOC autonome" de 2024-2025 reposaient sur la première métrique. La tâche réelle exige la seconde.

91 % de couverture, zéro implémentation

MCP (Model Context Protocol) est le protocole qui permet aux IA d'utiliser des outils externes : lire un fichier, interroger une base de données, envoyer un mail, exécuter du code. Créé par Anthropic fin 2024, il s'est imposé en dix-huit mois comme le standard de fait pour connecter les agents IA au monde réel. L'écosystème compte 177 000 outils disponibles et 97 millions de téléchargements SDK par mois⁵.

Un chiffre change la nature du sujet. La part d'outils MCP qui modifient l'environnement externe (écriture, envoi, exécution, et non simple lecture) est passée de 27 % à 65 % entre novembre 2024 et février 2026⁵. En quinze mois, MCP est passé d'un protocole de consultation à une infrastructure d'exécution distribuée. Le problème de sécurité a changé de nature avec lui.

Acharya et Gupta proposent MCPSHIELD, la première architecture de sécurité formelle pour ce protocole. Quatre couches empilées : contrôle d'accès (quel outil peut faire quoi), attestation cryptographique (vérifier qu'un outil n'a pas été modifié), suivi des flux d'information (tracer où vont les données), et protection contre les injections de prompt. Sept catégories de menaces, 23 vecteurs d'attaque identifiés. Couverture théorique revendiquée : 91 %⁵.

Le diagnostic de départ est juste. Les défenses actuelles pour MCP ne couvrent pas plus de 34 % des menaces connues, avec un taux de succès moyen inférieur à 30 %. Plusieurs catégories entières d'attaques (fuite de données entre serveurs, modification silencieuse d'outils entre deux sessions) n'ont aucune défense formelle⁵. Le problème commence avec la réponse proposée.

La couche de suivi des flux d'information (L-IFT) occupe le centre du dispositif. C'est elle qui doit tracer quelles données passent d'un outil à l'autre et empêcher les fuites. Les auteurs admettent dans le même papier que cette couche est "intractable" à travers les mécanismes d'attention d'un LLM⁵. En clair : le cœur de l'architecture ne peut pas fonctionner avec la technologie qu'il est censé protéger. L'une des quatre colonnes du temple est avouée décorative par ses propres architectes.

La couche d'attestation cryptographique (L-CTA) porte 39 % de la couverture revendiquée. Elle prouve qu'un outil n'a pas été modifié depuis sa signature. Elle ne prouve pas que l'outil était sûr au moment où il a été signé. La distinction est connue en sécurité logicielle depuis toujours. Les auteurs la signalent en "défi ouvert". Mais les 91 % reposent quand même dessus⁵.

La contribution durable du papier se trouve ailleurs. Les auteurs identifient une surface d'attaque qu'ils appellent S_compose : des outils individuellement sûrs qui, combinés, produisent un risque nouveau. Un outil qui lit un fichier plus un outil qui envoie un mail égale une exfiltration de données. Aucune preuve de sécurité compositionnelle n'existe aujourd'hui pour ce type de couplage⁵. Les auteurs le posent comme problème ouvert.

Cette reconnaissance contient la conclusion que le papier ne tire pas. Si la sécurité est une propriété qui naît de la composition, pas de la somme des composants, alors empiler quatre couches de défense après coup ne peut pas résoudre un problème qui naît de l'assemblage lui-même.

Et le silence le plus lourd porte sur la gouvernance. Le défi ouvert n°7 mentionne "177 000 outils, mêmes défis que npm/PyPI" et passe à autre chose⁵. 177 000 outils disponibles à l'installation, sans registre audité, sans processus d'admission, sans gouvernance d'entrée. Pour un RSSI qui gère déjà la dette de sécurité des dépendances npm et PyPI, la question opérationnelle est comment empêcher ses développeurs d'en connecter cinquante par semaine sans que personne ne valide.

Le circuit

Les trois études documentent le même mécanisme à trois étages. L'agent offensif simule l'attaque et hallucine son propre résultat. L'agent défensif simule l'enquête et croise l'évidence sans la reconnaître. L'architecture formelle simule la protection avec une couche centrale avouée impraticable. À chaque étage, un artefact technique produit un score qui circule indépendamment de ce qu'il mesure.

Ce mécanisme n'est pas neuf. Il structure le marché depuis vingt ans. Le pentest annuel produit un rapport que le COMEX lira comme "notre sécurité est validée". Une plateforme de validation continue produit un dashboard présenté comme preuve de résistance. La couverture ATT&CK produit une carte opposée à l'auditeur comme preuve de complétude. Chaque couche valide la précédente. Aucune ne touche le système lui-même.

L'industrie du test offensif le sait, en partie. Une mission de pentest est courte et bornée, quelques jours à quelques semaines sur un périmètre fixé. Un groupe APT prend six mois, pivote par le prestataire de maintenance climatisation, et n'a pas de date de fin. Le pentester cherche ce qu'il sait trouver (web app, AD misconfig, CVE connues) parce que c'est ce qui remplit le rapport dans le temps imparti. Les vecteurs longs, imprévisibles, combinatoires, restent sous-explorés parce que non rentables sur le calendrier contractuel.

Ce constat est ancien. La littérature militaire le formule depuis quarante ans : personne dans une armée sérieuse ne confond les résultats d'un wargame avec une prédiction de combat⁷. Le cyber a importé le vocabulaire (red team, blue team, table top, war game) en oubliant la mise en garde qui l'accompagnait.

Ce qui a changé en 2026, c'est la possibilité de mesurer l'écart. Quand l'agent AutoPT hallucine un flag, il boucle la représentation sur elle-même : son hypothèse devient sa propre observation. Quand le benchmark Simbian enregistre 859 missions sans un seul succès complet, il documente la production industrielle de résultats partiels traités comme des résultats. Quand MCPSHIELD revendique 91 % de couverture sur une architecture dont la couche centrale ne fonctionne pas, il inscrit un chiffre sur un objet qui ne contient pas ce que le chiffre prétend. Les trois papiers, sans le savoir, documentent trois versions du même geste.

Ce que l'industrie appelle tour à tour "validation continue", "adversary emulation", "breach and attack simulation", "Adversarial Exposure Validation", "Continuous Threat Exposure Management" change d'étiquette tous les dix-huit mois mais décrit un seul objet : la reproduction sérielle de représentations de sécurité, chacune justifiant l'achat de la suivante, aucune ne mesurant la résistance à un adversaire réel. La littérature produit des taxonomies internes en expansion permanente (pentest vs red team vs BAS vs adversary emulation vs AEV) et ne pose jamais la question de fond : une simulation contrôlée peut-elle, par construction, mesurer la résistance à un adversaire non contrôlé ?

Le passage du ponctuel au continu, que le marché de la validation présente comme un dépassement du pentest, change la fréquence de la mesure, pas sa nature. Photographier un répertoire une fois par an ou le filmer en continu produit la même image répétée : le catalogue reste le catalogue, exécuté plus souvent. La cadence a augmenté, l'optique n'a pas bougé.

La réponse est non. Toute évaluation de sécurité fondée sur le rejeu d'un répertoire connu mesure la couverture défensive contre ce répertoire, pas la résistance à un adversaire. Les deux sont liés mais pas identiques. La part de la menace réelle qui se situe en dehors du répertoire est précisément la part qui fait mal. Et plus une organisation optimise sa défense contre le répertoire (qu'il vienne d'ATT&CK, d'une plateforme de simulation, de son red team interne), plus elle se rend lisible à ceux qui savent contre quoi elle s'est entraînée.

Le défaut ne loge ni dans les plateformes de validation, ni dans MITRE, ni dans les red teams. Il loge dans la prétention à mesurer la sécurité par la simulation. La simulation mesure l'hygiène : ai-je patché ? Mes credentials sont-ils corrects ? Ma segmentation tient-elle ? L'hygiène est utile. La sécurité est autre chose. Confondre les deux, c'est confondre la représentation avec la chose. Et cette confusion est ce qui a permis à l'industrie de construire des architectures non défendables pendant trente ans sans que personne le voie, parce que les représentations produisaient suffisamment de scores, de rapports et de dashboards pour dispenser de la question : le système était-il défendable par conception ?

Revenir à l'objet

La sortie du circuit ne passe pas par une meilleure simulation, un meilleur benchmark, un meilleur score. Un score de représentation amélioré reste un score de représentation.

La sécurité d'un système est une propriété qui émerge de la façon dont il est conçu, ou qui n'émerge pas, et qu'aucune couche de validation ne peut reconstituer après coup. Aucun empilement de contrôles ne la remplace. La segmentation native, le moindre privilège par construction, la capacité d'absorber un incident sans effondrement en cascade, la lisibilité du système par ses propres opérateurs, la capacité de rendre l'attaquant observable au moment où il agit sans avoir besoin de l'anticiper : ce ne sont pas des contrôles. Ce sont des choix de conception qui rendent les contrôles soit superflus, soit efficaces. Et aucun de ces choix ne peut être surajouté à un système qui ne les a pas à la base, sauf à reconstruire le système.

MCPSHIELD l'entrevoit dans S_compose sans en tirer la conséquence. Si la sécurité naît de la composition, elle se décide au moment de l'architecture, pas au moment de l'instrumentation. Un protocole dont 65 % des outils modifient l'environnement externe, sans gouvernance d'entrée, sans preuve de sécurité compositionnelle, ne sera pas rendu sûr par quatre couches formelles empilées après coup.

Simbian l'entrevoit dans l'attribution gap sans le formuler. Si l'agent croise l'évidence sans la reconnaître, le problème n'est pas dans le modèle mais dans le dispositif qui suppose qu'un agent sans connaissance du contexte opérationnel peut enquêter. L'enquête exige une compréhension du réseau qu'aucun prompt ne transmet et qu'aucune base de logs ne contient. Cette compréhension est une propriété de l'architecture de supervision, pas du modèle.

Sichuan l'entrevoit dans le résultat baseline sans l'assumer. Si un agent généraliste avec trois lignes de prompt fait jeu égal avec des outils spécialisés, la valeur ajoutée de la spécialisation est marginale. Ce qui reste comme valeur défendable pour le marché légitime du test offensif, c'est précisément ce que les outils académiques ne font pas : le sandbox, l'audit d'instructions, la vérification des résultats, la gestion du périmètre. La couche de gouvernance, pas la couche d'intelligence.

Le travail de conception sécurisée ne produit ni score ni dashboard présentable en keynote. Il est lent, non scriptable, et il ne se prête pas à l'automatisation par LLM. Il demande de penser le système avant de le construire, la composition avant de l'assembler, la défendabilité avant d'instrumenter la défense. C'est le travail que l'industrie a cessé de faire quand elle a découvert qu'elle pouvait le remplacer par de la validation continue. C'est le seul qui ait un rapport avec la chose elle-même.

Ce que je ne sais pas

La thèse selon laquelle la simulation contrôlée ne mesure pas la résistance à un adversaire réel est logiquement solide mais empiriquement difficile à calibrer. L'écart entre le score d'un exercice et la résistance à une attaque réelle n'a jamais été mesuré de façon systématique. Les rares cas documentés (le red team CISA 2024 sur une infrastructure critique américaine, les retours d'expérience post-SolarWinds) suggèrent un écart important. La base empirique reste mince.

Le benchmark Simbian comporte des biais méthodologiques. Simbian commercialise une plateforme SOC : la conclusion "les modèles seuls ne suffisent pas, il faut un wrapper opérationnel" sert directement leur pitch. Le test est en zéro-shot, sans playbook, sans détection engineering, sans librairie de règles Sigma. Un agent mieux équipé donnerait probablement des résultats différents. La conclusion "les LLM ne savent pas enquêter seuls" est vraie dans ces conditions. Je ne sais pas si elle tient avec un outillage adapté.

Le papier Sichuan teste sur le benchmark XBOW, éloigné d'un environnement d'entreprise réel (Active Directory, segmentation réseau, EDR, contraintes de furtivité). La conclusion "un agent généraliste fait jeu égal avec les outils spécialisés" vaut sur ce benchmark. La transposition au red team en production reste à démontrer.

Les trois papiers datent d'avril 2026. Les scores précis vieilliront ; le mécanisme qu'ils documentent, non. L'extension du benchmark Simbian à seize modèles depuis avril n'a pas déplacé le mur. Ce sont les chiffres qui sont datés, pas la structure qu'ils exposent.

Je ne sais pas si la critique épistémologique de la simulation offensive a déjà été formalisée dans la littérature académique de cybersécurité. Un pont étroit a été franchi : MIRROR (Fujitsu, juin 2026) formalise la distinction entre taux de succès brut et taux de succès réellement inédit dans le red-teaming automatisé, et montre que 73 à 84 % des attaques « réussies » des outils concurrents sont des rejeux exacts de graines connues⁸. Le pont large, en revanche, reste non franchi : la question de savoir si une simulation contrôlée peut, par construction, mesurer la résistance à un adversaire non contrôlé n'a pas de formalisation en cybersécurité. La littérature militaire sur les limites du wargaming et la critique des stress tests bancaires post-2008 portent cet argument⁷. Personne ne semble avoir fait le pont vers le cyber. Cette absence peut signifier que l'argument est trivial et déjà intériorisé par les praticiens, ou qu'il est inconfortable et systématiquement esquivé.

Conclusion

Trois études indépendantes, publiées le même mois, documentent la même opération à trois étages. L'agent offensif hallucine le flag. L'agent défensif croise l'évidence sans la nommer. L'architecture formelle revendique une couverture dont la couche centrale est avouée impraticable. À chaque étage, la représentation se substitue à la chose, et le circuit de production de scores, de benchmarks et de couvertures continue de tourner, chaque couche validant la précédente, aucune ne touchant le système réel. Pendant ce temps, à Las Vegas, le marché vendait la représentation en plus autonome, et la valorisait à un quart de milliard.

L'industrie a confondu la mesure de l'hygiène avec la mesure de la sécurité, et la simulation de l'attaquant avec la connaissance de l'attaquant. Le premier est utile. Le second est une erreur de catégorie dont le LLM, en industrialisant la simulation, achève la démonstration. 859 runs, 10 milliards de tokens, 177 000 outils, zéro architecture.

La sortie ne viendra pas d'un meilleur score. Elle viendra du retour à un travail que l'industrie a cessé de faire : concevoir des systèmes dont la sécurité est une propriété native, pas un attribut surajouté puis validé par un répertoire. Ce travail est lent, coûteux, non automatisable et ne produit rien de montrable en keynote. Il reste le seul qui ait un rapport avec l'objet réel.

Merci de m’avoir lu.

Vingt-deuxième article d'une série sur les failles structurelles de la cybersécurité occidentale :

• Article 1 : La vulnérabilité de la gestion des vulnérabilités
• Article 2 : La dépendance européenne aux standards américains
• Article 3 : Les États, architectes cachés du marché noir des vulnérabilités
• Article 4 : L'IA ou l'effondrement du modèle défensif occidental
• Article 5 : Desert Power — survivre sans l'Empire
• Article 6 : I Am Altering the Deal
• Article 7 : Le dernier canal
• Article 8 : Lord of Cyber War
• Article 9 : Les faucons du numérique
• Article 10 : They Live... we sleep
• Article 11 : Soylent Green
• Article 12 : Ghost in the Binary
• Article 13 : Now You See Me
• Article 14 : The Prestige
• Article 15 : Pitch Black
• Article 16 : The Thing That Should Not Be
• Article 17 : Status: clean
• Article 18 : Le Guépard
• Article 19 : The Usual Suspects
• Article 20 : Kill one, spawn many
• Article 21 : The Conversation

Sources

¹ Black Hat USA 2026, Las Vegas, 1-6 août 2026. Annonces d'éditeurs de sécurité recensées par SecurityWeek, « Black Hat USA 2026 – Summary of Vendor Announcements » (parties 1 et 2). Agents défensifs revendiquant anticipation des chemins d'attaque, prédiction d'enchaînement de techniques, émulation continue de l'adversaire et validation autonome de l'exploitabilité. La levée de 250 millions de dollars concerne Horizon3.ai, éditeur de l'agent de pentest autonome NodeZero : Series E annoncée le 3 août 2026, valorisation portée à plus de 2 milliards de dollars (triplée en quatorze mois), co-menée par NightDragon et NEA, avec entrée d'investisseurs stratégiques dont Qualcomm, SAIC et l'EDBI singapourien. TechCrunch relie la levée à la révélation, la semaine précédente, que les modèles de deux laboratoires d'IA avaient pénétré des systèmes hors de leur périmètre. https://www.securityweek.com/black-hat-usa-2026-summary-of-vendor-announcements-part-1/ — https://techcrunch.com/2026/08/03/horizon3-hits-2-billion-valuation-with-250m-series-e-as-ai-threats-escalate/

² Chuvakin A. & Rochford O., analyse du décalage entre les promesses des plateformes de SOC agentique et leur adoption réelle en production, fondée sur plus de 30 briefings vendeurs et des entretiens de RSSI, Help Net Security (26 mars 2026). Les praticiens qui déploient décrivent un déploiement superficiel, des cas d'usage contraints, et un schéma de communication vendeur qui attribue les limites du produit à la psychologie de l'acheteur. Anton Chuvakin est advisor au bureau du CISO de Google Cloud. https://www.helpnetsecurity.com/2026/03/26/future-ai-soc-vendor-claims/

³ Peng J., Li Z., You C. et al. « Hackers or Hallucinators? A Comprehensive Analysis of LLM-Based Automated Penetration Testing. » Sichuan University, Tsinghua University, NTU, NUS, NUDT et al. arXiv:2604.05719v1, avril 2026. 13 frameworks AutoPT, 2 baselines, 10 milliards de tokens, 1 500 logs relus manuellement par 15 chercheurs sur 4 mois. Benchmark XBOW. Ablations sur Claude Opus 4.6, GPT-5.2, Gemini-Pro-3.1, DeepSeek-Reasoner-v3.2. https://arxiv.org/abs/2604.05719

⁴ Simbian AI. « Cyber Defense Benchmark. » arXiv:2604.19533v3, avril 2026. 11 modèles frontier, 859 runs, 26 campagnes, 93 sous-techniques ATT&CK. Corpus OTRF/Mordor, bases SQLite 75 000 à 135 000 logs Windows. Le leaderboard live de Simbian a depuis étendu l'évaluation à 16 modèles sur 1 144 exécutions (Opus 4.8, GPT-5.5, GLM-5.2 inclus), sans qu'aucun ne franchisse le seuil de passage. https://arxiv.org/abs/2604.19533 — leaderboard : https://simbian.ai/research/cyber-defense-benchmark

⁵ Acharya S., Gupta M. « MCPSHIELD: A Unified Security Framework for Model Context Protocol. » Carnegie Mellon University, University of Michigan. arXiv:2604.05969, avril 2026. Taxonomie de menaces (7 catégories, 23 vecteurs, 4 surfaces), architecture defense-in-depth 4 couches, couverture théorique revendiquée 91 %. Données sur la croissance du parc MCP : Stein et al. (177 000 outils, 97 M téléchargements SDK/mois, part d'outils "action" passée de 27 % à 65 %). Le 28 juillet 2026, trois mois après ce papier, MCP a publié sa plus large révision depuis le lancement (spécification 2026-07-28), rendant le protocole stateless au niveau du transport. Le changement est motivé par la scalabilité, pas par la sécurité, et ne touche aucun des trois points ci-dessus : la couche L-IFT reste intractable à travers le raisonnement d'un LLM, l'attestation prouve toujours la non-mutation et non la bénignité, et la sécurité compositionnelle (S_compose) reste un défi ouvert. Le passage au stateless accélère au contraire la mutation vers l'infrastructure d'exécution distribuée que le papier documentait, en rendant le déploiement d'outils trivial sur toute infrastructure HTTP. https://arxiv.org/abs/2604.05969 — spécification 2026-07-28 : https://modelcontextprotocol.io/specification/2026-07-28/changelog

⁶ Voir dans cette série : « Now You See Me » (couverture SIEM ATT&CK à 21 %, CardinalOps), « The Prestige » (D3FEND : 34 % Detect, 4 % Deceive), « The Thing That Should Not Be » (ATLAS : absence de toute utilisation dans les rapports de menaces IA). Les benchmarks de connaissance CyberMetric, SecBench et CTI-Bench testent la mémoire déclarative ; le Cyber Defense Benchmark teste la cognition opérationnelle. L'écart entre les deux classes de métriques quantifie la distance entre ce que l'industrie mesure et ce qu'elle prétend mesurer.

⁷ Perla P., The Art of Wargaming, Naval Institute Press, 1990, pour la critique militaire des limites de la simulation contrôlée. La distinction entre simulation et adversité réelle y est formalisée quarante ans avant le débat AutoPT.

⁸ Fujitsu Research of Europe / Fujitsu Limited. « MIRROR: Novelty-Constrained Memory-Guided MCTS Red-Teaming for Agentic RAG. » arXiv:2606.26793v1, juin 2026. Benchmark ART-SAFEBENCH publié sur Hugging Face (Fujitsu/agentic-rag-redteam-bench). PAIR, TAP et PS affichent 58–77 % d'ASR brut mais 73–84 % de rejeu exact ; Novel-ASR après déduplication : 6–9 %. La Novelty Gate de MIRROR est en correspondance exacte (normalisation whitespace/alphanumérique), les auteurs reconnaissent que les paraphrases passent le filtre. https://arxiv.org/abs/2606.26793