Sysdig Secure AI promette una difesa cloud più rapida, ma il controllo umano resta essenziale

Sysdig ha lanciato Secure AI il 4 agosto con tre modalità operative e la promessa di accelerare le indagini cloud senza eliminare la responsabilità umana. L’annuncio è arrivato su Google News mentre i team di sicurezza affrontavano una questione più difficile del sovraccarico di avvisi. Devono decidere quanta autorità operativa affidare agli agenti AI.

Secure AI combina agenti di sicurezza specializzati, integrazioni headless e l’assistente di AI generativa già esistente di Sysdig all’interno della sua piattaforma di protezione delle applicazioni cloud-native, o CNAPP. Sysdig afferma che il sistema può indagare su più di dieci volte il numero di casi, a un costo inferiore dell’88% rispetto a esperti umani che lavorano da soli.

Questi numeri rendono l’automazione allettante. Tuttavia, provengono dal modello di carico di lavoro di Sysdig, non da una valutazione comparativa condotta da un laboratorio indipendente.

Il conflitto più ampio non è quindi tra Sysdig e il lavoro di sicurezza manuale. È tra azione autonoma e controllo verificabile. Anche Google e Wiz, Palo Alto Networks e altri fornitori stanno assegnando agli agenti compiti di indagine e correzione.

I team di sicurezza non stanno più scegliendo se l’AI debba riassumere gli avvisi. Stanno decidendo quando il software possa indagare, modificare controlli, creare correzioni o contenere una minaccia in corso.

Cosa cambia davvero con Sysdig Secure AI

Secure AI trasforma diverse capacità Sysdig già esistenti in un modello operativo coordinato, in grado di passare dalle evidenze cloud a un’azione consigliata o automatizzata.

Sysdig ha annunciato l’offerta a Black Hat USA a Las Vegas. Secondo il lancio di Secure AI dell’azienda, è diventata generalmente disponibile il 4 agosto 2026.

Il prodotto si basa su Sysdig Secure, la CNAPP dell’azienda. Una CNAPP riunisce in un’unica piattaforma informazioni sulla postura cloud, sui workload, sulle identità, sulle vulnerabilità e sulla sicurezza runtime.

Secure AI non indica un chatbot né un singolo agente autonomo. Offre ai clienti tre modalità correlate per usare l’AI nella difesa cloud.

La prima modalità utilizza agenti AI di sicurezza specializzati. Questi agenti creano un elenco prioritario di rischi, esaminano le evidenze rilevanti e preparano mitigazioni o interventi correttivi.

La seconda modalità è la sicurezza cloud headless. In questo caso, Sysdig espone le proprie capacità tramite interfacce di programmazione delle applicazioni, strumenti da riga di comando, plugin e servizi Model Context Protocol.

Model Context Protocol, o MCP, è uno standard che consente alle applicazioni AI di collegarsi a strumenti e dati esterni. Questa interfaccia permette ad agenti di coding come Claude, Cursor o Codex di richiamare le capacità Sysdig nei flussi di lavoro esistenti.

La terza modalità è l’assistente di AI generativa integrato, precedentemente chiamato Sysdig Sage. I membri del team possono chiedergli di spiegare le rilevazioni, navigare la piattaforma e consigliare passaggi correttivi in linguaggio naturale.

Queste modalità si rivolgono a team con diversi livelli di esperienza nell’automazione. Un’organizzazione prudente può iniziare con spiegazioni e raccomandazioni. Un team maturo può collegare gli agenti ai flussi di indagine e correzione.

Sysdig afferma che le decisioni critiche mantengono la revisione umana, mentre il lavoro a rischio più basso o sensibile al tempo può procedere in autonomia. Afferma inoltre che ogni azione resta verificabile tramite audit.

Questa distinzione è importante perché la sicurezza cloud comprende classi di azioni molto diverse. Redigere un riepilogo di incidente comporta un rischio operativo limitato. Bloccare l’accesso, modificare autorizzazioni o applicare patch al software di produzione può interrompere l’attività.

Secure AI attinge anche alla telemetria runtime, che registra il comportamento mentre applicazioni e workload sono in esecuzione. Sysdig raccoglie gran parte di queste evidenze tramite osservazione a livello kernel e Falco, il suo motore open source di rilevamento runtime.

L’approccio collega vulnerabilità ad attività in tempo reale, esposizione, identità e configurazione cloud. Un agente può quindi chiedersi se un pacchetto vulnerabile sia in esecuzione e raggiungibile, anziché trattare allo stesso modo ogni risultato dello scanner.

Sysdig afferma che Falco ha superato i 200 milioni di download. Afferma inoltre che organizzazioni che rappresentano il 60% della Fortune 500 utilizzano Falco, anche se questo non significa che acquistino tutte prodotti Sysdig.

Il lancio riunisce questi componenti in un impegno di prodotto più chiaro. Sysdig sta vendendo l’AI come partecipante operativo, non solo come livello conversazionale sopra i dati di sicurezza.

Perché ora il titolo su Google News è importante

La visibilità su Google News riflette una più ampia transizione del mercato dall’analisi assistita dall’AI verso agenti che indagano e agiscono in ambienti cloud live.

I team di sicurezza usano da anni il machine learning per classificare i comportamenti, ridurre gli avvisi duplicati e identificare attività insolite. L’AI generativa ha inizialmente aggiunto la ricerca in linguaggio naturale e riepiloghi automatizzati.

I sistemi agentici fanno un ulteriore passo avanti. Possono scegliere strumenti, pianificare un’indagine, raccogliere evidenze e compiere azioni entro autorizzazioni definite.

Questa transizione avviene mentre sia l’infrastruttura sia gli attacchi diventano più automatizzati. Container di breve durata, identità macchina, deployment continuo e API cloud operano già più rapidamente della revisione manuale.

Sysdig sostiene che gli attaccanti possano attraversare ambienti cloud in pochi minuti. Il suo lancio cita un caso osservato dall’azienda in cui un agente AI ha raggiunto un database interno entro un’ora.

L’azienda fa riferimento anche a JADEPUFFER, che Sysdig descrive come la prima operazione ransomware documentata eseguita dall’inizio alla fine da un agente AI. Queste rilevazioni provengono dal team di ricerca sulle minacce di Sysdig e richiedono lo stesso scrutinio applicato ad altre ricerche dei fornitori.

La pressione resta credibile anche senza accettare ogni etichetta o dichiarazione sui tempi. Un attaccante può automatizzare ricognizione, uso di credenziali, movimento laterale e raccolta dati attraverso le stesse API gestite dai difensori.

Le vulnerabilità software diventano inoltre sfruttabili più rapidamente quando i modelli possono ispezionare il codice sorgente, generare casi di test e costruire potenziali exploit. Anthropic ha illustrato questa direzione attraverso Project Glasswing, un programma incentrato sull’uso di modelli avanzati per trovare e contribuire a correggere difetti software critici.

Questo modifica il carico di lavoro dei difensori cloud. Un’attività di probing più automatizzata genera più eventi, mentre attacchi più rapidi riducono il tempo disponibile per separare compromissioni reali da anomalie innocue.

Le assunzioni da sole non possono risolvere questo disallineamento temporale. Gli specialisti restano scarsi e aggiungere analisti non collega automaticamente evidenze frammentate tra infrastruttura, identità, endpoint, codice e applicazioni.

Uno studio ISSA e Omdia citato da Sysdig ha rilevato che l’83% delle organizzazioni intervistate stava adottando o pianificando di adottare l’AI per la cybersecurity. Lo studio sulla sicurezza dell’AI ha inoltre riportato che i professionisti trovavano il proprio lavoro sempre più difficile.

Questa combinazione spiega la tempistica del lancio. Gli acquirenti vogliono automazione, ma hanno anche bisogno di sistemi che riducano il lavoro di indagine anziché produrre un altro flusso di raccomandazioni.

Sysdig scommette che il contesto runtime crei il vantaggio necessario. Un modello fondato sul comportamento in tempo reale dovrebbe prendere decisioni migliori rispetto a uno che lavora solo su configurazioni statiche o elenchi di vulnerabilità.

Tuttavia, i dati runtime non eliminano l’incertezza. La telemetria può essere incompleta, le autorizzazioni possono essere configurate in modo errato e modifiche operative legittime possono assomigliare a comportamenti dannosi.

La domanda dietro il titolo di Google News non è quindi se gli agenti siano più rapidi. È se le loro evidenze, il ragionamento, le autorizzazioni e le azioni restino comprensibili sotto la pressione di un incidente.

Il contesto runtime è la principale scommessa competitiva di Sysdig

L’argomentazione centrale di Sysdig è che gli agenti di sicurezza diventano utili solo quando possono distinguere l’esposizione teorica dall’attività che avviene in un ambiente reale.

Gli scanner cloud producono spesso lunghi elenchi di vulnerabilità e debolezze di configurazione. Questi elenchi possono sovraccaricare i team perché la sola gravità tecnica non stabilisce il rischio aziendale immediato.

Un pacchetto vulnerabile in un workload di sviluppo isolato merita un trattamento diverso dallo stesso pacchetto in un sistema di produzione pubblico. Lo sfruttamento attivo cambia nuovamente la priorità.

La sicurezza dei workload AI di Sysdig correla esposizione pubblica, vulnerabilità, configurazioni errate, autorizzazioni ed eventi runtime. Il suo Cloud Attack Graph mappa poi le connessioni tra risorse interessate e possibili percorsi di attacco.

Secure AI usa questa base per guidare le indagini. Un agente può verificare se un pacchetto è attivo, identificare l’identità associata a un workload e rivedere comportamenti sospetti di processo o di rete.

Questo meccanismo può ridurre il lavoro di routine quando le evidenze sono affidabili. Può anche aiutare gli analisti a spiegare perché una rilevazione meriti un’azione immediata, mentre migliaia di rilevazioni simili possano attendere.

Sysdig presenta un’indagine su una vulnerabilità per dimostrare l’economia del modello. L’azienda stima un’indagine convenzionale come il lavoro di tre analisti per 45 minuti ciascuno, con un costo totale di circa $135.

Afferma che un analista che usa Secure AI può completare la stessa indagine in meno di 15 minuti per $16. Sysdig attribuisce circa $3.75 di tale importo ai token del modello.

Il calcolo produce l’affermazione dell’azienda di una capacità di indagine superiore di oltre dieci volte, a un costo inferiore dell’88%. È specifico, ma questa specificità non va scambiata per una prova indipendente.

Il risultato dipende dalla retribuzione degli analisti, dalla complessità dei casi, dalle integrazioni, dal consumo di token e dallo standard qualitativo usato per definire un’indagine completata. Ambienti diversi produrranno risultati diversi.

Una vulnerabilità nota con chiare evidenze runtime può adattarsi bene al modello. Una nuova compromissione di identità che coinvolga più provider cloud può richiedere molta più interpretazione umana.

Il calcolo esclude anche il lavoro di implementazione. I team devono configurare gli accessi, definire i confini delle approvazioni, collegare sistemi di ticketing e comunicazione, ottimizzare le policy e testare la gestione dei guasti.

La revisione degli audit aggiunge un altro costo. Un’organizzazione non risparmia tempo in modo significativo se gli analisti devono ricostruire ogni decisione automatizzata dopo che l’agente modifica i controlli di produzione.

Ciononostante, Sysdig ha identificato la corretta unità di valore. I responsabili della sicurezza non hanno bisogno di un’altra misura della velocità con cui un modello genera testo. Hanno bisogno di indagini completate che soddisfino una soglia di accuratezza difendibile.

L’evidenza più utile confronterebbe indagini assistite da agenti e indagini convenzionali sullo stesso insieme di casi. I valutatori dovrebbero misurare tempo di completamento, conclusioni errate, evidenze mancate, azioni non sicure e correzioni umane richieste.

Sysdig non ha pubblicato con l’annuncio questo tipo di benchmark controllato. Finché non lo farà, il dato sull’efficienza resterà un’affermazione dell’azienda basata su uno scenario descritto.

Questo non rende irrilevante l’affermazione. Offre agli acquirenti un’ipotesi concreta da testare durante la valutazione.

Wiz e Google aumentano la pressione sulla strategia agentica di Sysdig

Sysdig entra in una competizione attiva su quale fondamento di dati di sicurezza offra agli agenti autonomi il percorso più chiaro e sicuro dal rilevamento alla correzione.

Wiz ha introdotto gli agenti Red, Blue e Green nel marzo 2026. Ogni agente gestisce una parte diversa del ciclo di vita della sicurezza.

Il Red Agent cerca debolezze sfruttabili. Il Blue Agent indaga sulle minacce usando il contesto cloud, dell'identità e del runtime. Il Green Agent analizza i problemi ad alta priorità e prepara o esegue la correzione.

Wiz consente inoltre ai team di creare workflow che combinano questi agenti con passaggi di approvazione e strumenti di collaborazione. I suoi agent workflows possono indirizzare le azioni a bassa confidenza verso le persone, automatizzando al contempo le correzioni con maggiore confidenza.

Google Cloud ha intensificato la pressione competitiva durante la conferenza di aprile. Il suo portafoglio di sicurezza ha aggiunto agenti per la threat hunting, il detection engineering e il contesto di terze parti.

Google ha inoltre posizionato Wiz all'interno di una piattaforma più ampia che include threat intelligence Mandiant, Google Security Operations, servizi di identità e infrastruttura AI. La strategia di difesa agentica dell'azienda copre i workload cloud e le operazioni di sicurezza.

Palo Alto Networks persegue un percorso simile tra rete, cloud, operazioni di sicurezza e protezione AI. Prisma AIRS si concentra più direttamente sulla protezione di applicazioni e agenti AI, mentre il suo portafoglio più ampio fornisce il contesto operativo di sicurezza.

Questi fornitori differiscono nell'architettura, ma condividono un'affermazione. Dati contestuali migliori dovrebbero consentire a un agente di prendere decisioni più rapide e accurate rispetto a un modello generico collegato a strumenti dispersi.

Sysdig punta sulla telemetria runtime e su Falco. Wiz punta sul proprio security graph e sul contesto dal codice al cloud. Google punta su threat intelligence, scala dell'infrastruttura e una piattaforma di sicurezza in espansione.

La sfida non dipende dal fornitore che riesce a presentare il maggior numero di agenti. Gli agenti con un nome sono packaging. Gli acquirenti devono esaminare le prove a cui questi agenti accedono e l'autorità che ricevono.

Un agente specializzato può comunque arrivare alla conclusione sbagliata. Separare i compiti tra indagine, validazione e correzione può creare controlli utili, ma solo se gli agenti mettono in discussione le reciproche ipotesi.

Altrimenti, il coordinamento multi-agente può ripetere lo stesso errore in diversi passaggi automatizzati. Una conclusione errata di un agente investigativo può trasformarsi in una correzione generata con sicurezza.

La concorrenza esercita inoltre pressione sull'approccio headless di Sysdig. Gestire la sicurezza tramite agenti di coding offre flessibilità, ma assegna all'ambiente agente circostante un ruolo significativo nella catena di fiducia.

I team di sicurezza devono ispezionare il modello, il server MCP, i permessi degli strumenti, le credenziali, il contesto conversazionale e le integrazioni esterne. Una debolezza a qualsiasi livello può influenzare l'azione finale.

Il vantaggio di Sysdig è più evidente negli ambienti containerizzati e cloud-native, dove le prove runtime aggiungono un contesto sostanziale. Il vantaggio diventa meno certo quando un incidente coinvolge email, endpoint, applicazioni aziendali e sistemi di identità al di fuori della sua telemetria più solida.

I grandi concorrenti possono rispondere a questo limite attraverso piattaforme più ampie. Sysdig può rispondere mantenendo aperte le proprie interfacce e integrandosi con i sistemi che i clienti già utilizzano.

Ecco perché Secure AI è più di un annuncio di funzionalità. È il tentativo di Sysdig di rendere i dati runtime il livello di controllo per una difesa cloud autonoma.

La difesa cloud autonoma crea un nuovo problema di controllo

Gli stessi permessi che consentono a un agente di fermare un attacco possono anche amplificare una decisione errata, un'istruzione compromessa o una correzione eccessiva.

La revisione umana compare in tutto il messaggio di prodotto di Sysdig. L'azienda afferma che le persone definiscono gli obiettivi, che le decisioni critiche mantengono il coinvolgimento umano e che le azioni degli agenti restano verificabili.

Queste salvaguardie sembrano appropriate, ma la loro implementazione ne determina il valore. “Human in the loop” può descrivere qualsiasi cosa, da un'approvazione significativa a una notifica che arriva dopo un'azione.

L'approvazione diventa inoltre difficile quando la velocità è la principale promessa del prodotto. Un difensore non può esaminare con attenzione ogni passaggio aspettandosi al tempo stesso un contenimento alla velocità delle macchine.

I team hanno quindi bisogno di un'autorità graduata. Un agente potrebbe raccogliere liberamente le prove, aprire automaticamente un ticket, isolare un workload di sviluppo previa approvazione e non modificare mai da solo le policy di identità in produzione.

Il confine accettabile dipende dalla reversibilità e dal potenziale impatto. Terminare un singolo processo sospetto è diverso dal revocare un ruolo condiviso usato da diversi servizi dei clienti.

La prompt injection crea un'altra preoccupazione. Un agente può incontrare istruzioni dannose nel codice sorgente, nei log, nei ticket, nelle pagine web o in altri dati che legge durante un'indagine.

Se l'agente tratta contenuti non attendibili come indicazioni operative, un attaccante può influenzare l'indagine. L'accesso agli strumenti trasforma quindi un errore del modello in un'azione di sicurezza.

Anche la progettazione delle credenziali diventa altrettanto importante. Gli agenti dovrebbero ricevere l'autorità minima necessaria per ogni compito, usare credenziali a breve durata e operare tramite interfacce monitorate.

Credenziali di amministratore a lunga durata comprometterebbero il vantaggio di una progettazione dell'agente altrimenti accurata. La compromissione dell'agente o del suo contesto potrebbe quindi esporre l'intero ambiente.

Il settore riconosce già questi rischi. I rischi agentici OWASP includono il dirottamento degli obiettivi, l'uso improprio degli strumenti, l'abuso dell'identità, l'autonomia eccessiva e i guasti a cascata.

La traccia di audit di Secure AI può contribuire alla responsabilità, ma i log da soli non prevengono comportamenti non sicuri. I team hanno bisogno di policy che blocchino le azioni vietate prima dell'esecuzione.

Hanno inoltre bisogno di controlli indipendenti, esterni al processo di ragionamento dell'agente. Alcuni esempi includono confini di autorizzazione, finestre di modifica, protezioni delle risorse, limiti alle transazioni e requisiti di approvazione.

Un sistema affidabile dovrebbe conservare le prove alla base di ogni conclusione. Gli analisti devono poter vedere quali segnali l'agente ha consultato, quali alternative ha scartato e perché ha scelto un'azione.

Le spiegazioni in linguaggio naturale non sono sufficienti. I modelli possono creare riepiloghi persuasivi che non rappresentano fedelmente il loro processo interno o l'intero insieme di prove.

Gli acquirenti dovrebbero anche testare la gestione dell'incertezza. Un agente che ammette prove insufficienti e richiede una revisione può essere più sicuro di uno ottimizzato per chiudere ogni indagine.

I falsi positivi creano costi operativi, ma i falsi negativi comportano conseguenze di sicurezza più gravi. Un benchmark deve quindi separare la velocità dalla qualità delle decisioni.

L'esempio di costo dell'azienda non pubblica tassi di errore o di correzione. Non mostra nemmeno come il sistema si comporti quando la telemetria è assente, contraddittoria o deliberatamente manipolata.

Queste lacune non squalificano Secure AI. Definiscono il lavoro di valutazione necessario prima che le azioni autonome raggiungano la produzione.

Cosa dovrebbero testare i team di sicurezza prima di ampliare l'autonomia

La prossima fase sarà decisa dalla qualità misurata delle indagini, da azioni sicure in produzione e da prove che le prestazioni degli agenti migliorino al di fuori delle dimostrazioni dei fornitori.

Il primo segnale da osservare è una valutazione indipendente o riproducibile dai clienti. I team dovrebbero eseguire Secure AI e gli analisti convenzionali sugli stessi incidenti storici.

Ogni test dovrebbe monitorare il tempo d'indagine, la copertura delle prove, gli indicatori mancati, le conclusioni errate, le azioni consigliate e le correzioni umane. I confronti dei costi dovrebbero includere il lavoro di integrazione e revisione.

Queste prove rafforzerebbero il caso di Sysdig se i team riproducessero i guadagni di capacità dichiarati senza aumentare gli errori. Correzioni frequenti indebolirebbero l'argomento economico, anche se l'agente conclude rapidamente.

Il secondo segnale è l'uso in produzione della correzione autonoma. I case study dovrebbero spiegare quali azioni vengono eseguite automaticamente, quali richiedono approvazione e come le organizzazioni gestiscono il rollback.

Un case study utile includerebbe il comportamento in caso di errore, non soltanto la velocità media. Gli acquirenti devono sapere cosa accade quando un agente riceve telemetria incompleta o istruzioni in conflitto.

Gli attuali commenti dei clienti su Secure AI sostengono la direzione, ma restano testimonianze selezionate per un lancio di prodotto. Non sostituiscono prove controllate.

Il terzo segnale è la risposta dei concorrenti e l'interoperabilità. Google e Wiz offrono già agenti specifici per attività, mentre Palo Alto Networks collega la protezione AI a un'ampia piattaforma di sicurezza.

Sysdig deve dimostrare che il suo vantaggio runtime resta utile quando i clienti utilizzano diversi fornitori di sicurezza. Le interfacce headless possono aiutare, a condizione che permessi e scambio dati restino gestibili.

I clienti dovrebbero inoltre osservare con quale frequenza Sysdig aggiunge skill scritte da esperti. Le nuove skill possono ampliare la copertura, ma ogni funzionalità aggiunge un altro workflow che richiede test e governance.

Il ciclo di notizie di Google News passerà rapidamente oltre. L'adozione del prodotto, i benchmark controllati e gli errori resi noti riveleranno molto più del titolo di lancio.

Per gli acquirenti che valutano Secure AI, un'implementazione graduale è l'approccio più sensato. Iniziate con indagini in sola lettura, confrontate le conclusioni con quelle di analisti esperti e annotate i punti in cui l'agente perde contesto.

Successivamente, consentite azioni reversibili in ambienti limitati. Richiedete un'approvazione esplicita per le modifiche in produzione finché il team non abbia misurato l'accuratezza su un numero sufficiente di incidenti reali.

Infine, definite l'autonomia per tipo di azione, non tramite un'impostazione generale di confidenza. Raccolta delle prove, creazione di ticket, isolamento dei processi, modifiche ai permessi e distribuzione del codice comportano rischi diversi.

I responsabili della sicurezza dovrebbero porsi un'ultima domanda prima di aumentare l'accesso: il team può ricostruire, contestare e annullare ogni decisione importante presa dall'agente?

Sysdig ha presentato un caso credibile secondo cui le prove runtime possono aiutare gli agenti AI a dare priorità al rischio cloud reale. Non ha ancora dimostrato che un'ampia autonomia superi costantemente un attento controllo umano.

Questa prova richiederà più di un'altra apparizione su Google News. Richiederà risultati trasparenti provenienti da ambienti complessi, dove le prove sono in conflitto, i sistemi di produzione resistono al cambiamento e gli errori hanno conseguenze misurabili.