La piattaforma CNAPP di OX Security riunisce la postura cloud e la difesa runtime degli agenti AI

OX Security ha lanciato il 16 settembre una piattaforma CNAPP che abbina controlli cloud consolidati al monitoraggio in tempo reale degli agenti AI. La piattaforma CNAPP di OX Security, denominata OX Cloud, mira a colmare una lacuna di sicurezza che si crea quando software autonomi acquisiscono identità, autorizzazioni e accesso agli strumenti aziendali.

Il lancio non rappresenta semplicemente un'altra espansione dell'elenco di funzionalità per la sicurezza cloud. OX sostiene che i team di sicurezza abbiano bisogno di un unico grafo che colleghi codice, configurazione cloud, identità, dati, prompt e azioni degli agenti in esecuzione. Questa tesi mette in discussione sia i prodotti CNAPP convenzionali sia gli strumenti di sicurezza AI separati.

Palo Alto Networks e altri grandi fornitori di sicurezza offrono già protezione runtime, gestione della postura AI e controlli per gli agenti. OX deve quindi dimostrare che il suo contesto dal prompt al runtime consenta decisioni migliori, non soltanto una dashboard più ampia.

La questione centrale è se la combinazione di questi segnali aiuti i difensori a isolare rischi raggiungibili e comportamenti non sicuri degli agenti. In tal caso, OX Cloud potrebbe ridurre la distanza tra l'individuazione di una debolezza cloud e la comprensione di come un sistema autonomo potrebbe sfruttarla.

La piattaforma CNAPP di OX Security estende la visibilità all'attività degli agenti in tempo reale

OX Cloud aggiunge il comportamento degli agenti ai segnali relativi a infrastruttura, identità, vulnerabilità e dati già raccolti dalle piattaforme di sicurezza cloud.

Una piattaforma di protezione delle applicazioni cloud-native, o CNAPP, riunisce diverse funzioni di sicurezza cloud in un unico sistema. Queste funzioni includono comunemente il monitoraggio della configurazione, la protezione dei workload, l'analisi delle autorizzazioni, la gestione delle vulnerabilità e la mappatura dei percorsi di attacco.

OX Cloud include la gestione della postura di sicurezza cloud, la gestione della postura Kubernetes, la gestione della postura di sicurezza dei dati, il rilevamento runtime delle vulnerabilità, l'inventario cloud e l'analisi dei percorsi di attacco basata su grafi. L'azienda sta inoltre aggiungendo AI Detection and Response, abbreviato in AIDR.

La differenza risiede in ciò che OX intende far osservare alla piattaforma. Gli strumenti di postura convenzionali esaminano risorse quali bucket di storage, container, identità, percorsi di rete e policy di accesso. OX Cloud cerca inoltre di identificare agenti, modelli, prompt e server Model Context Protocol che operano in tale ambiente.

MCP è un'interfaccia standard che consente ai sistemi AI di connettersi a strumenti e dati esterni. Un server MCP potrebbe esporre a un agente un database, un file system, un servizio di ticketing, un repository di codice o un'API interna.

Questa connessione offre maggiore utilità a un agente, ma trasforma anche l'output del modello in azioni. Un agente manipolato potrebbe recuperare record riservati, invocare uno strumento non approvato o utilizzare una credenziale valida al di fuori del flusso di lavoro previsto.

OX afferma che la sua piattaforma collega queste azioni al contesto cloud circostante. Secondo l'annuncio di OX Cloud dell'azienda, il prodotto può inventariare workload, identità, archivi dati, cluster Kubernetes e agenti AI attivi.

La piattaforma utilizza quindi l'analisi della raggiungibilità per assegnare priorità ai risultati. La raggiungibilità determina se un componente esposto, un pacchetto vulnerabile o un'autorizzazione eccessiva possano effettivamente connettersi a una risorsa di valore o a un percorso di esecuzione.

Questo approccio è importante perché gli scanner cloud possono produrre lunghi elenchi di risultati tecnicamente validi. Un pacchetto vulnerabile all'interno di un workload isolato non presenta lo stesso rischio immediato dello stesso pacchetto in un servizio esposto a internet con accesso ai record dei clienti.

OX applica questa logica agli agenti. Un prompt discutibile o una chiamata insolita a uno strumento diventa più importante quando l'agente responsabile può raggiungere dati di produzione, API amministrative o sistemi di deployment.

L'azienda afferma inoltre che OX Cloud può associare l'attività runtime al prompt o al codice che l'ha avviata. Tale connessione potrebbe aiutare gli investigatori a ricostruire perché un agente abbia intrapreso un'azione, anziché limitarsi a registrare che l'azione si è verificata.

Restano affermazioni del fornitore. OX ha descritto capacità e architettura del prodotto, ma non ha pubblicato tassi di rilevamento comparativi, misurazioni dei falsi positivi, overhead di deployment o valutazioni indipendenti per questo lancio.

Questa lacuna di evidenze non rende il prodotto irrilevante. Definisce ciò che gli acquirenti aziendali devono convalidare prima di trattare la nuova piattaforma come un piano di controllo consolidato.

Perché gli agenti AI mettono sotto pressione la sicurezza cloud tradizionale

Gli agenti condensano diversi problemi di sicurezza già noti in un'unica identità in rapida evoluzione, capace di ragionare, scegliere strumenti e avviare modifiche.

Un workload tradizionale segue generalmente codice che gli ingegneri possono esaminare prima del deployment. Le sue autorizzazioni possono comunque essere eccessive e le sue dipendenze possono ancora contenere vulnerabilità. Tuttavia, il percorso di esecuzione previsto è relativamente stabile.

Un agente si comporta diversamente. Interpreta istruzioni, recupera contesto, seleziona strumenti e costruisce una sequenza di azioni durante l'esecuzione. Piccole modifiche nei prompt, nei documenti recuperati, nelle versioni dei modelli o nelle descrizioni degli strumenti possono alterare tale sequenza.

Questa variabilità non significa che il comportamento degli agenti sia impossibile da conoscere. Significa che i difensori necessitano di telemetria sia sul percorso decisionale sia sulle chiamate di sistema risultanti.

L'identità è una componente centrale del problema. Un agente che opera tramite un account di servizio condiviso può rendere difficili da interpretare i log. Gli investigatori potrebbero vedere una query al database o una modifica a un file senza sapere quale agente l'abbia avviata, perché abbia agito o chi abbia autorizzato il flusso di lavoro.

Le linee guida sul privilegio minimo di Microsoft raccomandano di trattare ogni agente come un principal distinto. Ogni agente dovrebbe avere un'identità gestita, un proprietario esplicito, ruoli con ambito ristretto e un manifesto degli strumenti approvato.

Questo modello crea un confine misurabile. I team possono determinare quali strumenti un agente dovrebbe chiamare, a quali risorse può accedere e se la sua attività runtime resta entro lo scopo assegnato.

Il problema diventa più serio quando i server MCP ereditano credenziali ampie. MCP supporta meccanismi di autorizzazione, incluso OAuth, ma il protocollo non applica automaticamente una policy sicura per ogni deployment.

Microsoft ha riferito che il 15 percento dei server MCP remoti osservati tramite i segnali di Defender for Cloud consentiva accesso non autenticato a dati sensibili o capacità operative. Le sue rilevazioni sull'esposizione MCP includevano connessioni a sistemi di ticketing, repository privati e strumenti delle risorse umane.

Questa percentuale non descrive tutte le implementazioni MCP. Dimostra però che la connettività degli agenti può esporre sistemi aziendali reali quando autenticazione e confini di esecuzione sono configurati in modo errato.

Una scansione della postura potrebbe identificare il server esposto. Un prodotto di gestione delle identità potrebbe individuare la sua credenziale. Uno strumento runtime potrebbe registrare una chiamata sospetta. OX scommette che un grafo condiviso possa collegare tutti e tre gli elementi prima che un analista ricomponga manualmente la catena.

Questo è l'argomento più solido a favore della combinazione dei dati CNAPP con la difesa runtime degli agenti AI. La minaccia non è né interamente un problema applicativo né interamente un problema cloud.

Si consideri un agente incaricato di risolvere richieste di supporto. Può leggere ticket, cercare documentazione interna e aggiornare i record dei clienti. Un prompt indiretto nascosto in un ticket potrebbe istruire l'agente a recuperare record non correlati o a inviare dati a un endpoint esterno.

Un filtro dei prompt potrebbe segnalare l'istruzione. Tuttavia, la gravità dipende dall'identità utilizzata dall'agente, dagli strumenti che può invocare e dai record a cui tali strumenti possono accedere.

Al contrario, una chiamata API insolita non indica sempre un attacco. L'agente potrebbe stare completando un'attività legittima dopo aver incontrato una richiesta non comune. I difensori necessitano di contesto sufficiente per distinguere un comportamento inatteso da un comportamento non autorizzato.

OX Cloud è progettato attorno a questa distinzione. La sua promessa non è semplicemente rilevare prompt insoliti. È collegare il comportamento in tempo reale con asset raggiungibili, autorizzazioni effettive e il percorso software di origine.

OX Cloud rende la raggiungibilità il suo principale elemento distintivo

Il meccanismo centrale della piattaforma è la prioritizzazione basata su evidenze collegate, in cui il comportamento runtime e i percorsi di attacco determinano quali risultati meritino attenzione.

I team di sicurezza cloud faticano già a gestire il volume degli alert. Gli scanner di postura rilevano configurazioni errate, gli strumenti per le vulnerabilità enumerano pacchetti, i sistemi di identità identificano autorizzazioni eccessive e gli strumenti per i dati classificano gli archivi sensibili.

L'aggiunta degli agenti può creare un ulteriore inventario senza risolvere questa frammentazione. Un team di sicurezza potrebbe scoprire che un agente esiste, utilizza un particolare modello e si connette a diversi strumenti. Questi fatti non mostrano comunque se il suo comportamento crei un percorso sfruttabile.

OX descrive un flusso di lavoro in quattro fasi: identificare, stabilire le priorità, investigare e governare. Le fasi utilizzano gli stessi dati contestuali anziché operare come moduli di prodotto scollegati.

L'identificazione copre workload, identità, agenti, archivi dati e asset cloud. OX afferma che ciò include risorse individuate dall'attività osservata, non solo risorse dichiarate nei file di configurazione.

La prioritizzazione applica la raggiungibilità a vulnerabilità, autorizzazioni, configurazioni errate ed esposizione della supply chain. Ai risultati che non possono connettersi a un workload attivo o a un asset di valore viene attribuita minore urgenza.

L'investigazione utilizza un grafo cloud per ricostruire le relazioni che circondano un evento. Un analista dovrebbe poter vedere quale identità ha agito, quale risorsa ha toccato e quali sistemi aggiuntivi erano raggiungibili.

La governance applica restrizioni all'attività degli agenti e all'utilizzo dell'AI. È qui che le funzioni AIDR e relative alla superficie di attacco agentica di OX diventano più che semplici funzionalità di scoperta.

Il meccanismo appare coerente, ma la sua qualità dipende dalla fedeltà dei dati. OX deve scoprire in modo affidabile gli asset, interpretare le autorizzazioni, tracciare le chiamate degli agenti e conservare contesto sufficiente per l'investigazione.

Le lacune nella copertura possono creare una falsa sensazione di sicurezza. Una chiamata a uno strumento non osservata, una credenziale non gestita, un percorso di traffico crittografato o un framework di agenti non supportato potrebbero interrompere la catena che collega il prompt al risultato.

Anche la correlazione dei dati può produrre conclusioni ambigue. Un prompt che appare poco prima di una chiamata API non dimostra automaticamente di aver causato la chiamata. Flussi di lavoro di lunga durata, agenti paralleli, tentativi ripetuti e sottoattività delegate complicano l'attribuzione.

OX deve quindi distinguere la correlazione dalla causalità all'interno della propria interfaccia. Gli analisti hanno bisogno di timestamp, catene di invocazione, record delle identità, decisioni di policy e tracce applicative che supportino la relazione proposta.

Anche l'architettura di deployment è importante. L'ispezione runtime può avvenire tramite intercettazione di rete, sensori sui workload, librerie applicative, gateway API, log cloud o integrazioni con framework per agenti.

Ogni metodo offre una visibilità diversa. I controlli di rete possono osservare destinazioni e payload, ma non il ragionamento interno. La strumentazione dei framework può acquisire la selezione degli strumenti, ma fornire una copertura incompleta nelle applicazioni personalizzate.

OX afferma che la più ampia piattaforma AINAPP collega le fasi di prompt, codice, build, deployment e runtime. AINAPP è il termine dell'azienda per una piattaforma di protezione delle applicazioni native dell'AI.

Il concetto offre a OX una posizione potenzialmente utile. I suoi prodotti per la sicurezza delle applicazioni esaminano già il codice sorgente e le supply chain del software. OX Cloud estende questo approccio all'infrastruttura distribuita e all'attività degli agenti in tempo reale.

Tuttavia, gli acquirenti dovrebbero chiedersi come funzioni la connessione per il codice e gli agenti non già gestiti tramite i prodotti OX. Una piattaforma unificata offre un valore limitato se il contesto più ricco compare solo all'interno di una toolchain strettamente controllata.

Il test pratico è un incidente reale. Un team di sicurezza dovrebbe inserire una descrizione di strumento sospetta, attivare un tentativo di accesso non autorizzato e verificare se OX ricostruisce l'intero percorso.

L'esercizio dovrebbe mostrare il contenuto iniziale, l'identità dell'agente, lo strumento selezionato, i parametri, la destinazione, l'autorizzazione effettiva, i dati interessati e il risultato dell'applicazione delle policy. Qualsiasi cosa in meno costringe gli analisti a ricomporre le prove tra sistemi diversi.

OX Security si confronta con piattaforme CNAPP e di sicurezza AI consolidate

OX compete contro il consolidamento delle piattaforme guidato da fornitori più grandi, non contro scanner cloud statici che ignoravano completamente l'AI.

Il mercato si è già orientato verso una copertura dell'intero ciclo di vita. I principali fornitori ora combinano rilevamento dell'AI, analisi della postura, red teaming, ispezione runtime, controlli delle identità e applicazione delle policy.

Palo Alto Networks presenta Prisma AIRS come una piattaforma che copre applicazioni AI, modelli, dati e agenti. La sua documentazione Prisma AIRS descrive firewall runtime, API, red teaming, sicurezza dei modelli, gestione della postura e protezione degli agenti.

Palo Alto integra inoltre il rilevamento dell'AI con Cortex Cloud. Questa connessione può identificare modelli, endpoint, dataset, agenti e relazioni di dipendenza tra Amazon Web Services, Microsoft Azure e Google Cloud.

Ciò rende la competizione principale più ampia di OX contro un CNAPP convenzionale. Si tratta dell'integrazione context-first di OX contro piattaforme di sicurezza consolidate che assemblano controlli simili nei portafogli di prodotti esistenti.

Gli operatori storici dispongono di basi installate, telemetria cloud, threat intelligence, integrazioni con le identità e relazioni commerciali consolidate. Gli acquirenti potrebbero preferire estendere un contratto esistente anziché introdurre un'altra piattaforma di sicurezza.

OX può rispondere con la focalizzazione. Un fornitore più piccolo può progettare attorno ai workflow degli agenti senza dover preservare ogni presupposto architetturale di una suite di prodotti meno recente.

La sua narrazione dal codice al runtime può anche attrarre i team di sicurezza delle applicazioni. Questi team vogliono sapere se una vulnerabilità introdotta durante lo sviluppo resta raggiungibile dopo il deployment e se un agente può attivare il percorso vulnerabile.

Questa connessione potrebbe ridurre le controversie tra sviluppatori e analisti della sicurezza. Gli sviluppatori ricevono spesso segnalazioni dagli scanner senza prove che il codice interessato sia esposto. Il contesto runtime può stabilire quali problemi abbiano rilevanza operativa immediata.

Eppure i fornitori più grandi avanzano lo stesso argomento a favore del consolidamento. Palo Alto ha riportato circa 120 milioni di dollari di ricavi ricorrenti annuali per Prisma AIRS dopo un anno di disponibilità generale.

L'azienda ha inoltre riportato oltre 800 clienti Prisma AIRS nella presentazione del quarto trimestre dell'anno fiscale 2026. Queste cifre utilizzano le definizioni proprie di Palo Alto per l'allocazione dei ricavi e le quotazioni contabilizzate, ma indicano una domanda commerciale significativa.

Questa pressione competitiva obbliga OX a dimostrare vantaggi specifici. Un elenco di funzionalità più lungo non sarà sufficiente, poiché le piattaforme cloud coprono già molte delle stesse categorie.

OX può differenziarsi attraverso indagini più rapide, una prioritizzazione più chiara, un supporto più ampio ai framework o un'attribuzione più trasparente dal prompt al runtime. Potrebbe inoltre competere grazie alla flessibilità di deployment e a una minore complessità operativa.

I clienti dovrebbero confrontare i workflow anziché le etichette di categoria. Entrambi i prodotti possono dichiarare rilevamento degli agenti, difesa runtime e gestione della postura, pur raccogliendo telemetria diversa o applicando le policy in punti differenti.

Una piattaforma potrebbe bloccare prompt malevoli prima dell'elaborazione del modello. Un'altra potrebbe intercettare chiamate agli strumenti, limitare le autorizzazioni delle identità o isolare il workload dopo aver rilevato attività sospette.

Questi controlli sono complementari, ma il loro posizionamento influenza latenza, copertura e modalità di errore. Un prodotto collocato al di fuori del percorso di esecuzione può osservare in modo più sicuro, pur non avendo l'autorità di blocco immediata.

Un controllo inline può fermare un'azione, ma diventa anche parte del percorso di disponibilità dell'applicazione. Gli acquirenti devono capire cosa accade quando il servizio di sicurezza rallenta, perde la connettività o non riesce a classificare una richiesta.

OX non ha fornito pubblicamente prove sufficienti e specifiche del lancio per risolvere questi confronti. La sua sfida immediata è trasformare un'architettura credibile in risultati ripetibili per i clienti.

La difesa runtime non può sostituire la progettazione degli agenti e il controllo degli accessi

Nessun CNAPP può compensare agenti che condividono identità, ricevono autorizzazioni eccessive o eseguono azioni ad alto impatto senza autorizzazione indipendente.

Il monitoraggio runtime riceve spesso attenzione perché può rilevare comportamenti che le revisioni statiche non colgono. Questo punto di forza può anche incoraggiare i team a trattare l'osservazione come un sostituto di un'architettura più sicura.

Un agente non dovrebbe ottenere un accesso ampio soltanto perché un prodotto di monitoraggio registra le sue azioni. Registrare un trasferimento di dati non autorizzato non annulla il trasferimento.

La tassonomia dei rischi agentici di OWASP include uso improprio degli strumenti, abuso di identità e privilegi, avvelenamento della memoria, guasti a cascata e comportamenti di agenti non autorizzati. Questi rischi attraversano i confini tra modelli, applicazioni, identità e infrastruttura.

I difensori dovrebbero iniziare con identità distinte per gli agenti. Le credenziali condivise oscurano la responsabilità e rendono difficile la revoca. Ogni agente di produzione necessita di un proprietario nominativo, uno scopo documentato e un insieme limitato di risorse consentite.

Anche l'accesso agli strumenti dovrebbe essere esplicito. Un agente progettato per riassumere i ticket di assistenza non dovrebbe ereditare l'accesso amministrativo alla piattaforma di ticketing. Dovrebbe ricevere soltanto le operazioni di lettura necessarie a tale attività.

L'accesso in scrittura merita una decisione separata. Se il workflow si espande fino a modificare record, il team dovrebbe creare nuove autorizzazioni e regole di approvazione anziché ampliare un ruolo esistente senza revisione.

Le azioni ad alto impatto richiedono un'applicazione deterministica. L'eliminazione di dati, la modifica dell'infrastruttura di produzione, l'emissione di pagamenti o la pubblicazione di contenuti esterni non dovrebbero dipendere soltanto dall'interpretazione, da parte di un modello, di istruzioni in linguaggio naturale.

L'approvazione umana resta appropriata per azioni con conseguenze finanziarie, operative o legali rilevanti. L'approvazione automatizzata può funzionare per attività a impatto minore quando le condizioni delle policy sono ristrette e applicate in modo indipendente.

La memoria introduce un altro rischio. Un agente può archiviare cronologia delle conversazioni, preferenze, fatti recuperati o piani intermedi tra sessioni. Contenuti malevoli possono persistere in quella memoria e influenzare decisioni successive.

Un prodotto runtime dovrebbe esporre, ove possibile, letture e scritture della memoria. Dovrebbe inoltre mostrare se un agente ha utilizzato contenuti recuperati nella selezione di uno strumento o nella costruzione dei parametri.

Tuttavia, l'accesso alla memoria può avvenire all'interno di un framework o di un servizio di modelli che fornisce telemetria limitata. Gli acquirenti dovrebbero verificare se OX Cloud acquisisce queste interazioni nel loro stack di deployment effettivo.

I falsi positivi rappresentano una sfida distinta. I workflow degli agenti producono naturalmente sequenze di azioni insolite perché si adattano alle richieste degli utenti. Un semplice rilevamento delle anomalie può segnalare variazioni legittime e sovraccaricare gli analisti.

OX afferma che la raggiungibilità aiuta a ridurre questo rumore. L'affermazione è plausibile, ma la raggiungibilità non prova l'intento malevolo. Un percorso raggiungibile può supportare un workflow legittimo, mentre un difetto software non raggiungibile può diventare rilevante dopo una modifica della configurazione.

Le aziende dovrebbero misurare la precisione durante un deployment controllato. Le metriche utili includono incidenti confermati, falsi positivi, tempo di indagine, attività legittime bloccate, workflow non supportati e lacune di telemetria.

Dovrebbero inoltre misurare l'impatto sulle prestazioni. L'ispezione runtime può aggiungere latenza quando valuta prompt, chiamate agli strumenti, flussi di dati o policy di identità in modo sincrono.

OX non ha pubblicato valori generali di latenza o overhead per OX Cloud. I risultati dipenderanno probabilmente dal metodo di deployment, dal volume di traffico, dalla complessità delle policy e dalla quantità di contesto raccolto.

Un'altra incertezza riguarda la coerenza dell'applicazione. Un'organizzazione può gestire agenti sviluppati con diversi framework, tra più cloud e piattaforme SaaS. Una policy deve resistere a queste differenze architetturali.

Una dashboard che rileva ogni agente ma ne governa solo un sottoinsieme crea una protezione disomogenea. I team di sicurezza hanno bisogno di una matrice di compatibilità chiara e di prove che i percorsi non supportati restino visibili.

La conclusione appropriata non è che la difesa runtime non abbia valore. È che il monitoraggio runtime funziona meglio come uno strato all'interno di un sistema di controllo più ampio.

La progettazione sicura degli agenti inizia con un'autorità limitata. La difesa runtime verifica quindi se il comportamento resta entro tali limiti e aiuta gli investigatori a comprendere le deviazioni.

Tre segnali mostreranno se OX Cloud mantiene le promesse

Il prossimo test consiste in prove operative, incluse la convalida da parte dei clienti, una riduzione misurabile del rumore e un'applicazione ampia su stack di agenti reali.

Il primo segnale è costituito da prove indipendenti fornite dai clienti. OX dovrebbe mostrare come la piattaforma opera in ambienti di produzione che contengono più cloud, framework per agenti, provider di identità e server MCP.

Casi di studio utili quantificherebbero quanti agenti e identità non umane sono stati rilevati. Dovrebbero inoltre riferire quali percorsi rischiosi sono stati confermati, quanti avvisi sono stati soppressi e come è cambiato il tempo di indagine.

Il secondo segnale è la prestazione comparativa. Gli acquirenti hanno bisogno di test di rilevamento e applicazione che coprano prompt injection, descrizioni di strumenti avvelenate, autorizzazioni eccessive, sequenze API insolite e tentativi di esfiltrazione dei dati.

Questi test dovrebbero includere variazioni benigne per misurare i falsi positivi. Un sistema che blocca ogni azione non comune offre scarso valore per workflow adattivi.

OX dovrebbe inoltre chiarire dove avviene l'applicazione. I clienti devono sapere se i controlli operano all'interno dei workload, tramite ispezione di rete, nei framework per agenti o attraverso API cloud.

Il terzo segnale è la risposta della concorrenza. Palo Alto Networks, Microsoft e altri fornitori di sicurezza stanno integrando identità degli agenti, postura, ispezione runtime e governance in piattaforme più ampie.

Se questi fornitori collegano codice, prompt, identità, risorse cloud e chiamate agli strumenti con una precisione simile, la distinzione architetturale di OX si ridurrà. OX competerà allora sulla qualità del deployment, sulla velocità delle indagini, sulla copertura e sul servizio clienti.

Se gli operatori storici manterranno questi controlli frammentati, OX potrà sostenere che un unico grafo contestuale produce decisioni più rapide e più difendibili. Le valutazioni dei clienti stabiliranno quale risultato rispecchi la realtà della produzione.

I responsabili della sicurezza che valutano la piattaforma CNAPP di OX Security dovrebbero iniziare con un workflow di agenti circoscritto. Possono mappare identità, strumenti approvati, dati raggiungibili, azioni previste e regole di escalation prima di abilitare una copertura più ampia.

La valutazione dovrebbe poi introdurre guasti controllati. È opportuno testare un server MCP esposto, un'identità con privilegi eccessivi, un documento avvelenato, una chiamata a uno strumento non autorizzata e un workload vulnerabile raggiungibile.

La piattaforma non dovrebbe soltanto mostrare che è accaduto qualcosa di insolito, ma anche perché fosse importante. Dovrebbe collegare l'istruzione originaria con l'identità agente, lo strumento selezionato, l'asset raggiungibile, la decisione della policy e l'esito finale.

Questo standard va oltre OX. I prodotti per la sicurezza degli agenti devono trasformare una telemetria complessa in un'applicazione affidabile e in indagini spiegabili.

Il lancio riflette un cambiamento reale nella sicurezza cloud. Gli agenti stanno diventando partecipanti attivi del cloud, anziché un'ulteriore categoria di asset da inventariare.

OX Cloud risponde integrando il comportamento in fase di esecuzione nello stesso grafo di codice, workload, identità e dati. L'impostazione è credibile, ma le affermazioni più forti richiedono ancora una convalida indipendente.

I team che valutano OX Cloud dovrebbero richiedere una prova vicina alle condizioni di produzione, non una dimostrazione rifinita delle funzionalità. La piattaforma riesce a identificare ogni agente, distinguere le variazioni legittime dagli abusi e ricostruire una catena d'azione completa? Può applicare limiti senza rallentare il lavoro ordinario o creare un'altra coda di avvisi? I risultati determineranno se la piattaforma CNAPP di OX Security diventerà un piano di controllo significativo o un ulteriore livello che i team di sicurezza dovranno riconciliare.