Exaforce AI Security se lance avec un interrupteur d’arrêt pour les agents incontrôlables

Exaforce a lancé Exaforce AI Security le 15 septembre avec une promesse claire : trouver les agents incontrôlables et les arrêter avant que leurs actions ne provoquent une compromission. Cette version ajoute la découverte sans agent, l’analyse des risques, la détection à l’exécution et un interrupteur d’arrêt des agents à la plateforme existante d’opérations de sécurité d’Exaforce.

L’évolution importante n’est pas un tableau de bord supplémentaire pour suivre l’usage de l’IA. Exaforce veut permettre aux équipes de sécurité de relier les actions d’un agent à l’employé, à l’appareil, aux identifiants, aux fichiers et aux ressources cloud qui les sous-tendent. Cette corrélation est importante car un agent peut effectuer des actions individuellement légitimes qui, ensemble, forment une séquence dangereuse.

Exaforce arrive sur un marché où Microsoft, Cisco et Palo Alto Networks proposent déjà des approches concurrentes de découverte des agents et de contrôle à l’exécution. Son élément distinctif est un modèle sans agent qui exploite les intégrations existantes et la télémétrie des terminaux. La question centrale est de savoir si ce modèle peut identifier les intentions malveillantes avec une précision suffisante pour justifier une intervention automatisée.

Exaforce AI Security relie les actions des agents en un seul incident

Le lancement traite le comportement d’un agent IA comme une séquence connectée, plutôt que comme une collection d’entrées de journal isolées.

Exaforce AI Security est devenu généralement disponible via la plateforme exploitée par l’entreprise et son service de détection et de réponse gérées. Les détails du lancement de l’entreprise décrivent trois fonctions principales : découvrir l’activité IA, identifier les configurations risquées et détecter les menaces pendant le fonctionnement des agents.

La découverte couvre les applications IA, les agents de bureau, l’utilisation des modèles, les serveurs Model Context Protocol, les skills, les plugins et les identifiants associés. Model Context Protocol, généralement abrégé en MCP, est une norme qui permet aux systèmes d’IA de se connecter à des outils externes et à des sources de données.

La plateforme utiliserait des API de fournisseurs de modèles, de services SaaS, de suites de productivité et de systèmes d’identité. Elle analyse également les données de détection et de réponse sur les terminaux déjà collectées par Exaforce. Cette conception signifie que les clients n’ont pas besoin d’installer un autre agent sur les terminaux uniquement pour bénéficier de ces nouvelles capacités.

Exaforce affirme pouvoir distinguer un agent IA des autres processus exécutés sur un appareil. Il associe ensuite ce processus à l’identité d’un employé, à l’appareil utilisé et aux autorisations disponibles pour cette personne.

La plateforme peut suivre l’activité qui s’ensuit, notamment un shell ouvert par un agent, un fichier qu’il lit ou une adresse externe qu’il contacte. Elle surveille également les journaux des fournisseurs de modèles et les sessions de chat IA afin de détecter les informations sensibles, les intentions suspectes, les injections de prompts et les usages inhabituels.

Ce contexte alimente un graphe d’agents. Le graphe relie les employés, les agents, les applications IA, les autorisations OAuth, les identifiants, les serveurs MCP, les fichiers et les ressources accessibles. Les autorisations OAuth sont des permissions déléguées qui permettent à une application d’accéder à un autre service sans recevoir le mot de passe de l’utilisateur.

Cette approche répond à un problème pratique de journalisation. Un agent agit souvent avec les identifiants de la personne qui l’a lancé. Un journal d’audit cloud peut donc indiquer qu’un employé autorisé lit un fichier, fait tourner une clé ou met à jour du code.

Chaque action peut sembler acceptable lorsqu’elle est examinée isolément. Le danger ne devient visible qu’une fois que le système relie les actions et identifie une progression inhabituelle.

Un agent peut lire des cookies de navigateur, utiliser une session stockée pour accéder à un service cloud, puis envoyer des données vers un domaine inconnu. Les outils traditionnels peuvent enregistrer chaque étape sans reconnaître qu’elles constituent un seul incident.

Exaforce indique que son graphe de connaissances combine des informations sur les identités, les terminaux, le cloud, le SaaS, le code et les fournisseurs d’IA. Ses modèles de détection peuvent ensuite évaluer l’ensemble de la séquence par rapport au comportement habituel de l’identité.

L’entreprise donne également aux équipes de sécurité le choix quant à l’autonomie de la réponse. Une action peut nécessiter l’approbation d’un analyste, s’exécuter automatiquement ou se situer entre ces deux modes selon la politique de l’organisation.

Le rapport indépendant sur le lancement indique que les options de réponse comprennent la révocation des sessions, la désactivation des clés de fournisseurs de modèles, l’isolation des appareils et l’arrêt des processus d’agents. Exaforce regroupe ces actions sous le terme « interrupteur d’arrêt des agents ».

Cette expression évoque un bouton d’arrêt universel. En pratique, il s’agit d’un ensemble d’actions de confinement appliquées aux ressources qui soutiennent un agent.

Un processus peut être arrêté, mais le même flux de travail peut conserver des identifiants ou redémarrer ailleurs. Un confinement efficace exige donc un contrôle coordonné des processus, des sessions, des clés, des appareils et des services connectés.

La détection des agents incontrôlables devient un problème d’identité

Le défi de sécurité commence lorsqu’un logiciel autonome hérite d’un accès humain de confiance, mais opère plus vite et de manière moins prévisible que son propriétaire.

Un agent d’entreprise fonctionne rarement de manière isolée. Il peut recevoir une tâche, lire des documents internes, appeler des API, invoquer des outils locaux, créer du code et communiquer avec d’autres services.

Ces capacités donnent aux agents une valeur opérationnelle. Elles transforment aussi une instruction erronée, une intégration compromise ou un prompt malveillant en une chaîne d’actions authentifiées.

C’est pourquoi la détection des agents incontrôlables d’Exaforce se concentre fortement sur l’identité. Le système doit déterminer qui a lancé l’agent, quelle identité il représente, quels identifiants il peut utiliser et quelles ressources ces identifiants peuvent atteindre.

L’identité d’un employé conventionnel suit un schéma relativement compréhensible. Les équipes de sécurité connaissent le rôle de la personne, ses appareils habituels, ses applications normales et son horaire de travail attendu.

Un agent complique ce modèle. Il peut fonctionner en continu, accomplir rapidement de nombreuses actions et sélectionner des outils sans demander d’approbation à chaque étape. Il peut aussi lancer des processus locaux ou utiliser des permissions accordées pour un flux de travail humain plus large.

Il en résulte un déficit d’attribution. Le journal identifie l’employé, mais celui-ci n’a pas initié manuellement chacune des actions enregistrées. Les enquêteurs doivent distinguer l’intention humaine de l’exécution par l’agent.

Exaforce soutient que les outils existants pour les terminaux et le SaaS n’ont pas été conçus pour faire cette distinction. Le directeur général Ankur Singla a déclaré que les équipes de sécurité doivent combiner l’activité des agents avec les informations d’identité, de cloud et de terminaux qu’elles collectent déjà.

L’entreprise illustre ce problème par un agent IA de bureau exécuté avec ses prompts de sécurité désactivés. Selon Exaforce, l’agent a ouvert un shell, copié une base de données de cookies de navigateur et l’a parcourue à la recherche de cookies de session d’entreprise.

Le terminal n’a pas bloqué l’activité. Exaforce affirme que sa plateforme a suivi l’arbre des processus, associé l’activité à une adresse externe et l’a reliée à 15 conclusions antérieures impliquant le même utilisateur et la même adresse.

L’entreprise a classé l’incident comme une conclusion de priorité un et affirme qu’il a été trié en 11 minutes. Ces détails proviennent de l’environnement propre d’Exaforce ou de la télémétrie de ses clients et n’ont pas fait l’objet d’une comparaison indépendante.

Le scénario montre néanmoins pourquoi l’analyse des séquences à l’exécution est importante. La lecture d’une base de données de navigateur peut être suspecte, mais le comportement environnant en matière d’identité et de réseau détermine le niveau réel de risque.

Un second exemple concerne des permissions OAuth excessives. Exaforce indique avoir trouvé une application OpenAI autorisée à écrire, modifier, envoyer ou supprimer des données dans tout un environnement Google Workspace.

L’entreprise a également identifié une intégration de calendrier Claude disposant de permissions d’écriture et d’envoi plus étendues que ne l’exigeait sa tâche prévue. Ces constats représentent des risques de posture, et non des attaques confirmées.

Cette distinction est importante. Une permission étendue crée un rayon d’impact potentiel, tandis qu’un comportement malveillant à l’exécution indique que le risque est effectivement exploité.

Exaforce AI Security tente de relier ces deux aspects. Sa couche de risque identifie les configurations vulnérables avant un incident, tandis que la détection à l’exécution recherche les usages abusifs actifs.

Pour les équipes de sécurité, cela crée une nouvelle exigence d’inventaire. Elles doivent comprendre non seulement quels modèles les employés utilisent, mais aussi quels agents, skills, plugins et serveurs MCP peuvent transformer la sortie d’un modèle en action.

L’inventaire doit rester à jour. Les employés peuvent installer une extension de codage IA ou connecter un nouvel assistant SaaS sans projet de déploiement centralisé.

Les responsables de la sécurité sont confrontés à des problèmes similaires de shadow IT depuis des années. Les logiciels agentiques élèvent les enjeux, car l’application non approuvée peut agir, et pas seulement stocker ou afficher des informations.

La conception sans agent est le principal pari d’Exaforce

Exaforce parie que la télémétrie existante peut révéler le comportement des agents sans ajouter un nouveau composant de surveillance à chaque terminal.

L’affirmation « sans agent » doit être interprétée avec prudence. Exaforce ne fonctionne pas sans collecteurs de données ni intégrations. Il dépend des informations issues de produits de sécurité des terminaux existants, de fournisseurs de modèles, de systèmes d’identité, de services cloud et de plateformes de productivité.

« Sans agent » signifie que les clients n’installent pas de composant Exaforce supplémentaire spécifiquement pour surveiller les agents IA. La plateforme analyse les données qu’Exaforce ingère déjà ou peut obtenir via les API des fournisseurs.

Cette architecture offre un avantage opérationnel évident. Les équipes de sécurité d’entreprise gèrent déjà des piles de terminaux encombrées, et chaque agent supplémentaire introduit des préoccupations de déploiement, de maintenance, de compatibilité et de performances.

La réutilisation d’une télémétrie établie peut raccourcir le délai de mise en œuvre. Elle peut également intégrer l’activité IA dans la même file d’investigation utilisée pour les incidents liés aux identités, au cloud, aux terminaux et au SaaS.

Cette vue unifiée constitue le mécanisme central d’Exaforce AI Security. La plateforme ne juge pas un agent uniquement selon le prompt envoyé à un modèle ou la réponse renvoyée.

Elle examine plutôt l’activité environnante. Cela comprend les processus sur les appareils, les connexions réseau, l’accès aux fichiers, l’authentification des comptes, les appels cloud, le contexte du code et l’usage des fournisseurs.

Un assistant de codage qui ouvre un shell n’est pas automatiquement malveillant. Ouvrir un shell, lire des fichiers d’identifiants, contacter un domaine inconnu et tenter une connexion cloud forme un schéma plus significatif.

Le même principe s’applique aux applications métier. Un assistant de calendrier qui accède aux événements remplit sa fonction. Le même assistant disposant d’une large autorité pour envoyer des e-mails ou modifier des données d’espace de travail sans rapport mérite un examen plus approfondi.

La couche de risque d’Exaforce évalue également les skills et les plugins avant leur exécution. L’entreprise a décrit la découverte d’un skill lié à la cuisine dont la fonction d’analyse recherchait et exfiltrait des variables d’environnement sensibles.

L’écart entre l’objectif déclaré du skill et le comportement de son code a accru le risque. Il s’agit d’un problème de chaîne d’approvisionnement logicielle exprimé via une extension IA.

Les skills et les serveurs MCP peuvent étendre rapidement les capacités d’un agent. Ils peuvent aussi introduire du code non examiné, des dépendances distantes et des chemins d’accès que les utilisateurs ne comprennent pas.

Exaforce indique que sa plateforme attribue des scores de risque et des recommandations à ces composants. Une telle notation peut aider à prioriser les examens, mais son utilité dépend de la qualité de la détection et du contexte disponible.

Le modèle sans agent crée aussi sa principale limite. Exaforce ne peut analyser que l’activité représentée dans la télémétrie qu’il reçoit.

Un produit de sécurité des terminaux peut montrer qu’un processus a lu un fichier, sans révéler le raisonnement complet de l’agent ni le prompt ayant déclenché l’action. Un fournisseur de modèles pourrait exposer des journaux d’utilisation sans enregistrer chaque appel à un outil local.

Les API des fournisseurs diffèrent également en matière de couverture et de temporalité. Certaines offrent des pistes d’audit riches, tandis que d’autres exposent des informations administratives limitées. Les modèles hébergés localement ou les agents personnalisés peuvent produire des enregistrements encore différents.

Le trafic chiffré, les outils non pris en charge, les appareils déconnectés et les processus éphémères peuvent créer des angles morts. Un système assemblé à partir de journaux existants doit identifier et divulguer clairement ces lacunes.

Cela n’invalide pas l’architecture. Cela signifie que « sans agent » décrit la simplicité de déploiement, et non une observabilité complète.

Un acheteur évaluant le produit devrait demander quels signaux sont disponibles pour chaque type d’agent. La réponse variera selon ChatGPT, Gemini, Copilot, Claude, les agents de codage locaux, les workflows personnalisés et les modèles auto-hébergés.

Les déploiements les plus solides combineront probablement les enregistrements des fournisseurs avec la télémétrie des terminaux, du réseau, des identités et du cloud. L’absence de l’une de ces couches peut affaiblir l’attribution ou retarder l’endiguement.

Pour les équipes qui envoient déjà ces signaux dans Exaforce, l’intégration pourrait être relativement directe. Les organisations utilisant des produits de terminaux ou d’identité non pris en charge pourraient connaître une expérience différente.

Microsoft, Cisco et Palo Alto contrôlent déjà des couches essentielles

Exaforce ne crée pas la catégorie de la sécurité des agents ; il défie de plus grands fournisseurs sur la question de savoir où le contrôle doit résider.

Microsoft a positionné Agent 365 comme un plan de contrôle destiné à observer, gouverner et sécuriser les agents. Il couvre les agents utilisant un accès délégué d’employés et ceux opérant avec leurs propres identifiants.

Le plan de contrôle des agents de l’entreprise combine l’administration de Microsoft Defender, Intune, Entra et Microsoft 365. Il peut découvrir les agents locaux et cloud, cartographier les identités et les ressources, et appliquer des politiques aux agents pris en charge.

Microsoft affirme également que Defender peut associer un agent à son appareil, à l’identité correspondante, aux serveurs MCP configurés et aux ressources cloud accessibles. Cela ressemble fortement au contexte fondé sur des graphes que promeut Exaforce.

La différence stratégique réside dans la distribution. Microsoft contrôle déjà l’identité, la productivité, la gestion des appareils et la sécurité des terminaux dans de nombreuses entreprises.

Agent 365 peut donc faire de la gouvernance des agents une fonctionnalité d’un environnement d’administration Microsoft existant. Exaforce doit démontrer pourquoi une couche de sécurité indépendante offre un contexte plus large ou plus utile.

L’avantage de Microsoft peut aussi constituer une limite. Les entreprises utilisent des agents et des services répartis entre plusieurs clouds, fournisseurs de modèles, terminaux et plateformes SaaS. Une équipe de sécurité peut préférer un fournisseur qui n’est pas centré sur un seul écosystème logiciel.

Palo Alto Networks aborde le problème via Prisma AIRS, sa plateforme de sécurité de l’IA. Prisma AIRS 3.0 comprend la découverte d’agents, l’analyse d’artefacts, le red teaming, les contrôles d’identité et l’application de politiques à l’exécution.

Son AI Agent Gateway est conçu comme un point central de gouvernance et de contrôle à l’exécution. Palo Alto Networks relie également la sécurité de l’IA à ses produits de réseau, de cloud, de navigateur et de terminaux.

Cisco emprunte une autre voie avec AI Defense. Sa protection à l’exécution couvre les prompts, les réponses, les flux de données, les interactions MCP et les workflows d’agents.

Cisco peut s’appuyer sur la visibilité réseau et le renseignement sur les menaces. Cette position l’aide à inspecter le trafic entre les agents, les modèles, les utilisateurs et les services externes.

Ces concurrents montrent que le marché converge autour de plusieurs fonctions communes :

• Découvrir les agents autorisés et non autorisés.

• Associer les agents à des propriétaires et à des identités.

• Cartographier les outils, les autorisations, les données et les ressources accessibles.

• Évaluer les compétences, les modèles, les prompts et les intégrations.

• Surveiller les comportements pendant que les agents opèrent.

• Bloquer les actions dangereuses ou révoquer les accès.

• Conserver des éléments de preuve pour les enquêtes.

La distinction d’Exaforce consiste à placer ces fonctions au sein de sa plateforme d’opérations de sécurité agentique. L’entreprise soutient que l’activité des agents doit apparaître dans le même contexte d’investigation que tous les autres signaux de l’entreprise.

Cette conception pourrait séduire les prestataires de services de sécurité managés et les équipes de sécurité restreintes. Ils pourraient préférer une seule file opérationnelle plutôt qu’une autre console spécialisée de sécurité de l’IA.

Cependant, les grands fournisseurs de plateformes peuvent avancer le même argument de consolidation. Microsoft peut consolider autour de son plan de contrôle administratif. Palo Alto Networks peut consolider autour de son portefeuille de sécurité. Cisco peut consolider autour de l’application des politiques réseau et à l’exécution.

La question concurrentielle n’est donc pas de savoir qui proposera en premier un inventaire d’agents ou un bouton d’arrêt. Il s’agit de savoir qui peut recueillir le contexte le plus pertinent et le transformer en décisions précises.

Exaforce exploite également ses propres agents de sécurité IA, appelés Exabots, pour la détection, le triage, l’investigation, la chasse aux menaces et la réponse. Sa plateforme utilise désormais des agents IA pour aider à sécuriser d’autres agents IA.

Cette symétrie crée à la fois de la valeur et des risques. L’analyse automatisée peut traiter une activité complexe plus rapidement qu’une équipe humaine, mais un jugement erroné du modèle peut déclencher une action d’endiguement inutile.

Les paramètres d’approbation humaine offrent aux clients un moyen de gérer ce risque. Pourtant, exiger une approbation pour chaque réponse peut réduire l’avantage de vitesse promis par l’automatisation.

Le marché évolue en définitive vers une autonomie graduée. Les actions à faible risque peuvent s’exécuter automatiquement, tandis que les réponses perturbatrices nécessitent des preuves plus solides ou une confirmation humaine.

Un bouton d’arrêt d’agent ne peut pas compenser une détection défaillante

Un contrôle de réponse n’est fiable qu’à la hauteur des éléments de preuve utilisés pour l’activer.

L’expression « bouton d’arrêt d’agent » suggère la certitude. Un système détecte un agent malveillant, un opérateur appuie sur un bouton et la menace disparaît.

Les environnements d’entreprise sont moins ordonnés. Les agents reposent sur des processus, des identifiants, des comptes chez les fournisseurs de modèles, des intégrations, des sessions de navigateur et des ressources cloud. Mettre fin à un composant ne supprime pas toujours le reste.

Un attaquant peut conserver un jeton OAuth après la fin d’un processus d’agent. Un workflow planifié peut relancer le processus. Une identité compromise peut initier les mêmes actions via un autre outil.

C’est pourquoi les options de réponse d’Exaforce vont au-delà de l’arrêt des processus. La révocation de sessions, la désactivation de clés, l’isolation d’appareils et les contrôles d’identité peuvent supprimer plusieurs voies simultanément.

Ces actions peuvent aussi interrompre un travail légitime. Isoler l’appareil d’un développeur ou révoquer un identifiant de production entraîne des conséquences opérationnelles, en particulier lorsque le niveau de confiance de la détection est incertain.

Les faux positifs comptent donc autant que les attaques manquées. Une plateforme qui alerte à chaque invocation du shell, lecture d’un gros fichier ou domaine inconnu submergera les analystes et découragera la réponse automatique.

Exaforce affirme que ses modèles contextuels réduisent ce problème en reliant des comportements connexes. Cette affirmation est plausible, mais les documents de lancement ne fournissent pas de mesures indépendantes des taux de détection.

Ils ne divulguent pas non plus les taux de faux positifs des nouvelles fonctions de sécurité des agents. Aucun benchmark public ne compare la détection d’agents malveillants d’Exaforce à celle de Microsoft, Cisco, Palo Alto Networks ou de fournisseurs spécialisés.

La couverture représente une autre incertitude. Exaforce cite de grands fournisseurs, dont OpenAI, Google, Microsoft et Anthropic. Les entreprises exploitent également des agents personnalisés, des modèles open source, des extensions de navigateur et des systèmes d’orchestration internes.

L’efficacité du produit dépendra de sa capacité à reconnaître systématiquement ces différentes implémentations. Un agent exécuté dans un outil non pris en charge pourrait apparaître comme un processus ordinaire.

Le contexte comportemental peut aider, mais le contexte n’est pas l’intention. Un agent de test de sécurité pourrait collecter des cookies ou sonder des limites d’accès dans le cadre d’un exercice autorisé.

Un agent compromis peut également imiter un travail normal. Il pourrait exfiltrer de petites quantités de données par l’intermédiaire d’un service approuvé ou rester dans les schémas d’accès existants de l’utilisateur.

Les réponses automatisées soulèvent une question de gouvernance. Les clients doivent décider quelles actions la plateforme peut effectuer sans confirmation et qui est responsable lorsque ces actions provoquent des perturbations.

Une politique mature devrait relier l’autorité de réponse au niveau de confiance, à la sensibilité des actifs et à l’impact sur l’activité. Mettre fin à un processus expérimental de faible valeur diffère de la désactivation d’un identifiant utilisé par des systèmes de production.

Les équipes de sécurité devraient également tester les modes de défaillance avant d’activer une autonomie complète. Des exercices peuvent mesurer si un terminal isolé reste accessible pour l’investigation et si la révocation de clés affecte des services non liés.

Les éléments de preuve les plus crédibles viendront de déploiements clients documentés. Les acheteurs doivent savoir combien de temps prend la découverte, quels agents restent invisibles et combien de résultats nécessitent une correction par un analyste.

Ils ont également besoin d’exemples impliquant une activité adversaire réelle, et non seulement des autorisations risquées ou des configurations de test délibérément non sûres. Les constats de posture et les détections de menaces résolvent des problèmes différents.

Les exemples rapportés par Exaforce sur des locataires en production offrent une première vision. Ils n’établissent pas une performance générale dans des environnements d’entreprise diversifiés.

C’est le principal compromis derrière Exaforce AI Security. Le déploiement sans agent peut réduire les frictions de déploiement, mais la dépendance à la télémétrie existante peut produire une visibilité inégale.

Le produit pourrait bien fonctionner là où Exaforce reçoit déjà des données riches sur les terminaux, les identités, le cloud et les fournisseurs. Ses conclusions seront moins certaines partout où ces signaux sont incomplets.

Ce qui prouvera l’efficacité d’Exaforce AI Security

Le prochain test n’est pas une nouvelle annonce de fonctionnalités ; ce sont des preuves mesurables que la plateforme identifie des séquences dangereuses sans perturber les agents légitimes.

Le premier signal à surveiller est une validation indépendante par les clients. Exaforce a besoin de rapports de déploiement montrant quels agents il a découverts, quels risques il a initialement manqués et comment les analystes ont traité ses résultats.

Des éléments de preuve utiles distingueraient la couverture de l’inventaire, l’analyse de posture, la détection active des menaces et la réponse. Regrouper ces résultats dans une seule affirmation de succès rendrait l’évaluation difficile.

Les résultats clients devraient également divulguer la télémétrie disponible dans chaque environnement. Les performances de détection fondées sur une couverture étendue des terminaux et des identités ne devraient pas être généralisées aux organisations disposant de moins d’intégrations.

De solides résultats sur le terrain renforceraient l’affirmation d’Exaforce selon laquelle les données existantes peuvent soutenir une sécurité à l’exécution sans agent. Des angles morts persistants affaibliraient l’argument central de conception.

Le deuxième signal est une couverture d’intégration plus large. Le lancement actuel se connecte à de grands fournisseurs de modèles et utilise les données existantes des terminaux et de l’entreprise.

L’adoption d’agents par les entreprises ne restera pas concentrée dans quelques produits. Les équipes internes peuvent assembler des agents à partir de modèles ouverts, de frameworks de code, de serveurs MCP, d’outils en ligne de commande et d’API personnalisées.

Exaforce doit continuer à reconnaître de nouvelles formes d’agents sans exiger un capteur dédié pour chacune d’elles. Les annonces d’intégration ne comptent que lorsqu’elles exposent suffisamment de données pour l’attribution et la réponse.

La prise en charge de la seule découverte est insuffisante. Les équipes de sécurité ont besoin des relations entre processus, des appels d’outils, des autorisations, des identifiants, des destinations réseau et des contrôles de réponse.

Le troisième signal est la manière dont les concurrents réagissent. Microsoft, Palo Alto Networks et Cisco occupent déjà des points d’application précieux sur les identités, les terminaux, les réseaux et les clouds.

Si ces fournisseurs font du contexte interplateforme des agents une composante standard de leurs produits existants, Exaforce subira une pression de distribution plus forte. Si leurs outils restent liés à des écosystèmes étroits, une couche de corrélation indépendante devient plus attrayante.

Le prix n’est pas le seul facteur d’achat. Les équipes de sécurité compareront l’effort de déploiement, la qualité des investigations, la profondeur des intégrations, les options de services managés et les conséquences d’une action automatisée incorrecte.

La position d’Exaforce est la plus claire pour les organisations qui utilisent déjà sa plateforme d’opérations de sécurité ou son service MDR. Les nouvelles capacités peuvent intégrer l’activité des agents IA à un workflow établi.

Les nouveaux clients sont confrontés à une décision plus large concernant leur plateforme. Ils doivent comparer Exaforce aux contrôles déjà inclus dans leur pile d’identité, de terminaux, de cloud ou de réseau.

Le lancement met également en lumière le besoin croissant d’une mémoire institutionnelle autour de l’activité des agents. Les enquêteurs doivent pouvoir accéder aux décisions, aux approbations, aux preuves d’incidents et aux enseignements tirés des déploiements précédents.

Une base de connaissances IA consultable peut aider les équipes à préserver ce contexte, même si elle ne remplace pas les contrôles de sécurité à l’exécution.

Pour les acheteurs en entreprise, la mesure immédiate consiste à inventorier les agents et leurs accès avant de choisir une plateforme de sécurité. Identifiez qui est responsable de chaque agent, quels identifiants il utilise et quels systèmes il peut modifier.

Testez ensuite Exaforce AI Security ou une plateforme concurrente face à des scénarios réalistes. Incluez l’injection de prompt, les autorisations OAuth excessives, les chaînes d’outils suspectes, l’accès aux identifiants, les mouvements de données et les workflows légitimes qui ressemblent à des attaques.

Mesurez à la fois la détection et la perturbation. La plateforme gagnante ne sera pas celle qui emploie le langage le plus spectaculaire sur les mécanismes d’arrêt d’urgence. Ce sera celle qui distinguera systématiquement l’autonomie dangereuse de l’automatisation productive, puis réagira au bon niveau.