La plateforme CNAPP d’OX Security réunit la posture cloud et la défense à l’exécution des agents IA

OX Security a lancé une plateforme CNAPP le 16 septembre, associant des contrôles cloud éprouvés à une surveillance en temps réel des agents IA. Baptisée OX Cloud, la plateforme CNAPP d’OX Security vise une lacune de sécurité créée lorsque des logiciels autonomes acquièrent des identités, des autorisations et l’accès à des outils d’entreprise.

Ce lancement ne constitue pas simplement une nouvelle extension d’une liste de fonctionnalités de sécurité cloud. OX affirme que les équipes de sécurité ont besoin d’un seul graphe reliant le code, la configuration cloud, les identités, les données, les prompts et les actions d’agents en direct. Cette affirmation remet en question à la fois les produits CNAPP conventionnels et les outils de sécurité IA distincts.

Palo Alto Networks et d’autres grands fournisseurs de sécurité proposent déjà une protection à l’exécution, une gestion de la posture IA et des contrôles des agents. OX doit donc démontrer que son contexte allant du prompt à l’exécution permet de prendre de meilleures décisions, et pas seulement d’offrir un tableau de bord plus vaste.

La question centrale est de savoir si la combinaison de ces signaux aide les défenseurs à isoler les risques atteignables et les comportements d’agents dangereux. Si c’est le cas, OX Cloud pourrait réduire l’écart entre la découverte d’une faiblesse cloud et la compréhension de la manière dont un système autonome pourrait l’exploiter.

La plateforme CNAPP d’OX Security étend la visibilité aux activités d’agents en direct

OX Cloud ajoute le comportement des agents aux signaux d’infrastructure, d’identité, de vulnérabilité et de données que les plateformes de sécurité cloud collectent déjà.

Une plateforme de protection des applications cloud-native, ou CNAPP, réunit plusieurs fonctions de sécurité cloud au sein d’un même système. Ces fonctions comprennent généralement la surveillance de la configuration, la protection des charges de travail, l’analyse des droits, la gestion des vulnérabilités et la cartographie des chemins d’attaque.

OX Cloud comprend la gestion de la posture de sécurité cloud, la gestion de la posture Kubernetes, la gestion de la posture de sécurité des données, la détection des vulnérabilités à l’exécution, l’inventaire cloud et l’analyse des chemins d’attaque fondée sur les graphes. L’entreprise ajoute également AI Detection and Response, qu’elle abrège en AIDR.

La différence tient à ce qu’OX veut que la plateforme observe. Les outils de posture conventionnels examinent des ressources telles que les buckets de stockage, les conteneurs, les identités, les chemins réseau et les politiques d’accès. OX Cloud cherche aussi à identifier les agents, les modèles, les prompts et les serveurs Model Context Protocol opérant dans cet environnement.

MCP est une interface standard qui permet aux systèmes IA de se connecter à des outils et à des données externes. Un serveur MCP peut exposer une base de données, un système de fichiers, un service de tickets, un dépôt de code ou une API interne à un agent.

Cette connexion rend un agent plus utile, mais elle transforme également les sorties du modèle en actions. Un agent manipulé pourrait récupérer des enregistrements restreints, appeler un outil non approuvé ou utiliser un identifiant valide en dehors de son flux de travail prévu.

OX affirme que sa plateforme relie ces actions au contexte cloud environnant. Selon l’annonce d’OX Cloud de l’entreprise, le produit peut inventorier les charges de travail, les identités, les magasins de données, les clusters Kubernetes et les agents IA actifs.

La plateforme utilise ensuite l’analyse d’atteignabilité pour hiérarchiser les résultats. L’atteignabilité détermine si un composant exposé, un package vulnérable ou une autorisation excessive peut effectivement se connecter à une ressource précieuse ou à un chemin d’exécution.

Cette approche est importante, car les scanners cloud peuvent produire de longues listes de résultats techniquement valides. Un package vulnérable au sein d’une charge de travail isolée ne présente pas le même risque immédiat que ce package dans un service exposé à Internet ayant accès aux dossiers clients.

OX applique cette logique aux agents. Un prompt douteux ou un appel d’outil inhabituel devient plus important lorsque l’agent responsable peut atteindre des données de production, des API d’administration ou des systèmes de déploiement.

L’entreprise indique également qu’OX Cloud peut associer une activité à l’exécution au prompt ou au code qui l’a initiée. Cette connexion pourrait aider les enquêteurs à reconstituer pourquoi un agent a effectué une action, plutôt que de simplement enregistrer que l’action a eu lieu.

Il s’agit toujours d’affirmations du fournisseur. OX a décrit des capacités et une architecture de produit, mais n’a pas publié de taux de détection comparatifs, de mesures des faux positifs, de surcharge de déploiement ou d’évaluations indépendantes pour ce lancement.

Cette lacune en matière de preuves ne rend pas le produit non pertinent. Elle définit ce que les acheteurs d’entreprise doivent valider avant de considérer la nouvelle plateforme comme un plan de contrôle consolidé.

Pourquoi les agents IA mettent la sécurité cloud traditionnelle sous pression

Les agents concentrent plusieurs problèmes de sécurité familiers au sein d’une identité évoluant rapidement, capable de raisonner, de choisir des outils et d’initier des changements.

Une charge de travail traditionnelle suit généralement du code que les ingénieurs peuvent examiner avant son déploiement. Ses autorisations peuvent néanmoins être excessives, et ses dépendances peuvent toujours contenir des vulnérabilités. Toutefois, le chemin d’exécution attendu est relativement stable.

Un agent se comporte différemment. Il interprète des instructions, récupère du contexte, sélectionne des outils et construit une séquence d’actions à l’exécution. De petits changements dans les prompts, les documents récupérés, les versions de modèles ou les descriptions d’outils peuvent modifier cette séquence.

Cette variabilité ne signifie pas que le comportement des agents est inconnaissable. Elle signifie que les défenseurs ont besoin de télémétrie autour du chemin de décision comme des appels système qui en résultent.

L’identité est un élément central de ce problème. Un agent agissant via un compte de service partagé peut rendre les journaux difficiles à interpréter. Les enquêteurs peuvent voir une requête de base de données ou une modification de fichier sans savoir quel agent l’a initiée, pourquoi il a agi ou qui a autorisé le flux de travail.

Les recommandations de Microsoft sur le moindre privilège préconisent de traiter chaque agent comme un principal distinct. Chaque agent devrait disposer d’une identité managée, d’un propriétaire explicite, de rôles à périmètre restreint et d’un manifeste d’outils approuvé.

Ce modèle crée une limite mesurable. Les équipes peuvent déterminer quels outils un agent devrait appeler, à quelles ressources il peut accéder et si son activité à l’exécution demeure dans le cadre de sa mission assignée.

Le problème devient plus grave lorsque les serveurs MCP héritent d’identifiants étendus. MCP prend en charge des mécanismes d’autorisation, y compris OAuth, mais le protocole n’applique pas automatiquement une politique sûre à chaque déploiement.

Microsoft a signalé que 15 pour cent des serveurs MCP distants observés par les signaux de Defender for Cloud autorisaient un accès non authentifié à des données sensibles ou à des capacités opérationnelles. Ses conclusions sur l’exposition MCP incluaient des connexions à des systèmes de tickets, des dépôts privés et des outils de ressources humaines.

Ce chiffre ne décrit pas tous les déploiements MCP. Il démontre néanmoins que la connectivité des agents peut exposer de véritables systèmes d’entreprise lorsque l’authentification et les limites d’exécution sont mal configurées.

Une analyse de posture peut identifier le serveur exposé. Un produit d’identité peut trouver son identifiant. Un outil d’exécution peut enregistrer un appel suspect. OX parie qu’un graphe partagé peut relier ces trois éléments avant qu’un analyste ne reconstitue manuellement la chaîne.

C’est l’argument le plus convaincant pour combiner les données CNAPP à la défense à l’exécution des agents IA. La menace n’est ni entièrement un problème d’application ni entièrement un problème cloud.

Prenons un agent chargé de résoudre des demandes de support. Il peut lire des tickets, rechercher dans la documentation interne et mettre à jour des dossiers clients. Un prompt indirect caché dans un ticket pourrait lui demander de récupérer des dossiers sans rapport ou d’envoyer des données vers un point de terminaison externe.

Un filtre de prompt pourrait signaler l’instruction. Toutefois, sa gravité dépend de l’identité utilisée par l’agent, des outils qu’il peut appeler et des dossiers auxquels ces outils peuvent accéder.

À l’inverse, un appel API inhabituel n’indique pas toujours une attaque. L’agent peut accomplir une tâche légitime après avoir rencontré une demande peu courante. Les défenseurs ont besoin de suffisamment de contexte pour distinguer un comportement inattendu d’un comportement non autorisé.

OX Cloud est conçu autour de cette distinction. Sa promesse ne consiste pas simplement à détecter des prompts étranges. Elle consiste à relier le comportement en direct aux actifs atteignables, aux autorisations effectives et au chemin logiciel à l’origine de l’action.

OX Cloud fait de l’atteignabilité son principal facteur de différenciation

Le mécanisme central de la plateforme est une priorisation liée aux preuves, dans laquelle le comportement à l’exécution et les chemins d’attaque déterminent quels résultats méritent attention.

Les équipes de sécurité cloud peinent déjà face au volume d’alertes. Les scanners de posture détectent les mauvaises configurations, les outils de vulnérabilité énumèrent les packages, les systèmes d’identité identifient les autorisations excessives et les outils de données classifient les magasins sensibles.

L’ajout d’agents peut créer un inventaire supplémentaire sans résoudre cette fragmentation. Une équipe de sécurité pourrait apprendre qu’un agent existe, utilise un modèle particulier et se connecte à plusieurs outils. Ces faits ne montrent toujours pas si son comportement crée un chemin exploitable.

OX décrit un flux de travail en quatre étapes : identifier, prioriser, enquêter et gouverner. Les étapes utilisent les mêmes données contextuelles au lieu de fonctionner comme des modules produits déconnectés.

L’identification couvre les charges de travail, les identités, les agents, les magasins de données et les actifs cloud. OX indique que cela inclut des ressources découvertes à partir de l’activité observée, et pas seulement des ressources déclarées dans des fichiers de configuration.

La priorisation applique l’atteignabilité aux vulnérabilités, aux autorisations, aux mauvaises configurations et à l’exposition de la chaîne d’approvisionnement. Les résultats qui ne peuvent pas se connecter à une charge de travail active ou à un actif précieux reçoivent un degré d’urgence moindre.

L’enquête utilise un graphe cloud pour reconstituer les relations entourant un événement. Un analyste devrait pouvoir voir quelle identité a agi, quelle ressource elle a touchée et quels systèmes supplémentaires étaient atteignables.

La gouvernance applique des restrictions à l’activité des agents et à l’utilisation de l’IA. C’est là que les fonctions AIDR et de surface d’attaque agentique d’OX deviennent plus que de simples fonctions de découverte.

Le mécanisme paraît cohérent, mais sa qualité dépend de la fidélité des données. OX doit découvrir les actifs de manière fiable, interpréter les autorisations, tracer les appels des agents et conserver suffisamment de contexte pour l’enquête.

Les lacunes de couverture peuvent créer un faux sentiment de confiance. Un appel d’outil non observé, un identifiant non géré, un chemin de trafic chiffré ou un framework d’agents non pris en charge pourraient rompre la chaîne reliant le prompt au résultat.

La corrélation des données peut aussi produire des conclusions ambiguës. Un prompt apparaissant peu avant un appel API ne prouve pas automatiquement qu’il a provoqué cet appel. Les flux de travail de longue durée, les agents parallèles, les nouvelles tentatives et les sous-tâches déléguées compliquent l’attribution.

OX doit donc distinguer la corrélation de la causalité dans son interface. Les analystes ont besoin d’horodatages, de chaînes d’invocation, d’enregistrements d’identité, de décisions de politique et de traces d’application qui étayent la relation proposée.

L’architecture de déploiement compte également. L’inspection à l’exécution peut s’effectuer par interception réseau, capteurs de charge de travail, bibliothèques d’applications, passerelles API, journaux cloud ou intégrations avec des frameworks d’agents.

Chaque méthode offre une visibilité différente. Les contrôles réseau peuvent observer les destinations et les charges utiles, mais manquer le raisonnement interne. L’instrumentation des frameworks peut capturer la sélection d’outils, mais fournir une couverture incomplète pour les applications personnalisées.

OX affirme que la plateforme AINAPP plus large relie les étapes de prompt, de code, de build, de déploiement et d’exécution. AINAPP est le terme employé par l’entreprise pour désigner une plateforme de protection des applications native de l’IA.

Le concept donne à OX une position potentiellement utile. Ses produits de sécurité applicative examinent déjà le code source et les chaînes d’approvisionnement logicielles. OX Cloud étend cette approche à l’infrastructure déployée et à l’activité des agents en production.

Toutefois, les acheteurs devraient se demander comment cette connexion fonctionne pour le code et les agents qui ne sont pas déjà gérés par les produits OX. Une plateforme unifiée offre une valeur limitée si le contexte le plus riche n’apparaît qu’au sein d’une chaîne d’outils étroitement contrôlée.

Le test pratique est un incident réel. Une équipe de sécurité devrait injecter une description d’outil suspecte, déclencher une tentative d’accès non autorisé et vérifier si OX reconstitue l’ensemble du parcours.

Cet exercice devrait montrer le contenu à l’origine de l’action, l’identité de l’agent, l’outil sélectionné, les paramètres, la destination, l’autorisation effective, les données affectées et le résultat de l’application des règles. Tout résultat moins complet obligerait les analystes à recouper des éléments de preuve entre plusieurs systèmes.

OX Security face aux plateformes CNAPP et de sécurité de l’IA établies

OX est en concurrence avec une consolidation de plateformes menée par de plus grands fournisseurs, et non avec des scanners cloud statiques qui auraient entièrement ignoré l’IA.

Le marché a déjà évolué vers une couverture sur l’ensemble du cycle de vie. Les grands fournisseurs combinent désormais découverte de l’IA, analyse de posture, red teaming, inspection à l’exécution, contrôles d’identité et application des politiques.

Palo Alto Networks présente Prisma AIRS comme une plateforme couvrant les applications d’IA, les modèles, les données et les agents. Sa documentation Prisma AIRS décrit des pare-feux d’exécution, des API, du red teaming, la sécurité des modèles, la gestion de posture et la protection des agents.

Palo Alto intègre également la découverte de l’IA à Cortex Cloud. Cette connexion peut identifier les modèles, les endpoints, les jeux de données, les agents et les relations de dépendance dans Amazon Web Services, Microsoft Azure et Google Cloud.

La principale concurrence dépasse donc le cadre d’OX face à un CNAPP conventionnel. Elle oppose l’intégration centrée sur le contexte d’OX à des plateformes de sécurité historiques qui assemblent des contrôles similaires à partir de leurs portefeuilles de produits existants.

Les acteurs historiques disposent de bases installées, de télémétrie cloud, de renseignements sur les menaces, d’intégrations d’identité et de relations d’approvisionnement établies. Les acheteurs peuvent préférer étendre un contrat existant plutôt qu’introduire une nouvelle plateforme de sécurité.

OX peut répondre par sa spécialisation. Un plus petit fournisseur peut concevoir ses produits autour des flux de travail des agents sans devoir préserver chaque hypothèse architecturale d’une suite de produits plus ancienne.

Son approche allant du code à l’exécution peut également séduire les équipes de sécurité applicative. Ces équipes veulent savoir si une vulnérabilité introduite pendant le développement reste accessible après le déploiement et si un agent peut activer le chemin vulnérable.

Cette connexion pourrait réduire les désaccords entre développeurs et analystes de sécurité. Les développeurs reçoivent souvent des alertes de scanners sans preuve que le code concerné est exposé. Le contexte d’exécution peut établir quels problèmes présentent une pertinence opérationnelle immédiate.

Pourtant, les grands fournisseurs avancent le même argument de consolidation. Palo Alto a déclaré environ 120 millions de dollars de revenus récurrents annuels pour Prisma AIRS après un an de disponibilité générale.

L’entreprise a également déclaré plus de 800 clients Prisma AIRS dans sa présentation du quatrième trimestre de l’exercice 2026. Ces chiffres reposent sur les propres définitions de Palo Alto concernant l’allocation des revenus et les devis enregistrés, mais ils indiquent une demande commerciale significative.

Cette pression concurrentielle oblige OX à démontrer des avantages précis. Une liste de fonctionnalités plus longue ne suffira pas, car les plateformes cloud couvrent déjà bon nombre des mêmes catégories.

OX peut se différencier par des investigations plus rapides, une priorisation plus claire, une prise en charge plus étendue des frameworks ou une attribution plus nette entre prompt et exécution. L’entreprise pourrait également rivaliser par sa flexibilité de déploiement et une complexité opérationnelle moindre.

Les clients devraient comparer les flux de travail plutôt que les intitulés de catégories. Deux produits peuvent revendiquer la découverte des agents, la défense à l’exécution et la gestion de posture tout en collectant des télémétries différentes ou en appliquant les politiques à des étapes différentes.

Une plateforme peut bloquer les prompts malveillants avant le traitement par le modèle. Une autre peut intercepter les appels d’outils, restreindre les autorisations d’identité ou isoler la charge de travail après la détection d’une activité suspecte.

Ces contrôles sont complémentaires, mais leur emplacement affecte la latence, la couverture et les modes de défaillance. Un produit positionné hors du chemin d’exécution peut observer de manière plus sûre tout en ne disposant pas d’une autorité de blocage immédiate.

Un contrôle intégré au flux peut arrêter une action, mais il devient aussi partie intégrante du chemin de disponibilité de l’application. Les acheteurs doivent comprendre ce qui se produit lorsque le service de sécurité ralentit, perd sa connectivité ou ne peut pas classifier une requête.

OX n’a pas fourni publiquement suffisamment d’éléments spécifiques au lancement pour trancher ces comparaisons. Son défi immédiat consiste à transformer une architecture crédible en résultats clients reproductibles.

La défense à l’exécution ne peut pas remplacer la conception des agents et le contrôle des accès

Aucun CNAPP ne peut compenser des agents qui partagent des identités, reçoivent des autorisations excessives ou exécutent des actions à fort impact sans autorisation indépendante.

La surveillance à l’exécution retient souvent l’attention parce qu’elle peut détecter des comportements que les revues statiques ne voient pas. Cette force peut aussi encourager les équipes à considérer l’observation comme un substitut à une architecture plus sûre.

Un agent ne devrait pas obtenir un accès étendu simplement parce qu’un produit de surveillance enregistre ses actions. La journalisation d’un transfert de données non autorisé n’annule pas ce transfert.

La taxonomie des risques agentiques d’OWASP comprend l’utilisation abusive d’outils, l’abus d’identité et de privilèges, l’empoisonnement de mémoire, les défaillances en cascade et les comportements d’agents dévoyés. Ces risques traversent les frontières entre modèles, applications, identités et infrastructures.

Les défenseurs devraient commencer par attribuer des identités distinctes aux agents. Les identifiants partagés obscurcissent la responsabilité et compliquent la révocation. Chaque agent de production a besoin d’un propriétaire nommé, d’un objectif documenté et d’un ensemble limité de ressources autorisées.

L’accès aux outils devrait également être explicite. Un agent conçu pour résumer des tickets de support ne devrait pas hériter d’un accès administratif à la plateforme de tickets. Il ne devrait recevoir que les opérations de lecture nécessaires à cette tâche.

L’accès en écriture mérite une décision distincte. Si le flux de travail évolue pour modifier des enregistrements, l’équipe devrait créer de nouvelles autorisations et règles d’approbation plutôt que d’élargir un rôle existant sans examen.

Les actions à fort impact nécessitent une application déterministe des règles. La suppression de données, la modification d’une infrastructure de production, l’émission de paiements ou la publication de contenu externe ne devraient pas dépendre uniquement de l’interprétation par un modèle d’instructions en langage naturel.

L’approbation humaine reste appropriée pour les actions ayant des conséquences financières, opérationnelles ou juridiques importantes. L’approbation automatisée peut convenir aux tâches à impact moindre lorsque les conditions de la politique sont étroites et appliquées de manière indépendante.

La mémoire introduit un autre risque. Un agent peut stocker l’historique des conversations, des préférences, des faits récupérés ou des plans intermédiaires entre les sessions. Du contenu malveillant peut persister dans cette mémoire et influencer des décisions ultérieures.

Un produit d’exécution devrait exposer les lectures et écritures de mémoire lorsque cela est possible. Il devrait également montrer si un agent a utilisé du contenu récupéré lors de la sélection d’un outil ou de la construction de paramètres.

Toutefois, l’accès à la mémoire peut avoir lieu au sein d’un framework ou d’un service de modèles fournissant une télémétrie limitée. Les acheteurs devraient tester si OX Cloud capture ces interactions dans leur pile de déploiement réelle.

Les faux positifs présentent un défi distinct. Les flux de travail des agents produisent naturellement des séquences d’actions inhabituelles, car ils s’adaptent aux demandes des utilisateurs. Une simple détection d’anomalies peut signaler des variations légitimes et submerger les analystes.

OX affirme que l’accessibilité aide à réduire ce bruit. Cette affirmation est plausible, mais l’accessibilité ne prouve pas une intention malveillante. Un chemin accessible peut prendre en charge un flux de travail légitime, tandis qu’une faille logicielle inaccessible peut devenir pertinente après un changement de configuration.

Les entreprises devraient mesurer la précision lors d’un déploiement contrôlé. Les indicateurs utiles incluent les incidents confirmés, les faux positifs, le temps d’investigation, les tâches légitimes bloquées, les flux de travail non pris en charge et les lacunes de télémétrie.

Elles devraient également mesurer l’impact sur les performances. L’inspection à l’exécution peut ajouter de la latence lorsqu’elle évalue de manière synchrone les prompts, les appels d’outils, les flux de données ou les politiques d’identité.

OX n’a pas publié de chiffres généraux de latence ou de surcharge pour OX Cloud. Les résultats dépendront probablement de la méthode de déploiement, du volume de trafic, de la complexité des politiques et de la quantité de contexte collectée.

Une autre incertitude concerne la cohérence de l’application des règles. Une organisation peut exploiter des agents construits avec plusieurs frameworks dans plusieurs clouds et plateformes SaaS. Une politique doit résister à ces différences architecturales.

Un tableau de bord qui découvre chaque agent mais n’en gouverne qu’un sous-ensemble crée une protection inégale. Les équipes de sécurité ont besoin d’une matrice de compatibilité claire et de preuves que les chemins non pris en charge restent visibles.

La conclusion appropriée n’est pas que la défense à l’exécution manque de valeur. C’est que la surveillance à l’exécution fonctionne le mieux comme une couche au sein d’un système de contrôle plus large.

La conception sécurisée des agents commence par une autorité limitée. La défense à l’exécution vérifie ensuite si le comportement reste dans ces limites et aide les enquêteurs à comprendre les écarts.

Trois signaux montreront si OX Cloud tient ses promesses

Le prochain test repose sur des preuves opérationnelles, notamment une validation client, une réduction mesurable du bruit et une application étendue des règles sur de véritables piles d’agents.

Le premier signal est une preuve client indépendante. OX devrait montrer comment la plateforme fonctionne dans des environnements de production contenant plusieurs clouds, frameworks d’agents, fournisseurs d’identité et serveurs MCP.

Des études de cas utiles quantifieraient le nombre d’agents et d’identités non humaines découverts. Elles devraient également indiquer quels chemins risqués ont été confirmés, combien d’alertes ont été supprimées et comment le temps d’investigation a évolué.

Le deuxième signal est la performance comparative. Les acheteurs ont besoin de tests de détection et d’application des règles couvrant l’injection de prompts, les descriptions d’outils empoisonnées, les autorisations excessives, les séquences API inhabituelles et les tentatives d’exfiltration de données.

Ces tests devraient inclure des variations bénignes afin de mesurer les faux positifs. Un système qui bloque chaque action inhabituelle apporte peu de valeur aux flux de travail adaptatifs.

OX devrait également préciser où l’application des règles intervient. Les clients doivent savoir si les contrôles fonctionnent au sein des charges de travail, via l’inspection réseau, dans les frameworks d’agents ou par l’intermédiaire d’API cloud.

Le troisième signal est la réponse concurrentielle. Palo Alto Networks, Microsoft et d’autres fournisseurs de sécurité intègrent l’identité des agents, la posture, l’inspection à l’exécution et la gouvernance dans de plus grandes plateformes.

Si ces fournisseurs relient le code, les prompts, les identités, les ressources cloud et les appels d’outils avec une précision similaire, la distinction architecturale d’OX se réduira. OX rivalisera alors sur la qualité du déploiement, la vitesse d’investigation, la couverture et le service client.

Si les acteurs historiques maintiennent ces contrôles fragmentés, OX pourra soutenir qu’un unique graphe contextuel produit des décisions plus rapides et plus défendables. Les évaluations des clients détermineront quelle issue reflète la réalité de la production.

Les responsables de la sécurité évaluant la plateforme CNAPP OX Security devraient commencer par un flux de travail d’agent limité. Ils peuvent cartographier son identité, ses outils approuvés, ses données accessibles, ses actions attendues et ses règles d’escalade avant d’activer une couverture plus large.

L’évaluation devrait ensuite introduire des défaillances contrôlées. Testez un serveur MCP exposé, une identité surautorisée, un document empoisonné, un appel d’outil non autorisé et une charge de travail vulnérable accessible.

La plateforme devrait montrer non seulement qu’un événement inhabituel s’est produit, mais aussi pourquoi il importait. Elle devrait relier l’instruction d’origine à l’identité agissante, à l’outil sélectionné, à la ressource accessible, à la décision de politique et au résultat final.

Cette norme s’applique au-delà d’OX. Les produits de sécurité des agents doivent transformer une télémétrie complexe en une application fiable des règles et en investigations explicables.

Ce lancement reflète une véritable évolution de la sécurité cloud. Les agents deviennent des participants actifs du cloud, plutôt qu’une simple catégorie d’actifs à inventorier.

OX Cloud répond à cette évolution en intégrant le comportement d’exécution au même graphe que le code, les charges de travail, les identités et les données. La conception est crédible, mais les affirmations les plus ambitieuses nécessitent encore une validation indépendante.

Les équipes qui envisagent OX Cloud devraient demander un essai représentatif d’un environnement de production, et non une démonstration de fonctionnalités soignée. La plateforme peut-elle identifier chaque agent, distinguer les variations légitimes des usages abusifs et reconstituer une chaîne d’actions complète ? Peut-elle imposer des limites sans ralentir le travail habituel ni créer une nouvelle file d’alertes ? Les réponses à ces questions détermineront si la plateforme CNAPP d’OX Security devient un véritable plan de contrôle ou une couche supplémentaire que les équipes de sécurité devront réconcilier.