Unit 42 Continuous Frontier AI Defense est lancé, mais aucun modèle n’a dépassé 40 % de couverture

Unit 42 Continuous Frontier AI Defense a été lancé le 22 septembre avec un avertissement marquant : aucun modèle d’IA testé n’a détecté plus de 40 % des vulnérabilités.

Palo Alto Networks répond avec un service de sécurité offensive permanent qui associe plusieurs modèles d’IA, un logiciel d’orchestration propriétaire et des spécialistes humains de la sécurité. Le service recherche continuellement les expositions, vérifie si les attaquants peuvent les exploiter, cartographie les chemins d’attaque et recommande des corrections priorisées.

Ce chiffre phare révèle aussi la tension centrale du service. Les modèles de pointe peuvent automatiser la recherche en sécurité à une échelle qui était récemment impraticable, mais chaque modèle manque encore la plupart des résultats dans des environnements complexes. Palo Alto Networks affirme que la combinaison de Claude Mythos 5, GPT-5.6-Cyber, de modèles à poids ouverts, d’outils spécialisés et de chercheurs de Unit 42 réduit davantage cet écart.

Cette approche met sous pression les programmes traditionnels de tests d’intrusion fondés sur des évaluations annuelles ou trimestrielles. Elle remet également en question les acheteurs qui prévoyaient de choisir un seul modèle cyber de premier plan et de bâtir leur automatisation défensive autour de celui-ci.

Toutefois, le plafond de 40 % provient d’une évaluation de Palo Alto Networks, et non d’un benchmark reproduit indépendamment. L’entreprise n’a pas publié suffisamment de détails méthodologiques pour comparer la couverture, les faux positifs, les coûts ou les résultats de remédiation entre les modèles.

Le lancement importe donc pour davantage que son annonce produit. Il transforme la diversité des modèles en décision d’architecture de sécurité, tout en laissant aux acheteurs le soin de vérifier le niveau de protection supplémentaire réellement apporté par le système combiné.

Unit 42 Continuous Frontier AI Defense transforme les tests en service continu

Le service remplace une évaluation planifiée par un cycle continu de découverte, de validation et de remédiation.

Palo Alto Networks a présenté ce service mondial dans son annonce de lancement du 22 septembre. Il est commercialisé sous forme d’abonnement annuel, avec des options selon les modèles utilisés.

L’entreprise le décrit comme un service de sécurité offensive agentique, dirigé par des experts. Dans ce contexte, agentique signifie que le logiciel peut planifier et exécuter plusieurs étapes de test de sécurité avec une intervention humaine limitée.

Le service commence par une évaluation de référence de l’ensemble du parc. Il poursuit ensuite les tests à mesure que les applications, les identités, les ressources cloud, les dépôts de code source, les API et les actifs réseau évoluent.

Son moteur de tests continus recherche les faiblesses connues et inconnues. Un harnais multimodèle oriente chaque tâche vers le modèle que Unit 42 considère comme le mieux adapté.

Un harnais est la couche logicielle qui entoure un modèle. Il fournit les outils, les instructions, les données cibles, les étapes de validation, les autorisations et les contrôles qui transforment un modèle généraliste en système opérationnel.

Unit 42 indique également que le service valide les chemins d’attaque de bout en bout. Cette distinction importe, car un défaut logiciel ne crée pas automatiquement une voie pratique vers des systèmes sensibles.

Un chemin d’attaque relie plusieurs conditions, telles qu’une application exposée, de faibles contrôles d’identité, des autorisations cloud excessives et des données accessibles. La validation aide à déterminer si ces conditions peuvent entraîner une compromission significative.

Le système génère ensuite des recommandations de remédiation, notamment des corrections priorisées, des recommandations au niveau du code et d’éventuels correctifs virtuels. Un correctif virtuel bloque un comportement malveillant au moyen d’un contrôle de sécurité lorsqu’il est impraticable de modifier immédiatement l’application concernée.

Selon le communiqué de presse de l’entreprise, les abonnements peuvent utiliser des modèles d’Anthropic, d’OpenAI et open source. Chaque configuration utilise un harnais multimodèle.

Cette conception s’appuie sur Unit 42 Frontier AI Defense, lancé en avril 2026. Cette offre précédente était axée sur l’analyse ponctuelle des expositions, un plan de sécurité et un programme de transformation plus large.

Le service de septembre modifie le modèle opérationnel. Au lieu de produire une évaluation et une feuille de route uniques, il continue de tester l’environnement après la mission initiale.

Ce changement reflète une faiblesse réelle des revues de sécurité périodiques. Les systèmes d’entreprise évoluent constamment au gré des déploiements, des mises à jour d’identité, des nouvelles intégrations, des modifications de configuration cloud et des dépendances tierces.

Une évaluation satisfaisante peut devenir obsolète après la version suivante. Les tests continus visent à réduire le délai entre un changement risqué et sa détection.

Les tests continus créent toutefois aussi des obligations opérationnelles. Un système permanent nécessite des inventaires d’actifs fiables, des identifiants contrôlés, des limites de test, une conservation des preuves et des règles d’escalade claires.

Sans ces contrôles, la découverte continue peut devenir une génération continue d’alertes. La valeur du service dépend de la capacité des résultats validés à parvenir aux équipes qui peuvent les corriger.

Pourquoi le plafond de couverture de 40 % compte davantage que le lancement

Palo Alto Networks ne prétend pas qu’un seul modèle de pointe résout la découverte des vulnérabilités. L’entreprise affirme que les divergences entre modèles sont inévitables.

Unit 42 indique qu’aucun modèle unique n’a détecté plus de 40 % des vulnérabilités dans les bases de code d’entreprise et les environnements actifs qu’il a évalués. Il indique également que Claude Mythos 5 et GPT-5.6-Cyber se recoupaient sur moins de 10 % des expositions identifiées.

Prises ensemble, ces affirmations suggèrent que les modèles ont détecté des faiblesses sensiblement différentes. Un modèle classé premier pour le total de résultats pourrait néanmoins manquer des problèmes qu’un autre modèle reconnaît.

C’est le renversement au cœur de l’annonce. Des modèles cyber plus capables ne centralisent pas nécessairement le travail de sécurité autour d’un seul gagnant. Ils peuvent rendre plus précieuse l’orchestration de différents modèles.

Les modèles diffèrent par leurs données d’entraînement, leurs méthodes de renforcement, leurs garde-fous, leur gestion du contexte, leur utilisation des outils et leur comportement de raisonnement. Ils peuvent aussi aborder la même cible avec des hypothèses différentes.

Un modèle peut mieux fonctionner lors de la revue de code source. Un autre peut être plus performant pour interagir avec une application active ou relier des faiblesses d’identité entre des systèmes cloud.

Le harnais environnant peut compter autant que le modèle de base. La sélection des outils, la logique de nouvelle tentative, la mémoire, la décomposition de la cible et les règles de validation influencent ce que le système peut découvrir.

Les précédentes recherches NOVA de Unit 42 fournissent un exemple plus vaste de cette complémentarité. NOVA est le Network and Open-Source Vulnerability Analyzer de l’entreprise.

Palo Alto Networks affirme que NOVA a analysé 3 915 projets open source sur deux mois et généré 14 090 résultats de vulnérabilités confirmées. L’entreprise a classé 40 % d’entre eux comme étant de gravité élevée ou critique.

Elle a également indiqué que 99,4 % de ces résultats n’avaient pas été signalés auparavant. Ce chiffre doit être lu comme un résultat de recherche d’un fournisseur, et non comme un recensement indépendant des vulnérabilités logicielles.

Le projet couvrait notamment les écosystèmes Go, JavaScript et TypeScript, PHP, C et C++, ainsi que Java. Unit 42 a indiqué que chaque modèle évalué avait contribué à des résultats que les autres modèles n’avaient pas produits.

Dans un sous-ensemble détaillé, le modèle ayant généré le plus grand volume a produit 235 résultats confirmés, dont 185 résultats uniques. Le modèle ayant généré le plus faible volume a tout de même produit 139 résultats, dont 93 uniques.

Ces chiffres étayent l’idée qu’un ensemble peut accroître la couverture. Ils n’établissent pas le niveau de couverture supplémentaire que recevra chaque client d’entreprise.

La taille de la base de code, le langage de programmation, l’architecture applicative, les outils disponibles et les autorisations de test peuvent tous modifier le résultat. Les environnements actifs introduisent également des contrôles absents des tests limités aux dépôts.

L’affirmation de 40 % ne doit donc pas être interprétée comme une limite universelle des modèles d’IA. Elle décrit l’évaluation de Unit 42 dans des conditions que Palo Alto Networks n’a pas entièrement divulguées publiquement.

Les détails manquants comprennent l’ensemble complet des vulnérabilités, les configurations des modèles, le nombre de tentatives, l’accès aux outils, les budgets de temps et le traitement des résultats en double.

Palo Alto Networks n’a pas non plus publié de matrice de confusion complète présentant les vrais positifs, les faux positifs, les faux négatifs et les résultats contestés. Cela rend les comparaisons indépendantes difficiles.

Néanmoins, ce constat sur la couverture offre un avertissement important. Les entreprises ne devraient pas considérer un benchmark solide d’un modèle comme la preuve qu’un seul modèle voit l’ensemble d’une surface d’attaque.

Un modèle peut être performant dans des défis contrôlés tout en manquant des faiblesses créées par une chaîne d’identité, une intégration ou un modèle de déploiement particulier. La couverture doit être mesurée dans l’environnement de l’acheteur.

Le véritable arbitrage oppose la couverture multimodèle à la simplicité d’un modèle unique

Le choix principal n’oppose plus les tests humains aux tests par IA. Il oppose un ensemble géré à une dépendance envers un modèle et un flux de travail uniques.

Un système à modèle unique présente des avantages évidents. Il est plus facile à intégrer, surveiller, gouverner et évaluer qu’un service qui répartit le travail entre plusieurs modèles restreints et ouverts.

L’acheteur peut documenter un fournisseur, une politique d’accès, une famille de modèles et un ensemble de caractéristiques de sortie. Les équipes d’ingénierie font face à moins d’éléments mobiles lorsqu’elles diagnostiquent des résultats incohérents.

Un service multimodèle accroît la complexité. Chaque modèle peut nécessiter des invites, des outils, des garde-fous, des règles de traitement des données et des parcours d’escalade différents.

Les résultats doivent aussi être normalisés avant que les analystes puissent les comparer. Deux modèles peuvent décrire différemment la même vulnérabilité ou lui attribuer des niveaux de gravité contradictoires.

La réponse de Unit 42 est l’orchestration. Son harnais propriétaire est conçu pour orienter le travail, combiner les résultats, valider l’exploitabilité et présenter les conclusions dans un service géré unique.

Cela place la valeur au-dessus de la couche des modèles. Si les modèles capables deviennent interchangeables, l’avantage durable se déplace vers l’accès aux cibles, le routage des tâches, la validation, l’intégration de la remédiation et la supervision experte.

Le PDG de Palo Alto Networks, Nikesh Arora, a défendu cette thèse dans une interview accordée à Axios. Il a soutenu que plusieurs modèles associés à l’expertise humaine représentent probablement la direction prise par le secteur.

Les modèles sous-jacents ne sont pas des chatbots publics ordinaires. Anthropic limite ses capacités cyber les moins restreintes à des utilisateurs contrôlés via un programme d’accès Mythos.

OpenAI positionne de même GPT-5.6-Cyber pour la recherche autorisée de vulnérabilités et les tests de sécurité. Son programme Daybreak étendu fournit aux défenseurs qualifiés un accès adapté aux flux de travail cyber avancés.

Ces restrictions créent une raison supplémentaire d’acheter un service géré. De nombreuses entreprises ne peuvent pas obtenir, exploiter ou gouverner directement chaque modèle contrôlé inclus dans le système de Unit 42.

Toutefois, l’accès géré introduit un risque de concentration. Les clients dépendent de Palo Alto Networks pour la disponibilité des modèles, les décisions de routage, l’évaluation, les preuves et les priorités de remédiation.

Un fournisseur de modèles peut modifier les conditions d’accès, les garde-fous, les règles de conservation ou les versions des modèles. Unit 42 doit absorber ces changements sans affaiblir la couverture ni perturber les évaluations en cours.

Les modèles à poids ouverts offrent une autre voie, mais ils imposent leur propre charge de gouvernance. L’opérateur devient responsable de l’hébergement, des mises à jour, de l’isolation, de la surveillance et des contrôles contre les abus.

L’ensemble crée également un difficile problème de mesure. Davantage de modèles peuvent produire davantage de constats sans entraîner une réduction proportionnelle du risque matériel.

Dix constats à faible gravité qui se chevauchent ne comptent pas nécessairement davantage qu’une chaîne d’identité validée atteignant des données de production. Le seul volume de découvertes est un faible indicateur de réussite.

Les acheteurs devraient se concentrer sur les chemins d’attaque validés, les constats acceptés, le délai de correction, la récurrence et la réduction des risques confirmée indépendamment. Ces mesures relient la production des modèles aux résultats de sécurité.

Le même principe s’applique aux connaissances internes de sécurité. Les constats, le contexte du code, les données de responsabilité et les décisions de correction doivent disposer d’un emplacement traçable plutôt que d’être dispersés dans des rapports.

Les équipes d’ingénierie qui construisent déjà une base de connaissances d’ingénierie peuvent appliquer la même rigueur aux preuves de sécurité. L’objectif est de préserver pourquoi un constat était important et comment il a été résolu.

L’avantage concurrentiel reviendra aux systèmes qui transforment les preuves en actions. Le simple accès aux modèles deviendra moins convaincant à mesure que d’autres fournisseurs acquerront des capacités similaires.

Ce que les chiffres ne prouvent toujours pas

Le lancement présente des affirmations convaincantes sur la couverture, mais ne fournit pas encore de référence reproductible sur l’efficacité.

Les documents publics n’identifient pas l’ensemble complet des modèles inclus dans la comparaison de couverture. Ils citent Claude Mythos 5 et GPT-5.6-Cyber comme principaux exemples, aux côtés de modèles à poids ouverts.

Ils n’expliquent pas non plus comment Unit 42 a déterminé l’ensemble complet des vulnérabilités à partir duquel la couverture de chaque modèle a été calculée.

Ce dénominateur est essentiel. Les chercheurs ne peuvent pas savoir qu’un modèle a trouvé 40 % des vulnérabilités sans disposer d’un ensemble de référence suffisamment complet ou d’un ensemble combiné soigneusement défini.

Si le dénominateur inclut chaque constat unique produit par tous les modèles, l’ajout de modèles peut augmenter le total et diminuer le pourcentage de chaque modèle pris individuellement. Cela démontrerait toujours une complémentarité, mais mesurerait une couverture relative à l’ensemble.

Une référence fondée sur des vulnérabilités introduites volontairement répondrait à une question différente. Elle mesurerait si chaque modèle a détecté un ensemble connu de défauts contrôlés.

Tester des environnements clients réels crée des complications supplémentaires. Certaines vulnérabilités réelles restent non confirmées, car leur exploitation perturberait la production ou accéderait à des données sensibles.

Unit 42 affirme que son système valide l’exploitabilité en conditions réelles, mais les documents publics ne décrivent pas les limites d’autorisation pour chaque mode de test. Ces limites peuvent affecter sensiblement la couverture apparente.

Les taux de faux positifs sont tout aussi importants. Un système d’IA peut produire de nombreuses hypothèses de vulnérabilité plausibles qui consomment du temps d’analyste sans créer de risque exploitable.

La validation humaine peut réduire ce problème. Pourtant, le service n’a pas publié combien de constats bruts les experts rejettent, fusionnent, rétrogradent ou renvoient pour des tests supplémentaires.

Le coût et la latence restent également flous. Un harnais multi-modèles peut améliorer la couverture tout en consommant bien davantage de ressources d’inférence, de sandbox et d’analystes qu’un flux de travail à modèle unique.

L’entreprise affirme que le routage aide à gérer le coût de l’IA de pointe à grande échelle. Elle n’a pas publié de comparaisons de coûts par tâche ni les compromis appliqués par son routeur.

Les acheteurs ont aussi besoin de clarté sur le traitement des données. Les tests de sécurité peuvent exposer du code source propriétaire, des détails d’architecture, des identifiants et des preuves de faiblesses exploitables.

Chaque fournisseur de modèle peut avoir des exigences différentes en matière de conservation et de surveillance. Les clients devraient déterminer quelles données quittent leur environnement, combien de temps elles restent disponibles et qui peut les examiner.

Les affirmations du service concernant la correction nécessitent une vigilance comparable. Recommander une modification du code n’est pas la même chose que la déployer en toute sécurité.

Les correctifs suggérés exigent examen, tests, responsabilité, plans de retour arrière et vérification. Les correctifs virtuels peuvent réduire rapidement l’exposition, mais ils peuvent aussi créer un faux sentiment de sécurité si la faille sous-jacente demeure.

Palo Alto Networks affirme que le service peut établir une base de référence pour l’ensemble du parc et poursuivre les tests à mesure que l’environnement évolue. Les acheteurs devraient demander comment il détecte ces changements et détermine ce qui doit être retesté.

Un commit de dépôt, une mise à jour de politique cloud, une nouvelle route API ou un changement d’identité peuvent affecter différentes parties d’un chemin d’attaque. Un retest efficace dépend de la compréhension de ces dépendances.

La question sceptique centrale est donc mesurable : l’ensemble réduit-il plus rapidement l’exposition validée que les programmes existants de tests d’intrusion et de gestion des vulnérabilités ?

La réponse exige des preuves au niveau des clients. Des comparaisons utiles incluraient les constats acceptés par heure de test, les chemins d’attaque critiques éliminés, le délai médian de correction et les taux de récurrence.

Un retest indépendant devrait également confirmer que les correctifs signalés ferment le chemin initial. Sinon, le système risque de mesurer le travail généré plutôt que la réduction du risque.

Aucune de ces lacunes ne rend le service inefficace. Elles établissent la différence entre une stratégie technique plausible et une valeur opérationnelle démontrée indépendamment.

Les tests continus par IA soumettent les équipes de sécurité à une nouvelle pression

Le service déplace le goulot d’étranglement de la découverte des vulnérabilités vers la décision de savoir quels constats méritent une action immédiate.

Les équipes de sécurité gèrent déjà les alertes des scanners, les résultats d’analyse de code, les rapports de bugs, les constats de tests d’intrusion, les mauvaises configurations cloud et les avertissements liés aux identités. Un autre système de découverte à fort volume peut alourdir cette charge.

L’accent mis par Unit 42 sur la validation de l’exploitation vise à résoudre ce problème. Un constat relié à un chemin d’attaque viable mérite davantage d’attention qu’une faiblesse théorique isolée.

Cette priorisation devient essentielle lorsque les agents fonctionnent en continu. Un rapport mensuel permet aux équipes de traiter un lot limité, tandis qu’un système toujours actif peut générer du travail après chaque changement significatif.

La pression s’étend au-delà du centre des opérations de sécurité. Les responsables d’applications, les équipes cloud, les administrateurs d’identité et les responsables d’ingénierie doivent participer à la correction.

Une recommandation au niveau du code exige un développeur qui comprend le service concerné. Un constat lié aux identités peut nécessiter des changements qui perturbent des flux de travail établis ou des systèmes automatisés.

L’exposition cloud peut concerner plusieurs équipes et comptes. Une correction réseau peut affecter la disponibilité, la supervision et le trafic client.

Cela fait des données de responsabilité un élément du contrôle de sécurité. Le service doit relier chaque exposition validée à la personne ou à l’équipe capable de la résoudre.

Les organisations ont également besoin d’objectifs de réponse fondés sur l’exploitabilité, la portée et l’impact sur l’activité. Les seuls libellés de gravité capturent rarement ces relations.

Une faille critique dans une bibliothèque peut ne présenter aucun chemin accessible dans un environnement donné. Une faiblesse d’identité modérée peut fournir un accès direct à des systèmes de production sensibles.

Les tests continus modifient également les questions d’approvisionnement. Les acheteurs devraient évaluer le processus opérationnel qui entoure les modèles, et pas seulement les noms de modèles figurant dans l’annonce.

Ils devraient demander si Unit 42 fournit des preuves pour chaque étape de l’attaque, enregistre chaque action d’outil, sépare la découverte de l’exploitation et prend en charge des conditions d’arrêt définies par le client.

Les identifiants devraient respecter le principe du moindre privilège nécessaire aux tests. L’accès à la production devrait être isolé, temporaire, surveillé et révocable.

Les actions destructrices nécessitent des contrôles explicites. Un agent qui valide une faiblesse de base de données ne devrait pas recevoir l’autorisation de modifier ou de supprimer des informations de production.

Les clients devraient également exiger des journaux complets. Un constat utile devrait indiquer l’actif concerné, le chemin testé, les preuves observées, la version du modèle et du harnais, ainsi que le réviseur humain.

Ces enregistrements soutiennent la correction, les audits, la réponse aux incidents et les retests ultérieurs. Ils aident également à identifier les régressions de modèle après une mise à jour.

Les fournisseurs traditionnels de tests d’intrusion subissent la pression de ce modèle opérationnel. Les missions annuelles apportent une expertise approfondie, mais leurs constats commencent à vieillir dès que la cible change.

Les scanners automatisés font face à un défi différent. Ils offrent une visibilité continue, mais beaucoup peinent à valider des chaînes d’exploitation complexes à travers les couches de code, cloud, identité et réseau.

Unit 42 positionne son service entre ces catégories. Il combine automatisation continue, supervision experte et validation des chemins d’attaque.

La question non résolue est de savoir si cette combinaison peut évoluer économiquement sans réduire la qualité de l’examen humain. L’attention des experts reste limitée, même lorsque l’inférence des modèles augmente.

Si les modèles génèrent des constats plus rapidement que les clients ne peuvent les corriger, le service doit contribuer à réduire la file d’attente. Sinon, la découverte continue peut révéler les mêmes contraintes organisationnelles plus fréquemment.

Trois signaux montreront si la stratégie multi-modèles fonctionne

Le prochain test n’est pas une nouvelle annonce de modèle. C’est la preuve qu’une couverture combinée produit une réduction des risques plus rapide et vérifiée indépendamment.

Le premier signal est une méthodologie d’évaluation détaillée. Palo Alto Networks devrait expliquer comment il a calculé le plafond de couverture de 40 % et le chiffre de chevauchement inférieur à 10 %.

Une méthodologie utile identifierait les versions des modèles, les types de cibles, les autorisations des outils, les limites de tentatives, les budgets de temps, les critères de validation et le dénominateur.

Elle devrait également signaler les faux positifs et les constats contestés. Sans ces détails, les observateurs externes ne peuvent pas déterminer si l’avantage de l’ensemble provient de la diversité des modèles, de la conception du harnais, de ressources de calcul supplémentaires ou d’une intervention humaine.

La publication de ces informations renforcerait l’argument central. Si la différence persiste dans des conditions reproductibles, les systèmes de défense à modèle unique feront face à un désavantage architectural clair.

Si des tests indépendants révèlent des différences plus faibles, les clients pourraient préférer des flux de travail plus simples avec un modèle et des outils spécialisés. Le résultat affaiblirait l’argument en faveur d’un grand ensemble géré.

Le deuxième signal est la preuve client liée à la correction. Les études de cas devraient présenter les chemins d’attaque validés et fermés, le délai de résolution, la récurrence et la comparaison avec les méthodes de test précédentes.

Trouver en quelques semaines l’équivalent d’une année d’expositions semble impressionnant, mais le volume seul n’établit pas la valeur. Le résultat important est de savoir si les équipes ont éliminé plus tôt un risque matériel.

Les preuves devraient distinguer les vulnérabilités nouvellement découvertes des constats existants des scanners. Elles devraient aussi séparer les correctifs générés par les modèles des changements examinés et déployés par les clients.

Un retest indépendant rendrait ces résultats plus crédibles. Une équipe distincte devrait confirmer que le chemin d’attaque initial ne fonctionne plus et que le correctif n’a pas créé une autre exposition.

Le troisième signal est la manière dont les concurrents et les fournisseurs de modèles réagissent. D’autres fournisseurs de sécurité peuvent créer leurs propres routeurs, s’associer à des programmes de modèles à accès contrôlé ou proposer des couches de validation indépendantes des modèles.

Anthropic et OpenAI peuvent également étendre l’accès direct aux défenseurs approuvés. Un accès plus large réduirait l’un des avantages d’acquérir cette capacité auprès d’un fournisseur géré.

Parallèlement, les nouvelles versions de modèles peuvent accroître la diversité. Un modèle présentant un entraînement ou un comportement d’utilisation d’outils véritablement différent pourrait apporter des constats que les systèmes actuels manquent.

Il faudra observer si Unit 42 ajoute des modèles parce qu’ils améliorent la couverture mesurée ou parce qu’ils renforcent une liste marketing. Le service devrait pouvoir retirer les modèles qui ajoutent peu de valeur unique.

Les acheteurs devraient demander des données de contribution pour chaque modèle de l’ensemble. Un rapport utile présenterait les constats validés uniques, le chevauchement, le coût, la latence et les performances par catégorie de tâche.

Ils devraient également demander comment le routage évolue au fil du temps. Un harnais qui apprend quel modèle gère le mieux une langue ou un type de cible particulier peut améliorer l’efficacité.

Cependant, le routage dynamique complique la reproductibilité. Retester le même environnement avec une combinaison différente de modèles peut produire des constats et des preuves différents.

Des enregistrements versionnés peuvent résoudre ce problème. Chaque résultat doit préserver le modèle, le harnais, les outils, les politiques et l’état cible pertinent utilisés durant les tests.

Unit 42 Continuous Frontier AI Defense arrive à un moment où les modèles de cybersécurité deviennent à la fois plus capables et davantage restreints. Cette combinaison crée une demande pour des intermédiaires de confiance.

Palo Alto Networks a proposé une réponse cohérente : utiliser plusieurs modèles, les entourer d’outils contrôlés, valider les résultats et maintenir les experts dans la boucle.

L’affirmation de 40 % de couverture rend cette stratégie plausible, mais non concluante. Les entreprises devraient la considérer comme une hypothèse à tester face à leurs propres applications, identités et environnements cloud.

Les responsables de la sécurité qui évaluent le service devraient commencer par un pilote circonscrit. Définissez les actifs, les autorisations, les contrôles de sécurité, les constats existants et les indicateurs de remédiation avant le début des tests.

Comparez ensuite les constats retenus, les chemins d’attaque vérifiés, la charge de travail des analystes et les délais de clôture avec le programme actuel. Demandez quel modèle a contribué de manière unique à chaque résultat important.

Ce processus transforme l’affirmation centrale de Unit 42 en un élément qu’une organisation peut vérifier. Si l’ensemble de modèles identifie des chemins significatifs que les outils existants ne détectent pas, l’architecture justifie sa complexité.

S’il ne fait essentiellement qu’augmenter la file d’alertes, le nombre de modèles n’aura pas d’importance. La question est de savoir si les tests continus à l’aide de plusieurs modèles aident les défenseurs à réduire l’exposition avant que les attaquants puissent l’exploiter.