Palo Alto Networks Unit 42 AI Defense passe en mode permanent, mais les preuves doivent suivre

Palo Alto Networks a transformé Unit 42 AI Defense en service continu, remplaçant les évaluations périodiques par des tests offensifs permanents et multi-modèles. Lancé le 22 septembre, le service cible l’écart croissant entre des attaques opérant à la vitesse des machines et des programmes de sécurité encore organisés autour d’analyses planifiées, de revues manuelles et de remédiations tardives.

Le service, officiellement nommé Unit 42 Continuous Frontier AI Defense, associe des modèles d’IA spécialisés à l’expertise humaine en sécurité offensive. Il teste les applications, les API, les infrastructures cloud, les dépôts de code et les actifs réseau à mesure que les environnements clients évoluent. Palo Alto Networks affirme que le système peut également relier des faiblesses distinctes en chemins d’attaque révélant comment un intrus pourrait atteindre des systèmes de valeur.

Cette promesse place Palo Alto Networks dans une compétition plus vaste avec Microsoft, CrowdStrike, Google et d’autres fournisseurs de sécurité qui développent des défenses fondées sur des agents. Pourtant, la confrontation décisive n’oppose pas les fournisseurs entre eux. Elle oppose la découverte continue à un processus de remédiation d’entreprise souvent manuel, fragmenté et lent.

Unit 42 AI Defense passe des évaluations aux tests continus

Le changement important n’est pas un assistant IA supplémentaire. Palo Alto Networks transforme les tests de sécurité offensive en service d’entreprise continu.

Unit 42 a présenté son offre Frontier AI Defense initiale en avril 2026. Ce service reposait sur une analyse ponctuelle de l’exposition, suivie d’un plan de sécurité destiné à améliorer les défenses du client.

Le nouveau service de tests continus étend cette approche au-delà d’une évaluation planifiée. Il établit une référence, surveille les changements, exécute de nouveaux tests, valide les résultats et déclenche des tests supplémentaires à mesure que les environnements évoluent.

Palo Alto Networks décrit le produit comme un service de sécurité offensive agentique. Ici, agentique signifie que le logiciel peut accomplir des tâches de sécurité en plusieurs étapes au lieu de produire uniquement des recommandations textuelles.

Le service utilise Claude Mythos 5 d’Anthropic, GPT-5.6-Cyber d’OpenAI et des modèles à poids ouverts. Une couche d’orchestration propriétaire oriente les différentes tâches vers le modèle que Palo Alto Networks juge le mieux adapté à chaque mission.

Cette répartition du travail compte, car les tests de sécurité regroupent plusieurs problèmes distincts. Repérer du code suspect, explorer une application, évaluer une configuration et relier des faiblesses en un chemin d’attaque exigent des capacités différentes.

Unit 42 place ensuite des spécialistes humains autour de ces modèles. Ses consultants examinent les résultats, vérifient si les faiblesses sont exploitables et hiérarchisent les correctifs selon les chemins d’attaque obtenus.

Le produit couvre les applications web propriétaires et tierces, les API, les environnements cloud, les dépôts sources et les actifs réseau. Cette portée reflète la façon dont les attaques modernes franchissent les frontières au lieu de rester confinées à un seul outil de sécurité.

Une application web vulnérable peut exposer des identifiants. Ces identifiants peuvent déverrouiller un service cloud, qui pourrait ensuite donner accès à des données sensibles ou à un autre système d’identité.

Un scanner qui ne signale que la première vulnérabilité peut manquer la conséquence plus large. Continuous Frontier AI Defense vise à modéliser le parcours connecté, puis à montrer aux défenseurs quel maillon mérite d’abord leur attention.

Le service peut également fournir des recommandations au niveau du code et de correctifs virtuels. Un correctif virtuel est un contrôle compensatoire qui bloque l’exploitation sans modifier le logiciel vulnérable lui-même.

Palo Alto Networks indique que les clients peuvent associer le service à sa technologie distincte de correctifs virtuels. Cette option est utile lorsqu’un correctif logiciel officiel n’existe pas encore ou ne peut pas être déployé immédiatement.

La disponibilité est mondiale via des abonnements annuels, selon l’entreprise. La combinaison de modèles incluse varie selon l’abonnement, tandis que chaque configuration utilise la couche d’orchestration multi-modèles.

Ce lancement modifie donc l’offre Unit 42 de trois manières. Les tests deviennent continus, la sélection des modèles devient dynamique et les résultats alimentent un cycle récurrent de validation et de remédiation.

Le résultat se rapproche davantage d’une équipe rouge permanente que d’une analyse traditionnelle des vulnérabilités. La question centrale reste de savoir s’il peut fonctionner ainsi à l’échelle d’une entreprise.

La conception multi-modèles constitue le véritable pari du produit

Palo Alto Networks parie que la diversité des modèles peut détecter des faiblesses de sécurité qu’un unique modèle de pointe manquerait.

Le raisonnement de l’entreprise part d’une limite observée lors de ses propres tests. Palo Alto Networks a déclaré à Axios qu’aucun modèle individuel n’avait détecté plus de 40 % des vulnérabilités dans un environnement client complexe.

Les faiblesses détectées par Claude Mythos 5 et GPT-5.6-Cyber se chevauchaient moins de 10 % du temps. Ces chiffres proviennent des tests du fournisseur et n’ont pas fait l’objet d’une validation indépendante équivalente.

Néanmoins, l’écart signalé explique l’architecture. Un service reposant sur un seul modèle hériterait de ses angles morts, de ses schémas de refus, de ses limites d’entraînement et de ses méthodes privilégiées.

Un dispositif multi-modèles peut attribuer les tâches selon les forces observées. Un modèle peut inspecter le code source, tandis qu’un autre explore une application active ou évalue une configuration cloud.

Les modèles à poids ouverts ajoutent une autre option. Ils peuvent être adaptés à des tâches plus ciblées ou déployés sous des contraintes opérationnelles différentes de celles des modèles fermés.

Le compte rendu indépendant du lancement décrit un système qui recherche continuellement les faiblesses et recommande des correctifs. Il tente également de combiner des faiblesses individuelles en chemins d’attaque viables.

Cette deuxième étape est essentielle. Les équipes de sécurité reçoivent déjà plus de résultats qu’elles ne peuvent traiter, et un scanner automatisé supplémentaire peut ajouter du bruit sans réduire les risques.

La validation des chemins d’attaque pose une question plus utile. Elle vérifie si plusieurs faiblesses peuvent être combinées pour atteindre un actif important, une identité ou une fonction administrative.

Les experts humains de Unit 42 restent intégrés à ce processus. Leur rôle consiste à vérifier les résultats des modèles, à simuler des comportements d’adversaires crédibles et à distinguer les chemins d’attaque plausibles des combinaisons théoriques.

Cette couche humaine répond également à un problème fondamental de l’IA générative. Les modèles peuvent produire des explications convaincantes mais erronées, des preuves incomplètes ou des étapes impossibles à reproduire.

Un service utile doit donc conserver les artefacts. Les équipes de sécurité ont besoin de l’actif concerné, du chemin testé, du comportement observé, des preuves et de la remédiation proposée.

Ces enregistrements doivent également subsister au-delà de l’évaluation. Les équipes ont besoin d’une base de connaissances consultable reliant les résultats aux responsables, aux décisions antérieures, aux modifications de code, aux exceptions et aux résultats des nouveaux tests.

Sans cette continuité, les tests permanents peuvent devenir un arriéré qui ne cesse de croître. Davantage de découvertes ne produisent pas automatiquement une meilleure sécurité.

Palo Alto Networks indique avoir passé six mois à tester l’approche en interne et dans le cadre de plus de 100 missions clients de Unit 42. L’entreprise fait également état d’un investissement de 17 millions de dollars dans le développement et le travail méthodologique.

Lors de son déploiement interne, l’entreprise affirme que le service a détecté ce qu’elle qualifie d’une année d’expositions en trois semaines. La comparaison est frappante, mais l’annonce ne publie ni la référence sous-jacente ni la répartition des niveaux de gravité.

Dans les évaluations clients, l’entreprise affirme que sa précédente Frontier AI Exposure Analysis a détecté des expositions dans chaque organisation testée. Elle a classé 37 % de ces résultats comme élevés ou critiques.

Palo Alto Networks affirme également que la plupart des expositions provenaient d’applications propriétaires. Plus des deux tiers des résultats dans les applications tierces ne disposaient apparemment pas d’un identifiant Common Vulnerabilities and Exposures connu.

Un CVE est un identifiant public associé à une vulnérabilité logicielle documentée. L’absence de CVE peut signaler une faille inconnue, un problème de configuration ou une faiblesse hors des bases de données de vulnérabilités standard.

Ces résultats renforcent l’argument en faveur de tests allant au-delà des scanners conventionnels. Ils n’établissent pas combien de résultats étaient uniques, reproductibles ou finalement corrigés.

L’architecture multi-modèles est donc à la fois le facteur différenciant et le premier problème de mesure. Les acheteurs ont besoin de preuves qu’une couverture supplémentaire des modèles réduit les risques manqués sans multiplier les faux positifs.

La sécurité à la vitesse des machines accroît la pression sur tous les grands fournisseurs

Unit 42 AI Defense pousse les concurrents à démontrer que leurs agents peuvent prévenir l’exposition, et pas seulement résumer les alertes après détection.

Le lancement intervient alors que les entreprises de sécurité passent des interfaces conversationnelles à des agents capables d’enquêter, de décider et d’agir à travers plusieurs systèmes. Palo Alto Networks inscrit cette évolution dans la gestion offensive de l’exposition.

Microsoft suit une voie proche avec Project Perception. L’entreprise a présenté des modèles et des agents spécialisés dans la cybersécurité, destinés à identifier, hiérarchiser et corriger les vulnérabilités logicielles.

Microsoft indique que son architecture associe de petits modèles spécialisés à des systèmes de pointe plus grands. Le plus petit modèle traite l’analyse courante, tandis que les modèles plus grands prennent en charge les tâches plus difficiles.

Cette approche ressemble à la stratégie de routage de Palo Alto Networks, bien que Microsoft puisse intégrer ses agents à ses produits pour les développeurs, l’identité, les terminaux et le cloud. Sa plateforme de modèles de sécurité met également l’accent sur la gouvernance et l’apprentissage continu.

CrowdStrike se concentre sur le centre des opérations de sécurité. Son système Charlotte AI coordonne des agents pour les enquêtes, la recherche de menaces et la réponse gouvernée au sein de la plateforme Falcon.

La proposition de SOC agentique de l’entreprise s’appuie sur la télémétrie des terminaux et le contexte opérationnel. Palo Alto Networks démarre plus près de la découverte des expositions et de la simulation d’adversaires.

Google Cloud intègre lui aussi des agents dans les flux de détection des menaces, d’enquête, de sécurité cloud et de remédiation. Son avantage provient du contexte cloud, du renseignement sur les menaces et de l’accès au portefeuille de modèles de Google.

Ces produits se recoupent, mais ils ne sont pas interchangeables. Un agent d’opérations de sécurité enquête sur une activité, tandis qu’un agent de tests offensifs recherche activement des faiblesses exploitables.

Les catégories finiront probablement par converger. La découverte mène à la remédiation, la remédiation exige une vérification et les incidents actifs révèlent souvent des expositions que les tests préventifs n’ont pas détectées.

Cette convergence renforcera la pression concurrentielle autour de l’accès aux données. Les agents fonctionnent mieux lorsqu’ils peuvent voir le code, les identités, les configurations, les relations réseau, les tickets et le comportement à l’exécution.

Elle favorise aussi les fournisseurs disposant de plateformes d’entreprise établies. Ils peuvent relier un résultat d’IA à un contrôle, un flux de travail ou un point d’application existant sans devoir construire chaque intégration à partir de zéro.

Palo Alto Networks dispose de produits couvrant les réseaux, la sécurité cloud, les opérations de sécurité, l’identité et la réponse aux incidents. Unit 42 ajoute de l’expertise humaine et du renseignement sur les menaces à ce portefeuille.

Le service peut donc faire le lien entre le conseil et le logiciel. Les consultants valident les chemins d’attaque, tandis que les produits de la plateforme peuvent soutenir la détection, la remédiation ou les contrôles compensatoires.

Cette conception crée un avantage commercial, mais aussi une source de scepticisme. Un fournisseur qui découvre une faiblesse peut recommander des produits de son propre portefeuille dans le cadre de la solution.

Les clients auront besoin d’une séparation claire entre les preuves, la priorité de remédiation et les recommandations de produits. Les constats doivent rester utiles même lorsque le système affecté appartient à un autre fournisseur.

Palo Alto Networks affirme que ses tests incluent des actifs tiers, et pas seulement ses propres produits. Les acheteurs devraient vérifier que les intégrations, la qualité des preuves et les recommandations de remédiation restent cohérentes dans des environnements mixtes.

La pression plus générale s’étend au-delà des fournisseurs de sécurité. Les équipes rouges internes, les sociétés de tests d’intrusion et les fournisseurs de gestion des vulnérabilités doivent expliquer où l’expertise humaine crée une valeur allant au-delà de la découverte automatisée.

Les testeurs humains apportent toujours de la créativité, du contexte métier et du jugement face à des comportements ambigus. Ils peuvent également évaluer des processus sociaux et des hypothèses organisationnelles qu’un agent connecté au réseau ne peut pas observer.

Les agents IA apportent répétition, échelle et persistance. Ils peuvent retester après chaque changement significatif sans attendre la prochaine évaluation trimestrielle.

Le modèle gagnant combinera ces deux forces. L’automatisation continue devrait prendre en charge les tâches techniques récurrentes, tandis que les experts humains se concentrent sur les chemins incertains, l’impact métier et les décisions à plus haut risque.

La découverte continue se heurte à une remédiation lente

Le service ne réussit que si les clients peuvent corriger les expositions vérifiées presque aussi vite que les agents les découvrent.

Palo Alto Networks présente le produit autour d’une fenêtre défensive qui se réduit. Ses recherches Unit 42 indiquent que le chemin observé le plus rapide entre l’accès initial et l’exfiltration de données est tombé à 72 minutes.

Les données de réponse aux incidents de l’entreprise couvrent plus de 750 enquêtes à fort enjeu. Elles indiquent que la vitesse des attaques a été multipliée par quatre par rapport à l’année précédente.

Unit 42 indique également que 87 % des attaques examinées ont traversé au moins deux surfaces d’attaque. Certains incidents ont impliqué une activité sur jusqu’à 10 fronts.

Des faiblesses liées à l’identité sont apparues dans 89 % des enquêtes, selon le même rapport. Les techniques fondées sur l’identité représentaient 65 % des accès initiaux, tandis que les vulnérabilités exploitées en représentaient 22 %.

Il s’agit de statistiques produites par le fournisseur, issues des interventions d’Unit 42. Elles décrivent un ensemble substantiel d’incidents, mais pas toutes les organisations ni l’ensemble du paysage des menaces.

Même avec cette réserve, elles clarifient pourquoi les tests périodiques sont sous pression. Une évaluation trimestrielle offre une protection limitée lorsque l’infrastructure, le code, les comptes et les dépendances changent chaque jour.

Les tests continus peuvent réduire l’intervalle entre la création d’une exposition et sa découverte. Ils ne peuvent pas, à eux seuls, raccourcir chaque processus d’approbation, de développement, de déploiement ou d’approvisionnement qui suit.

Une faille applicative confirmée peut toujours exiger qu’une équipe d’ingénierie modifie le code. Une mauvaise configuration cloud peut impliquer plusieurs responsables aux exigences opérationnelles contradictoires.

Une identité exposée peut nécessiter une rotation des identifiants, une refonte des accès et une enquête sur l’activité antérieure. Une faiblesse d’un tiers peut ne disposer d’aucune correction contrôlée par le client.

Le patching virtuel peut offrir une protection temporaire dans certaines situations. Pourtant, les contrôles compensatoires nécessitent des tests, une surveillance, un responsable et un plan de remédiation permanente.

Cela crée le compromis central du lancement. Le même système qui améliore la découverte peut submerger les équipes dont la capacité de remédiation reste fixe.

Les responsables de la sécurité devraient donc évaluer le débit plutôt que le nombre brut de constats. Les mesures pertinentes incluent le temps de validation, le temps d’attribution, le temps d’atténuation et le temps de vérification de la clôture.

Les taux de réouverture comptent également. Un correctif qui disparaît lors du déploiement suivant n’est pas une amélioration durable de la sécurité.

L’ancienneté de l’exposition est une autre mesure utile. La découverte continue a une valeur limitée si les constats critiques restent non résolus tandis que de nouveaux constats s’accumulent.

Les intégrations de ticketing du produit peuvent aider à faire entrer les preuves dans les workflows établis. L’intégration ne garantit pas que la bonne équipe assume la responsabilité ou reçoive suffisamment de contexte pour agir.

Chaque ticket devrait expliquer l’actif affecté, le chemin d’attaque crédible, la conséquence métier, les preuves de validation et le contrôle recommandé. Il devrait aussi distinguer l’exploitabilité confirmée de l’inférence du modèle.

La priorisation doit rester suffisamment stable pour que les équipes puissent planifier. Si les scores de risque changent sans preuves compréhensibles, les développeurs et les responsables d’infrastructure se méfieront de la file d’attente.

Ce problème de confiance est bien connu dans la gestion des vulnérabilités. Les équipes de sécurité mesurent souvent la couverture des scanners, tandis que les équipes d’ingénierie perçoivent le système à travers les faux positifs et les échéances concurrentes.

Les tests permanents augmentent les enjeux, car ils peuvent générer des constats en continu. Les acheteurs devraient exiger des contrôles pour le périmètre, la déduplication, la suppression, l’escalade et le retest.

Ils devraient aussi décider où s’arrête l’action autonome. Recommander un correctif, ouvrir un ticket, modifier du code et bloquer le trafic de production comportent des risques opérationnels très différents.

Un déploiement mature définira les autorisations selon les conséquences. Les retests à faible risque peuvent s’exécuter automatiquement, tandis que les changements en production exigent une approbation explicite et des plans de retour arrière.

Le résultat devrait être une boucle fermée. Découvrir, valider, attribuer, remédier, retester et conserver les preuves.

Sans cette boucle, Unit 42 AI Defense risque d’optimiser la partie la plus visible du travail de sécurité. Il identifierait les problèmes plus rapidement tout en laissant intact le goulet d’étranglement organisationnel plus difficile.

L’affirmation d’autonomie nécessite des preuves indépendantes

La plus grande incertitude n’est pas de savoir si les modèles de pointe peuvent trouver des vulnérabilités. Elle est de savoir s’ils peuvent fonctionner en continu sans introduire un risque ou un bruit inacceptables.

Palo Alto Networks a publié plusieurs résultats internes significatifs. Toutefois, l’entreprise n’a pas communiqué suffisamment de méthodologie pour permettre à des tiers de reproduire les principales affirmations de performance.

Les acheteurs ne connaissent pas encore la répartition des vulnérabilités derrière le plafond de 40 % d’un modèle unique. Ils ne disposent pas non plus de taux détaillés de précision, de rappel, de faux positifs et de faux négatifs.

Le chevauchement signalé de moins de 10 % entre deux modèles est particulièrement important. Il suggère une diversité, mais un faible chevauchement peut aussi refléter des tests incohérents ou des définitions différentes d’un constat valide.

Une évaluation indépendante devrait vérifier quelle explication prévaut. Elle devrait aussi tester si le système multi-modèles trouve davantage de chemins d’attaque significatifs qu’une équipe humaine qualifiée ou que des outils établis.

L’évaluation comparative des systèmes de sécurité agentiques est difficile, car les tests statiques vieillissent rapidement. Les modèles peuvent assimiler des données de tests publiques, tandis que les environnements réels des entreprises comprennent des autorisations évolutives, des applications personnalisées et des dépendances non documentées.

Le système de test lui-même peut également devenir un risque. Un agent offensif reçoit des outils et des accès destinés à sonder les systèmes, exécuter des actions et collecter des preuves.

Cet accès exige des limites strictes. L’agent devrait opérer selon le principe du moindre privilège, ce qui signifie ne recevoir que les autorisations nécessaires à sa tâche assignée.

Chaque action devrait être journalisée. Les opérations à haut risque devraient exiger une autorisation humaine, et l’environnement devrait permettre un confinement rapide si le comportement dépasse le périmètre approuvé.

Le National Institute of Standards and Technology a constaté un large consensus selon lequel les agents IA introduisent de nouvelles préoccupations de sécurité. Ses conclusions sur la sécurité des agents indiquent également que les pratiques de cybersécurité établies doivent être adaptées aux systèmes agentiques.

Ces préoccupations s’appliquent directement aux tests offensifs autonomes. Une injection de prompt, un outil compromis, un dépôt empoisonné ou une cible erronée pourrait rediriger un agent autorisé.

Un modèle pourrait également exposer du code source sensible ou des données de configuration à un service externe. Les acheteurs ont besoin de réponses claires sur la conservation des données, l’accès aux modèles, le traitement régional et les politiques d’entraînement.

La conception multi-modèles rend ces questions plus complexes. Différents modèles peuvent entraîner des exigences différentes en matière de traitement des données, de limites de déploiement et de contraintes opérationnelles.

Palo Alto Networks affirme que des experts humains valident les constats et les chemins d’attaque. L’annonce publique donne moins de détails sur les étapes d’approbation, l’isolation des modèles, l’accès des clients aux audits et les procédures d’incident du système de test lui-même.

Cela ne signifie pas que les contrôles sont absents. Cela signifie que les clients potentiels devraient traiter les détails de gouvernance comme un élément de l’évaluation du produit, et non comme une note de bas de page de mise en œuvre.

L’affirmation selon laquelle des expositions sont apparues chez chaque client évalué mérite également du contexte. Toute évaluation suffisamment large peut trouver des faiblesses de configuration, des composants non pris en charge ou des problèmes à faible probabilité.

Les seules étiquettes de gravité ne peuvent pas démontrer l’importance métier. Une faiblesse techniquement critique peut se trouver derrière de solides contrôles, tandis qu’une faille d’identité modérée peut permettre une chaîne d’attaque dommageable.

Les chemins validés offrent un meilleur signal que la gravité isolée. Même dans ce cas, les clients devraient exiger des preuves reproductibles et des hypothèses explicites sur l’accès, les capacités de l’attaquant et l’état de l’environnement.

Ils devraient également demander comment le système gère les tests destructifs. Une simulation sûre doit établir l’exploitabilité sans endommager les données, interrompre le service ou enfreindre les conditions de tiers.

Les applications tierces présentent une autre limite. Un client peut contrôler un compte ou une intégration sans avoir l’autorisation d’effectuer des tests agressifs contre l’infrastructure du fournisseur.

La gestion du périmètre doit donc fonctionner aux niveaux des actifs, des actions et du temps. Une autorisation large pour tester « l’entreprise » n’est pas suffisamment précise pour un système autonome.

L’interprétation la plus prudente du lancement est mesurée. Palo Alto Networks a présenté une architecture crédible et des preuves internes notables, mais pas une norme de performance établie de manière indépendante.

Cet écart est normal pour un service nouvellement lancé. Il ne devient problématique que si les acheteurs confondent les résultats du fournisseur avec des résultats universellement prouvés.

Trois signaux montreront si la défense permanente fonctionne

La phase suivante devrait être jugée à l’aune des résultats de remédiation, de la validation indépendante et des réponses concurrentielles, plutôt qu’au nombre de modèles impliqués.

Le premier signal est la performance de remédiation des clients. Palo Alto Networks devrait indiquer si les clients ferment plus rapidement les chemins d’attaque validés après avoir adopté le service continu.

Les mesures utiles comprennent le temps médian de validation, le temps d’atténuation, le temps de clôture et la récurrence après retest. Les seuls décomptes de gravité ne montreront pas si la sécurité s’est améliorée.

Une diminution de l’ancienneté des expositions renforcerait l’argumentaire de l’entreprise. Une file croissante de constats non résolus suggérerait que la découverte dépasse la capacité des clients.

Le deuxième signal est l’évaluation technique indépendante. Des chercheurs ou des clients devraient reproduire l’avantage multi-modèles sur des applications représentatives, des environnements cloud, des bases de code et des systèmes d’identité.

Ce travail devrait présenter les faux positifs, les constats manqués, les contributions propres à chaque modèle et la qualité des preuves. Il devrait également comparer les résultats des agents à ceux de testeurs humains et de produits de sécurité établis.

Des gains cohérents soutiendraient la thèse d’orchestration de Palo Alto Networks. De fortes différences entre environnements montreraient que les acheteurs ont besoin d’attentes de déploiement plus limitées.

Le troisième signal est la manière dont les concurrents relient la découverte autonome à l’action. Microsoft, CrowdStrike, Google et des entreprises spécialisées dans la sécurité intègrent tous davantage les agents dans les workflows opérationnels.

Une réponse concurrentielle crédible combinerait des tests persistants, une remédiation gouvernée et une vérification dans des environnements technologiques mixtes. Un autre assistant conversationnel ne répondrait pas au même problème.

La pression concurrentielle devrait également améliorer la transparence. Les acheteurs ont besoin d’éléments comparables sur le comportement des modèles, les autorisations, le traitement des données, la supervision humaine et les résultats des remédiations.

Palo Alto Networks a identifié un véritable décalage. Les attaquants peuvent automatiser la reconnaissance et l’exploitation, tandis que de nombreux défenseurs attendent encore des évaluations programmées et des tickets acheminés manuellement.

Unit 42 Continuous Frontier AI Defense s’attaque à ce décalage avec des tests persistants sur plusieurs modèles. Son architecture reconnaît qu’aucun modèle unique ne voit suffisamment et que la validation humaine reste essentielle.

L’épreuve la plus difficile commence après la découverte. Une entreprise doit convertir les résultats en changements attribués, autorisés, testés et durables, sans laisser un agent offensif créer de nouveaux risques.

Les responsables de la sécurité qui évaluent Palo Alto Networks Unit 42 AI Defense devraient commencer par un environnement représentatif et mesurer l’ensemble du cycle de remédiation. Ils devraient suivre les chemins vérifiés, les faux positifs, le délai de clôture, les récidives et l’effort de revue humaine. Ils devraient également documenter chaque autorisation accordée aux agents de test.

La décision ne devrait pas dépendre du fait que la démonstration révèle une faille inquiétante. La plupart des évaluations étendues finissent par en trouver une. La question décisive est de savoir si le service transforme, de manière répétée, les résultats valides en systèmes plus sûrs plus rapidement que le processus actuel de l’organisation.