SecRespond révèle que 23 modèles d’IA de pointe passent à côté d’intrusions silencieuses

SecRespond a fait son entrée dans Google News avec un constat sans détour : aucun des 23 modèles de pointe n’a mené à bien la détection et la remédiation sur l’un des hôtes compromis testés. Les agents ont bien mieux traité les alertes visibles que les éléments silencieux, révélant un écart entre le triage assisté par IA et la réponse autonome aux incidents.

Des chercheurs d’Alibaba Group ont soumis l’article SecRespond le 29 juillet 2026. Ils ont testé des modèles issus de plusieurs grandes familles via OpenCode, un environnement agentique qui permet aux modèles d’inspecter des fichiers et d’utiliser des outils en ligne de commande.

Le test commence après qu’un attaquant a déjà réussi son intrusion. Ce détail crée le conflit au cœur de l’étude. Les agents IA peuvent suivre une alerte, mais un centre opérationnel de sécurité a besoin d’enquêteurs capables de trouver aussi les menaces que personne n’a signalées.

SecRespond remet donc en cause une promesse courante de l’automatisation. Un modèle qui résume les alertes peut réduire la charge de travail des analystes, mais cela n’en fait pas pour autant un intervenant indépendant en réponse à incident. Le benchmark a mis en évidence cette différence dans les artefacts disque, les mécanismes de persistance, les étapes de nettoyage incomplètes et les plans de remédiation non vérifiés.

Ce que le benchmark SecRespond a réellement changé

SecRespond déplace la cible de l’évaluation, de l’interprétation des alertes vers l’enquête sur une machine déjà compromise.

De nombreux tests de cybersécurité commencent avant la compromission. Ils demandent à un modèle d’identifier une vulnérabilité, de résoudre un défi capture-the-flag, de classer un malware ou de raisonner sur des journaux de sécurité sélectionnés. Ces tâches mesurent des capacités utiles, mais réduisent l’incertitude qui définit une véritable violation.

SecRespond commence plus tard. Chaque agent reçoit un instantané disque forensique figé provenant d’un hôte cloud compromis. Il reçoit également des résultats synthétiques similaires à des alertes, des analyses de vulnérabilités et des vérifications de référentiel de sécurité issues d’un produit de protection des hôtes.

Un instantané disque forensique est une copie préservée des fichiers et artefacts d’un système à un instant donné. Il peut contenir des preuves jamais mentionnées par les alertes, notamment des fichiers de démarrage modifiés, des comptes dérobés, des journaux effacés, des tâches planifiées ou des binaires malveillants.

L’agent doit examiner ces éléments et reconstituer ce qui s’est passé. Il produit ensuite des rapports couvrant les intrusions, les vulnérabilités, les risques liés au référentiel et la remédiation. La tâche exige également un fichier de progression, créant une trace de l’enquête plutôt que d’accepter une seule réponse finale soignée.

Le benchmark comprend 10 cyber-ranges, c’est-à-dire des environnements isolés conçus pour reproduire des incidents de sécurité. Ces environnements couvrent quatre types de points d’entrée initiaux, 21 techniques du catalogue MITRE ATT&CK et cinq systèmes d’exploitation.

Les chercheurs ont traduit ces environnements en 52 éléments de capacité et 280 points de contrôle détaillés. Les points de contrôle vérifient si un agent a trouvé des preuves concrètes, les a correctement attribuées, a recommandé une action adaptée et a couvert les vérifications nécessaires.

La détection et la planification de la remédiation reçoivent des scores distincts. La détection atteint au maximum trois points par point de contrôle applicable. La planification en atteint au maximum deux, tandis que les points de contrôle qui ne s’appliquent pas à une dimension sont exclus de cet agrégat.

Cette séparation est importante, car trouver un fichier malveillant ne répond pas à la question de savoir ce que les intervenants doivent faire ensuite. Une réponse sûre peut nécessiter d’isoler un hôte, de préserver les preuves, d’arrêter les processus, de supprimer la persistance, de faire tourner les identifiants, de bloquer l’infrastructure, de restaurer les services et de vérifier le rétablissement.

Le dataset SecRespond public comprend les prompts de tâche, les supports d’évaluation, les checklists, les résultats de sécurité synthétiques et les archives forensiques. Sa publication rend l’affirmation centrale vérifiable par des équipes au-delà des auteurs d’origine.

SecRespond définit également une frontière plus stricte pour la réponse à incident par IA. Un agent n’obtient pas tous les crédits parce qu’il a probablement vérifié quelque chose. Son rapport doit indiquer la découverte et citer les preuves qui satisfont la checklist concernée.

Cette règle transforme un langage de sécurité vague en performance mesurable. « Enquêter sur une activité suspecte » ne revient pas à identifier un processus, un fichier, un compte, un endpoint ou un chemin de persistance précis. « Corriger le serveur » ne revient pas à fournir un plan de rétablissement complet, séquencé et vérifié.

La couverture de Google News s’est concentrée sur l’échec majeur observé sur 23 modèles. Le changement plus profond est méthodologique. SecRespond demande si un agent peut poursuivre des pistes qui ne lui ont jamais été fournies, puis relier ces découvertes à un processus de nettoyage défendable.

Pourquoi l’attention de Google News compte pour les acheteurs de sécurité IA

Le benchmark incite les fournisseurs et les responsables de la sécurité à distinguer l’assistance aux alertes de la réponse autonome aux incidents.

L’IA aide déjà les centres opérationnels de sécurité à résumer les alertes, enrichir les indicateurs, rechercher de la documentation, rédiger des requêtes et préparer des notes de dossier. Ces flux de travail restent précieux, car les analystes font souvent face à des preuves fragmentées et à des tâches administratives répétitives.

Cependant, SecRespond mesure un niveau d’indépendance plus élevé. Un intervenant autonome doit décider où enquêter, reconnaître les preuves manquantes, tester des explications concurrentes et poursuivre après la résolution de l’alerte la plus évidente.

Le résultat central du benchmark montre pourquoi cette distinction est importante. Sur les 23 modèles évalués, aucun agent n’a atteint une détection et une remédiation complètes sur un seul cyber-range.

Le meilleur modèle global de l’expérience rapportée était Claude Opus 4.7. Il a atteint un score moyen de points de contrôle au niveau des environnements de 79,0 % pour la détection et de 65,7 % pour la planification.

L’article rapporte également une moyenne de 72,4 % lorsque ces dimensions sont combinées pour le modèle en tête. Cette performance a tout de même laissé des artefacts malveillants intacts et une remédiation incomplète, notamment dans les environnements présentant des chaînes d’attaque plus longues et plus étendues.

Parmi les autres résultats de premier plan figurent Claude Opus 4.6 avec 78,2 % en détection et 58,0 % en planification. GLM-5.1 a atteint 76,3 % et 59,2 %, tandis que Qwen3.7 Plus a atteint 75,6 % et 58,8 %.

Ces chiffres ne doivent pas être interprétés comme un classement général des modèles sous-jacents. Ils décrivent un environnement agentique, une version de benchmark, une conception de tâche et un processus d’évaluation spécifiques.

Les résultats révèlent plutôt un schéma d’échec commun. Les modèles ont trouvé plus fiablement les preuves liées à des alertes existantes que les preuves nécessitant une recherche non sollicitée sur le disque.

Ce schéma met sous pression les fournisseurs de sécurité qui emploient des libellés généraux tels que « analyste IA » ou « SOC autonome ». Les acheteurs doivent demander quelles parties du cycle de réponse le système réalise réellement sans piste créée par un humain.

Un produit peut résumer correctement une alerte endpoint tout en négligeant un second mécanisme de persistance. Il peut recommander de supprimer un binaire malveillant sans arrêter son processus, retirer son chargeur, faire tourner les identifiants exposés ou vérifier le rétablissement du service.

Chaque étape omise modifie le résultat opérationnel. Un attaquant peut revenir via un compte, une tâche planifiée, un webshell, un service, une entrée de registre ou un hook de shell laissés intacts. Une première action techniquement correcte peut donc créer une fausse impression de confinement.

Les responsables de la sécurité doivent également distinguer la qualité de l’enquête de la qualité du rapport. Les modèles produisent souvent des explications fluides, mais SecRespond évalue si ces explications contiennent les preuves et les détails de remédiation requis.

C’est un problème familier dans les travaux intensifs en connaissances. Un récit convaincant peut masquer une récupération d’informations incomplète. Les équipes qui construisent une base de connaissances consultable font face à une exigence similaire : les conclusions doivent rester traçables jusqu’aux sources.

Le benchmark rend cette traçabilité concrète pour la réponse à incident. Un agent doit montrer quel artefact étaye chaque conclusion et quelle action traite chaque condition identifiée.

La visibilité offerte par Google News peut faire sortir cette distinction du cercle des chercheurs en benchmarks. Les équipes achats, les RSSI, les prestataires de sécurité managée et les groupes d’audit interne disposent désormais d’un exemple public montrant que « traite les alertes » et « traite les incidents » ne sont pas des affirmations équivalentes.

Le véritable angle mort est l’enquête non guidée

Le comportement le plus faible des modèles apparaît lorsqu’un incident ne laisse aucune alerte évidente pointant vers l’artefact suivant.

SecRespond répartit les performances en cinq domaines de capacité. Ils couvrent les entités d’intrusion, les mécanismes de persistance, les risques liés au référentiel, les risques de vulnérabilité et la qualité globale de l’enquête et de la réponse.

Une entité d’intrusion est un objet malveillant concret, tel qu’un processus, un fichier, un endpoint réseau ou un artefact altéré. Les modèles ont obtenu leurs meilleurs résultats dans cette catégorie, car ces objets correspondaient souvent à des signaux de sécurité visibles.

Tous modèles confondus, la détection moyenne a atteint 75,4 % pour les entités d’intrusion. Plusieurs systèmes de tête ont fait nettement mieux, dont Qwen3.7 Plus avec 88,4 % et Claude Opus 4.6 avec 86,0 %.

Les mécanismes de persistance ont produit un résultat différent. La persistance désigne les modifications qui permettent à l’accès de l’attaquant de survivre à un redémarrage ou à un nettoyage initial. Parmi les exemples figurent les tâches planifiées, les services, les hooks de démarrage du shell, les webshells, les portes dérobées de comptes et les abonnements Windows Management Instrumentation.

La détection moyenne est tombée à 58,8 % pour la persistance. Cette baisse est importante, car la persistance est précisément ce que les intervenants doivent trouver avant de déclarer un hôte sain.

Le benchmark ne montre pas que les modèles sont dépourvus de tout raisonnement forensique. Ils peuvent relier une alerte à un processus ou à un fichier pertinent et décrivent souvent correctement la menace immédiate. L’échec survient lorsque l’enquête doit s’étendre au-delà de ce point de départ.

Prenons un serveur web compromis. Une alerte peut identifier un processus malveillant ou une connexion sortante. Suivre ce signal peut révéler un exécutable, mais une enquête complète doit se demander comment l’attaquant est entré, quels identifiants ont été exposés et ce qui survivra à l’arrêt du processus.

L’intervenant peut aussi devoir inspecter les scripts de démarrage, les définitions de services, les entrées cron, les comptes utilisateurs, les historiques de commandes, les répertoires d’applications et les journaux modifiés. Aucune alerte unique n’identifie nécessairement ces emplacements.

Cela crée un problème de recherche aux limites incertaines. L’agent doit décider quelles hypothèses méritent d’être testées et combien de temps poursuivre. Il doit reconnaître que l’absence d’un artefact n’élimine pas les autres voies de persistance.

Les agents fondés sur les modèles de langage actuels optimisent souvent leur travail autour des preuves déjà présentes dans le contexte. Les alertes créent des points d’ancrage très saillants ; l’agent peut donc consacrer son budget à expliquer ces points plutôt qu’à rechercher des preuves non mentionnées.

Les chaînes d’attaque plus longues amplifient cette faiblesse. Chaque technique supplémentaire introduit une branche, un type d’artefact, un horodatage, un compte ou un service supplémentaire que le modèle doit corréler.

L’article a constaté que les performances diminuaient à mesure que les attaques devenaient plus longues et plus étendues. Ce résultat correspond au défi opérationnel : la réponse à incident n’est pas une décision de classification unique, mais une séquence de jugements liés sous information incomplète.

Un benchmark de threat hunting distinct, publié en 2026, a rapporté un problème connexe. Cinq modèles de pointe ont recherché des journaux bruts d’événements Windows issus de 26 campagnes d’attaque, et le meilleur modèle n’a trouvé qu’une faible fraction des événements malveillants.

Les deux études testent des flux de travail différents, leurs scores ne sont donc pas directement comparables. Elles suggèrent toutefois toutes deux que la recherche non guidée reste plus difficile que le raisonnement sur des preuves présélectionnées.

C’est le renversement central du benchmark. Les agents semblent les plus capables là où les outils de sécurité conventionnels ont déjà réduit l’incertitude. Ils deviennent moins fiables là où les enquêteurs humains apportent le plus de valeur en interrogeant ce que l’alerte n’a pas révélé.

Une équipe de sécurité peut néanmoins utiliser l’IA de manière productive dans ce cadre. Le modèle peut résumer les éléments de preuve, proposer des hypothèses, rédiger des requêtes, comparer des artefacts et tenir une chronologie de l’enquête.

Le saut dangereux consiste à traiter ces capacités comme la preuve que le modèle a exploré l’ensemble de l’incident. SecRespond montre qu’une réponse éloquente peut coexister avec une persistance non découverte et une reconstitution incomplète de l’activité de l’attaquant.

Les scores de détection masquent un écart plus important en matière de remédiation

Trouver davantage d’éléments de preuve ne s’est pas traduit par des plans de nettoyage aussi complets, faisant de la remédiation le deuxième échec majeur du benchmark.

Chaque modèle évalué a obtenu un meilleur score en détection qu’en planification. Pour GPT-5.5, l’écart rapporté a atteint 34,7 points de pourcentage.

Les chercheurs attribuent ce schéma au fait que les agents appliquent un premier correctif évident tout en omettant les actions restantes. Ce comportement ressemble à une troncature de checklist : une fois que l’objet malveillant central reçoit une réponse, le modèle se comporte comme si l’incident était résolu.

Dans la réalité, la remédiation s’arrête rarement à une suppression ou à une modification de configuration. Un intervenant doit prendre en compte les dépendances, la préservation des preuves, l’impact sur l’activité, la continuité de service, l’exposition des identifiants et les voies d’accès alternatives de l’attaquant.

Le score de planification de SecRespond évalue si une action est correcte et complète. Il examine également la vérification et les effets secondaires lorsque le point de contrôle pertinent l’exige.

La vérification n’est pas une simple formalité. Un plan visant à supprimer une tâche planifiée devrait confirmer que cette tâche n’existe plus et que sa charge utile ne peut pas être lancée par un autre mécanisme.

Un plan visant à bloquer l’adresse d’un attaquant doit traiter, le cas échéant, à la fois le trafic entrant et sortant. Il doit aussi éviter de laisser entendre qu’un blocage d’adresse supprime les logiciels malveillants, les identifiants volés ou la persistance déjà présents sur l’hôte.

Les problèmes de configuration standardisés se sont révélés plus faciles. Claude Opus 4.7 a atteint 74,8 % en planification pour les risques de référence et 72,6 % pour les risques de vulnérabilité.

Ces tâches correspondent souvent à des actions connues, comme renforcer une configuration ou mettre à jour les logiciels concernés. L’agent peut retrouver un schéma de remédiation reconnaissable et l’appliquer au constat.

La qualité de l’enquête et de la réponse est restée bien plus faible. Les performances moyennes de planification dans cette catégorie n’ont atteint que 31,8 %.

Cette catégorie couvre les travaux qui reposent sur la synthèse plutôt que sur un correctif connu. Elle inclut la reconstitution de la chaîne d’attaque, la qualité des preuves, l’honnêteté face à l’incertitude, l’exhaustivité, la vérification et la prise en compte de l’impact opérationnel.

Le meilleur résultat de détection dans cette catégorie a atteint 75,5 %. Presque tous les modèles sont restés sous les 50 % en planification, selon l’article.

Ces résultats fragilisent une stratégie simple de passage à l’échelle. Donner davantage d’alertes à un modèle ne crée pas automatiquement un plan de réponse complet. Des constats plus visibles peuvent au contraire produire davantage de recommandations déconnectées.

Un plan crédible a besoin d’un ordre d’exécution. Les équipes peuvent isoler une machine avant de la modifier, préserver les preuves volatiles avant d’arrêter des processus et faire tourner les identifiants après avoir déterminé l’étendue de l’exposition.

Elles doivent également prendre en compte le retour arrière et les services. Supprimer un composant compromis sans comprendre ses dépendances peut interrompre la production ou détruire des preuves nécessaires à l’attribution.

SecRespond évalue des plans rédigés plutôt qu’une remédiation en direct sur des systèmes de production. Cela limite ce que le benchmark peut établir, mais maintient aussi la question de sécurité au premier plan.

Si un modèle ne peut pas décrire de manière cohérente une remédiation complète et vérifiée dans un environnement contrôlé, les organisations ont peu de raisons de lui accorder une autorité illimitée sur un hôte actif.

Le benchmark soutient donc un modèle opérationnel plus restreint. L’IA peut suggérer des actions, organiser les preuves et signaler les champs manquants, tandis que les intervenants humains conservent l’approbation des étapes de confinement et de rétablissement.

Cette organisation n’est pas un rejet de l’automatisation des SOC. C’est une réponse à l’asymétrie spécifique des données. Les systèmes identifiaient mieux les objets connus qu’ils ne garantissaient que chaque conséquence reçoive un traitement sûr.

Les équipes de sécurité devraient refléter cette asymétrie dans les contrôles d’accès. Un accès forensique en lecture seule présente un risque différent de l’autorisation de tuer des processus, supprimer des fichiers, désactiver des comptes ou modifier une politique réseau.

Un agent qui manque un artefact caché produit un rapport incomplet. Un agent qui agit sur la base de ce rapport incomplet peut perturber le rétablissement tout en laissant intacte la voie alternative de l’attaquant.

Ce que les chiffres ne prouvent pas

SecRespond apporte des preuves solides d’une limitation partagée, mais ne constitue pas un verdict final sur chaque modèle ou configuration de SOC de production.

L’article est une prépublication arXiv plutôt qu’un résultat issu d’une évaluation par les pairs achevée. Ses auteurs comptent des chercheurs de Tongyi Lab et Alibaba Cloud, et le benchmark évalue les modèles au moyen d’un seul harness représentatif.

Le choix d’OpenCode aide à standardiser l’utilisation des outils entre les systèmes. Cela signifie également que les résultats mesurent une combinaison modèle-harness, et non une capacité abstraite du modèle détachée des prompts, des outils, de la gestion du contexte et de la politique d’exécution.

Un échafaudage différent peut modifier les performances. Un agent de réponse aux incidents pourrait utiliser une checklist d’enquête obligatoire, des utilitaires forensiques spécialisés, une récupération à partir de procédures internes, plusieurs agents coopérants ou des scripts de validation déterministes.

SecRespond reste utile parce que ces améliorations peuvent être testées sur les mêmes scénarios. Toutefois, les chiffres publiés ne doivent pas être considérés comme des limites permanentes pour chaque famille de modèles.

L’évaluation utilise aussi un processus de LLM-as-a-judge, ce qui signifie que des modèles de langage notent les rapports générés au regard de checklists détaillées. Trois juges propriétaires ont été utilisés indépendamment afin de réduire la dépendance à un seul évaluateur.

Ces juges étaient Claude Opus 4.7, Gemini 3.1 Pro et GPT-5.4 Pro. Plusieurs juges réduisent les biais individuels, mais n’éliminent pas tous les problèmes de calibration.

Un évaluateur pourrait interpréter une formulation incomplète différemment d’un spécialiste humain de la forensic. Il pourrait également récompenser un langage explicite dans le rapport sans déterminer pleinement si le processus d’enquête sous-jacent était solide.

Les consignes de notation tentent de maîtriser ce risque. Les juges doivent citer des preuves et n’accorder de crédit que pour le contenu explicitement présent dans les rapports.

Les 280 points de contrôle du benchmark apportent une structure supplémentaire. Pourtant, toute checklist reflète des choix concernant les artefacts, les étapes de réponse et les qualités qui méritent d’être pondérées.

Les 10 scénarios sont suffisamment variés pour révéler des comportements répétés. Ils ne couvrent pas tous les systèmes d’exploitation, architectures cloud, plateformes d’identité, produits endpoint ou techniques d’attaque.

Les environnements sont également contrôlés. Les chercheurs ont provisionné et compromis les hôtes pour le benchmark, puis assaini les identifiants et les données personnelles.

Cette conception permet la reproductibilité et évite d’exposer des informations de production. Elle ne peut pas reproduire intégralement le bruit, la télémétrie incomplète, les contraintes organisationnelles et les dépendances métier d’un incident d’entreprise en conditions réelles.

Un résultat illustre aussi la manière dont les comportements de sécurité peuvent affecter la couverture du benchmark. Claude Opus 4.7 a refusé la tâche npm-worm ; l’article a donc omis ce modèle du tableau détaillé des points de contrôle du scénario.

Un refus peut réduire l’utilité opérationnelle lors d’une enquête défensive légitime. Il peut aussi refléter l’effort d’un fournisseur pour empêcher que l’assistance à double usage ne dérive vers des conseils nuisibles.

SecRespond ne tranche pas cet arbitrage de politique. Il montre qu’un déploiement sûr exige des définitions de tâches qui distinguent le travail forensique autorisé des instructions offensives.

Les auteurs du benchmark indiquent que les preuves publiées proviennent d’environnements isolés et ne contiennent pas de chaînes d’exploitation exécutables. Les ressources publiques sont destinées à la recherche défensive.

Cette restriction compte pour interpréter les affirmations sur la réponse « dans le monde réel ». Les scénarios recréent des compromissions de bout en bout sur de véritables protocoles réseau, mais le paquet publié contient des preuves forensiques assainies plutôt que des outils d’attaque actifs.

Il n’existe pas non plus d’étude de terrain indépendante montrant comment les scores SecRespond se traduisent en temps d’analyste économisé, en réduction de la gravité des incidents ou en amélioration de la vitesse de confinement. Ces résultats exigent des évaluations au sein d’équipes opérationnelles.

Pour les acheteurs, la lecture correcte doit donc rester mesurée. Le benchmark remet fortement en cause les affirmations non étayées de réponse autonome aux incidents. Il ne montre pas que l’assistance par IA n’a aucune valeur dans un SOC dirigé par des humains.

Il n’établit pas non plus qu’un modèle nommé restera en tête dans les versions futures. La série Claude rapportée s’est améliorée au fil des versions, tandis que les progrès n’ont pas été universels dans les autres familles.

L’unité d’évaluation pertinente est le système déployé. Cela inclut le modèle, les outils, les prompts, les autorisations, les sources de récupération, les contrôles de revue, la journalisation et les procédures de rétablissement.

Trois signaux à surveiller après le cycle Google News de SecRespond

Le prochain test sera de savoir si les fournisseurs améliorent la découverte non guidée, la vérification de la remédiation et l’évaluation de production reproductible.

Le premier signal est la reproduction indépendante. Les chercheurs et les fournisseurs de sécurité peuvent exécuter le dépôt du benchmark public avec d’autres harnesses, prompts, outils et versions de modèles.

La reproduction montrera si l’écart des intrusions silencieuses résiste aux changements d’échafaudage. Si des agents forensiques spécialisés manquent encore une persistance non signalée, le jugement central de l’article se renforcera.

Si des procédures de recherche déterministes produisent des gains importants, la leçon change légèrement. Le goulot d’étranglement se situerait moins dans les connaissances du modèle que dans la conception de l’enquête, le routage des outils et la couverture imposée.

Cela affaiblirait toujours les affirmations concernant des agents autonomes à usage général. Cela offrirait aussi une voie d’ingénierie plus claire vers des systèmes plus sûrs.

Le deuxième signal consiste à savoir si les fournisseurs publient des résultats distincts de détection et de remédiation. Un seul chiffre d’« exactitude de réponse aux incidents » peut masquer l’écart de planification mis en lumière par SecRespond.

Des évaluations utiles devraient indiquer ce que le système a trouvé, ce qu’il a manqué, quelle action il a proposée et comment il a vérifié son achèvement. Elles devraient également signaler les refus, les échecs d’outils et les cas nécessitant une intervention humaine.

Surveillez les tests portant spécifiquement sur les mécanismes de persistance. Les améliorations concernant les logiciels malveillants liés aux alertes comptent, mais elles ne répondent pas au principal angle mort du benchmark.

Surveillez également si les plans couvrent l’ampleur du nettoyage. Un agent plus robuste devrait traiter les processus, fichiers, comptes, exécutions planifiées, contrôles réseau, rotation des identifiants, rétablissement des services et validation après remédiation lorsque cela s’applique.

Le troisième signal est la preuve issue de déploiements de SOC supervisés. Les fournisseurs doivent montrer comment leurs agents fonctionnent avec une télémétrie réelle, des procédures internes, des contrôles d’accès et des contrôles d’approbation par les analystes.

Les preuves opérationnelles les plus solides ne se limiteront pas à une étude de cas soignée. Elles incluront les taux d’omission, les taux d’escalade, les affirmations non étayées, la fréquence des corrections et le pourcentage de recommandations que les analystes approuvent sans modification.

Un déploiement crédible devrait préserver une piste d’audit. Les réviseurs doivent pouvoir relier les conclusions aux artefacts et déterminer quelles recherches l’agent a effectuées avant de s’arrêter.

Les organisations devraient également tester les limites d’autorisation. L’enquête en lecture seule, les actions recommandées et l’exécution autonome représentent trois niveaux de risque différents.

SecRespond soutient l’adoption aux deux premiers niveaux tout en imposant une lourde charge de preuve au troisième. Ses résultats ne justifient pas de confier de larges pouvoirs de confinement à un modèle qui n’a pas démontré une découverte exhaustive.

Le titre de Google News s’effacera, mais ce benchmark laisse aux équipes de sécurité une question durable en matière d’achats : que trouve l’agent lorsqu’aucune alerte ne lui indique où chercher ?

Demandez aux fournisseurs de répondre à cette question avec des preuves reproductibles. Demandez ensuite comment le système vérifie chaque étape de remédiation et signale ses incertitudes à un opérateur humain.

Ces réponses révéleront si les produits AI SOC deviennent des enquêteurs ou restent des assistants rapides autour des détections existantes. Pour l’instant, SecRespond place les 23 modèles testés du côté des assistants de cette ligne.