Previsioni sulla sicurezza AI della Cloud Security Alliance: il SOC autonomo incontra il problema della fiducia

Le previsioni sulla sicurezza AI della Cloud Security Alliance indicano che la cybersecurity potrebbe diventare pressoché irriconoscibile nell'arco di circa due anni, nonostante seri limiti al processo decisionale autonomo. La previsione arriva da Jim Reavis, CEO e cofondatore dell'alleanza, in un'analisi di CSO pubblicata il 16 settembre 2026.

Il cambiamento è già iniziato nei centri operativi di sicurezza. Gli agenti AI possono raccogliere prove, arricchire gli avvisi e condurre il triage iniziale tra sistemi che un tempo richiedevano ricerche umane separate. Il conflitto nasce quando questi agenti devono decidere se ignorare un evento, contenere un dispositivo o modificare i controlli di produzione.

Gli sviluppatori software hanno accettato rapidamente l'assistenza AI perché la maggior parte del lavoro generato continuava a passare attraverso pipeline di test, revisione e deployment. I team di sicurezza affrontano uno standard più severo. Un errore di codifica può spesso essere individuato prima del rilascio, mentre un'azione di contenimento errata può interrompere un'attività aziendale in pochi secondi.

Questa differenza definisce la prossima fase della cybersecurity agentica. L'AI può aumentare la velocità difensiva, ma la stessa autonomia amplia anche le conseguenze di un'istruzione errata, di un'identità compromessa o di un risultato fuorviante. Il modello vincente non rimuoverà le persone dalla sicurezza. Sposterà il giudizio umano al di sopra di uno strato operativo più rapido e strettamente governato.

Il SOC autonomo sta già iniziando ad arrivare

Il SOC autonomo sta emergendo attraverso attività delegate, non tramite l'improvvisa sostituzione di un intero team di sicurezza.

Un centro operativo di sicurezza, o SOC, monitora i sistemi, indaga sulle attività sospette e coordina la risposta agli incidenti. Gran parte del lavoro iniziale consiste nel raccogliere contesto da più strumenti prima che un analista possa stabilire se un avviso sia rilevante.

David Lindner, CISO di Contrast Security, ha descritto a CSO una prima versione di questo flusso di lavoro. Un incidente arrivava tramite Jira, dopodiché un agente raccoglieva informazioni da GitHub e Datadog e produceva un triage iniziale. Lindner ha caratterizzato il sistema come capace di svolgere il lavoro di un analista SOC, anziché limitarsi ad assisterne uno.

Questo esempio è importante perché unisce vari passaggi precedentemente separati. L'agente riceve un caso, decide quali sistemi contengono prove pertinenti, recupera tali prove e prepara una valutazione. Trasforma una coda di ricerche manuali in un'unica azione coordinata.

Lo stesso schema sta comparendo nelle piattaforme di sicurezza più grandi. Google Cloud ha dichiarato che il suo agente Triage and Investigation ha elaborato oltre 5 milioni di avvisi in un anno. L'azienda riferisce che Gemini ha ridotto una tipica analisi manuale di 30 minuti a 60 secondi. Si tratta di risultati riportati dall'azienda, ma mostrano il flusso di lavoro che i fornitori cercano di standardizzare.

Google ha inoltre introdotto agenti per il threat hunting, il detection engineering e il contesto di terze parti. La sua strategia di difesa agentica collega queste funzioni con dati delle operazioni di sicurezza e azioni di risposta automatizzate.

Questo è più significativo dell'aggiunta di un chatbot a una dashboard. Un chatbot risponde a domande quando gli vengono poste. Un agente può pianificare una sequenza, richiamare strumenti connessi, valutare risultati intermedi e proseguire fino al raggiungimento di un obiettivo definito.

La distinzione crea anche rischi. Ogni connessione concede all'agente una combinazione di visibilità e autorità. L'accesso a ticket e telemetria supporta le indagini, mentre l'accesso a identità, endpoint, controlli cloud o firewall può supportare il contenimento.

Le organizzazioni stanno quindi separando la raccolta del contesto dal giudizio finale. Lionel Litty, CISO di Menlo Security, ha detto a CSO che gli agenti aiutano già il suo team a dare priorità agli eventi e a fornire contesto. La sua organizzazione non si sente a proprio agio nel lasciare che decidano autonomamente quali eventi gli analisti debbano ignorare.

Questa esitazione non invalida il SOC autonomo. Rivela come probabilmente si articolerà l'adozione. Le aziende automatizzeranno prima la raccolta ripetitiva delle prove, poi il triage circoscritto e infine le azioni di risposta reversibili. Le decisioni ad alto impatto resteranno soggette ad approvazione finché i team non riusciranno a misurare l'affidabilità in condizioni operative reali.

Le previsioni sulla sicurezza AI della Cloud Security Alliance sono già visibili in questo graduale trasferimento di lavoro. La domanda importante non è più se gli agenti entreranno nel SOC. È quali decisioni si guadagneranno il diritto di prendere.

La trasformazione della cybersecurity AI mette sotto pressione il modello di triage umano

I risultati generati dalle macchine crescono più rapidamente di quanto i team umani possano convalidarli e risolverli.

L'AI ha già cambiato il lato produttivo della tecnologia. Uno studio del 2025 ha combinato esperimenti sul campo randomizzati che hanno coinvolto 4.867 sviluppatori presso Microsoft, Accenture e un'altra grande azienda. Gli sviluppatori dotati di un assistente di coding AI hanno completato il 26,08% di attività in più, secondo lo studio sulla produttività degli sviluppatori.

La sicurezza non ha ricevuto un aumento equivalente della capacità di revisione. Uno sviluppo più veloce crea più codice, più dipendenze e più modifiche da esaminare per i team di sicurezza applicativa. Gli strumenti AI per le vulnerabilità producono quindi ulteriori risultati su questa base software in espansione.

Individuare più difetti sembra un vantaggio inequivocabile. In pratica, un flusso non classificato di debolezze può sopraffare le persone incaricate di risolverle. Una vulnerabilità diventa intelligence difensiva utile solo quando l'organizzazione riesce a stabilirne rilevanza, titolarità, sfruttabilità e percorso di remediation.

Reavis ha descritto tutto questo come un problema di assorbimento. I team devono capire come elaborare, prioritizzare e risolvere le informazioni prodotte dai sistemi automatizzati. Litty l'ha paragonato ai precedenti programmi di analisi statica che generavano centinaia di risultati, molti dei quali gli ingegneri finivano per ignorare.

Il collo di bottiglia è importante perché la scoperta autonoma e la remediation autonoma non hanno lo stesso grado di maturità. Caleb Sima, presidente della Cloud Security Alliance AI Safety Initiative, ha detto a CSO che la scoperta delle vulnerabilità nel codice sorgente è già molto sviluppata. I test autonomi all'interno di complesse reti di produzione aziendali devono ancora fare molta strada.

Il codice sorgente presenta un obiettivo relativamente circoscritto. Un ambiente reale include stato di runtime, relazioni di identità, controlli compensativi, servizi proprietari, dipendenze aziendali e inventari degli asset incompleti. Un risultato che appare grave isolatamente può avere una portata limitata, mentre un normale errore di configurazione può esporre un percorso critico.

Questo crea pressione su due gruppi. Gli analisti SOC devono valutare più avvisi e i team di ingegneria devono assorbire più richieste di remediation. Nessuno dei due gruppi trae beneficio quando un sistema AI si limita a spostare una pila più grande di lavoro non verificato oltre il confine organizzativo.

La questione diventa più urgente man mano che l'AI genera una quota maggiore del software. Un sondaggio riportato su 2.350 CISO, responsabili della sicurezza applicativa e sviluppatori ha rilevato che quasi metà del codice di produzione era generato dall'AI. La stessa ricerca sosteneva che le organizzazioni che utilizzavano l'AI per dall'81% al 100% del loro codice distribuivano codice vulnerabile 3,4 volte più spesso rispetto agli adottanti prudenti.

Questi risultati del sondaggio si basano sulle dichiarazioni dei partecipanti e non dovrebbero essere trattati come una misurazione universale. Illustrano comunque il disallineamento operativo. La produzione software può accelerare immediatamente, mentre capacità di revisione, governance e titolarità della remediation cambiano più lentamente.

La cybersecurity agentica deve colmare questo divario invece di aggiungere un ulteriore livello di rilevamento. I sistemi utili sopprimeranno i risultati irrilevanti, mapperanno i rischi sugli asset raggiungibili, proporranno correzioni, le testeranno e conserveranno prove per la revisione umana. Il volume grezzo delle scoperte è una misura inadeguata dei progressi nella sicurezza.

È anche qui che la conoscenza organizzativa diventa infrastruttura operativa. Per giudicare correttamente un risultato, un agente necessita di decisioni architetturali aggiornate, cronologia degli incidenti, registri di titolarità ed eccezioni. I team di ingegneria che mantengono una base di conoscenza ricercabile offrono a persone e agenti un contesto migliore per questo giudizio.

Le organizzazioni sotto pressione non sono soltanto i fornitori di sicurezza. I CISO devono riprogettare i flussi di lavoro, i responsabili dell'ingegneria devono accettare cicli di remediation più rapidi e i proprietari delle piattaforme devono esporre i controlli in sicurezza. Il vecchio modello di triage umano non può continuare a espandersi un analista alla volta.

La sicurezza AI della Cloud Security Alliance affronta un test di riproducibilità

La cybersecurity non può copiare lo sviluppo software AI perché i controlli difensivi richiedono comportamenti ripetibili in condizioni avversarie.

Lo sviluppo assistito dall'AI tollera un certo grado di variazione. Uno sviluppatore può richiedere diverse implementazioni, scartare risultati deboli, eseguire test e rivedere il risultato prima che gli utenti lo incontrino. La prima risposta del modello non deve necessariamente diventare la risposta di produzione.

Le azioni di sicurezza spesso operano sotto vincoli diversi. Un rilevamento deve identificare lo stesso comportamento pericoloso in modo coerente. Un sistema di contenimento deve isolare il bersaglio previsto senza disabilitare servizi non correlati. Un'indagine deve preservare le prove e spiegare come sia giunta alla propria conclusione.

Lindner ha riassunto la differenza con un requisito: la sicurezza necessita di riproducibilità. Se le stesse prove portano un agente verso decisioni sostanzialmente diverse, un CISO non può affidargli con sicurezza l'autorità sui sistemi di produzione.

La riproducibilità non richiede formulazioni identiche in ogni report. Richiede risultati stabili sulle decisioni che contano. La stessa sequenza malevola dovrebbe produrre gravità, portata e raccomandazioni di risposta compatibili quando i fatti circostanti rimangono invariati.

Questo standard diventa difficile quando un agente utilizza modelli probabilistici, dati esterni in evoluzione e più strumenti connessi. Un aggiornamento del modello può modificare il ragionamento. Un errore di recupero può omettere un contesto decisivo. Una risposta di uno strumento compromesso può manipolare il piano stesso.

I team di sicurezza devono quindi valutare l'intero sistema agentico, non solo il modello linguistico. Il sistema include prompt, memoria, identità, connettori, regole di approvazione, log, comportamento di fallback e ogni controllo che l'agente può modificare.

Il software che circonda un agente AI viene talvolta chiamato harness. L'harness determina ciò che il modello può osservare, quali strumenti può chiamare e cosa avviene dopo che sceglie un'azione. Un modello potente all'interno di un harness debole rimane un operatore pericoloso.

Questo sposta i test oltre la sola accuratezza conversazionale. I team necessitano di valutazioni basate su scenari che esaminino contenimenti errati, escalation mancate, prompt injection, contesto corrotto, uso improprio dei privilegi e recupero dopo un fallimento parziale. Devono inoltre ripetere questi scenari quando cambiano modelli, prompt o integrazioni.

La governance non può restare un documento rivisto una volta all'anno. Ogni agente necessita di un proprietario, uno scopo definito, un elenco dei sistemi accessibili e un confine di autorità esplicito. Le sue azioni necessitano di timestamp, prove alla fonte e di un percorso di ricostruzione.

Il panorama degli standard emergenti riflette questa necessità. L’OWASP GenAI Security Project mappa gli strumenti lungo il ciclo di vita degli agenti e nell’intersezione tra sviluppo e operazioni di sicurezza. Il suo panorama della sicurezza considera la protezione degli agenti come un insieme di responsabilità, anziché come un’unica categoria di prodotto.

Questo è il compromesso centrale nelle previsioni sulla sicurezza dell’AI della Cloud Security Alliance. I difensori hanno bisogno di autonomia perché gli attacchi e le modifiche al software stanno accelerando. Eppure, ogni ulteriore autorizzazione autonoma aumenta il potenziale impatto di una decisione errata o manipolata.

Una progettazione pratica parte da ruoli circoscritti. Un agente può arricchire un avviso senza modificare l’infrastruttura. Un altro può redigere una regola di rilevamento, ma richiedere una convalida prima della distribuzione. Un agente di contenimento può operare solo su classi di asset preapprovate e usare azioni che i team possono annullare rapidamente.

Anche la supervisione umana necessita di una definizione precisa. Richiedere a una persona di approvare centinaia di decisioni delle macchine crea un controllo formale, non un controllo efficace. La persona deve ricevere le prove, il livello di confidenza, gli asset interessati, l’azione proposta e il probabile impatto aziendale in una forma che possa valutare.

Nel tempo, i sistemi possono guadagnarsi un’autorità più ampia grazie alle prestazioni osservate. I team possono confrontare le raccomandazioni con le decisioni degli analisti, misurare i falsi positivi, condurre esercitazioni controllate ed estendere le autorizzazioni solo quando le prove giustificano tale scelta.

Il SOC autonomo del futuro assomiglierà quindi a una gerarchia di autorità delegata. Gli agenti gestiranno decisioni frequenti e circoscritte alla velocità delle macchine. Professionisti esperti definiranno le policy, esamineranno le eccezioni e si assumeranno la responsabilità del comportamento del sistema.

Gli attacchi alla velocità delle macchine cambiano il costo dell’attesa

L’argomento a favore della difesa automatizzata diventa più forte quando un attaccante può muoversi più rapidamente di qualsiasi catena di approvazione umana.

La risposta tradizionale agli incidenti presuppone spesso che i difensori abbiano tempo per indagare tra le varie fasi di un’intrusione. Gli analisti correlano gli avvisi, contattano i proprietari dei sistemi, confermano l’impatto e poi autorizzano il contenimento. Quel processo diventa fragile quando gli attaccanti automatizzati possono effettuare ricognizione e sfruttamento quasi immediatamente.

Sima ha descritto uno scenario in cui un agente ostile entra in un ambiente e crea altri 200 agenti. Questi cercano vulnerabilità, individuano asset di valore e sottraggono dati prima che un team convenzionale possa rispondere.

Il numero è uno scenario proposto da un esperto, non una previsione documentata di ogni attacco. Il meccanismo sottostante è credibile. Il software può duplicare i compiti, eseguirli in parallelo e coordinare i risultati molto più velocemente di quanto una persona possa navigare tra più console di sicurezza.

Google Cloud ha riportato un’altra misura della riduzione dei tempi di risposta. Il suo materiale M-Trends 2026 affermava che il passaggio dall’accesso iniziale a un attore di minaccia secondario è sceso da otto ore a 22 secondi nell’arco di tre anni. Questa cifra riguarda il coordinamento tra attaccanti piuttosto che sciami autonomi, ma mostra perché una difesa ritardata sta diventando insostenibile.

La cybersecurity agentica risponde avvicinando azioni selezionate al rilevamento. Un endpoint può isolarsi, un sistema di identità può sospendere un token oppure un controllo cloud può limitare un workload prima che una persona completi l’indagine più ampia.

La difficoltà consiste nell’evitare che il contenimento automatizzato diventi un’ulteriore fonte di interruzione. Un attaccante che manipola l’automazione difensiva potrebbe causare un denial of service senza violare l’applicazione protetta. Un falso segnale potrebbe isolare un servizio critico nel momento peggiore possibile.

Sima ha sostenuto che i sistemi cloud, le applicazioni e gli endpoint dovrebbero adeguare i controlli alla velocità delle macchine senza compromettere la produzione. Quest’ultima condizione comporta gran parte dell’onere ingegneristico. L’azione rapida aiuta solo quando il sistema di risposta comprende le dipendenze e offre un percorso di ripristino sicuro.

L’architettura di sicurezza tradizionale resta rilevante in questo contesto. Il privilegio minimo limita ciò che un’identità compromessa può raggiungere. La separazione dei compiti impedisce a un singolo componente di controllare ogni fase. La difesa in profondità evita che il fallimento di una protezione esponga un’intera azienda.

Litty ha sottolineato questi principi fondamentali nel rapporto di CSO. Le organizzazioni dovrebbero presumere che un componente possa essere violato e progettare l’ambiente per limitare i danni conseguenti. L’AI non elimina questa responsabilità. Rende più facile attraversare confini deboli su larga scala.

L’automazione cambia anche la preparazione agli incidenti. I team hanno bisogno di opzioni di contenimento predefinite prima che inizi un attacco. Devono sapere quali workload possono essere messi in quarantena, quali connessioni possono essere bloccate e quali processi aziendali richiedono una decisione umana.

Una buona automazione della risposta dovrebbe essere graduale. Segnali a bassa confidenza potrebbero attivare registrazioni aggiuntive. Prove più solide potrebbero limitare un token o segmentare un host. Solo le condizioni più affidabili dovrebbero autorizzare azioni con un ampio impatto operativo.

Ogni azione automatizzata dovrebbe rimanere osservabile. Gli analisti devono poter vedere quali prove l’hanno attivata, quale policy l’ha consentita e cosa ha modificato l’agente. Se l’azione fallisce, il sistema necessita di un chiaro percorso di escalation anziché di ripetuti esperimenti autonomi.

La sfida fondamentale non è più tra esseri umani e macchine. È tra automazione governata e automazione non governata. Gli attaccanti beneficiano della velocità senza responsabilità, mentre i difensori devono combinare velocità con sicurezza, continuità e prove.

Questa asimmetria spiega perché la transizione sarà più lenta dell’adozione dell’AI per la programmazione. Uno sviluppatore può scartare un suggerimento errato. Un CISO deve pianificare la possibilità che un’azione difensiva errata diventi di per sé un incidente.

I team di sicurezza ricchi di agenti premieranno il giudizio

È probabile che l’AI comprima il coordinamento di routine, aumentando al contempo il valore dell’esperienza, della progettazione dei sistemi e della responsabilità.

Lo sviluppo software offre una prima visione del cambiamento organizzativo. Gartner prevede che entro il 2030 l’80% delle organizzazioni trasformerà grandi gruppi di ingegneria del software in team più piccoli potenziati dall’AI. La previsione include più specialisti senior, strutture manageriali più ampie e nuovi ruoli focalizzati su governance e contesto.

La cybersecurity potrebbe seguire una direzione simile senza produrre un esito occupazionale identico. L’indagine di primo livello è più facile da delegare perché spesso segue schemi ripetibili di raccolta delle prove. Gli incidenti complessi richiedono ancora conoscenza dell’architettura, delle priorità aziendali, del comportamento degli attaccanti e della storia organizzativa.

Reavis prevede che le organizzazioni di sicurezza diventeranno più piatte, con professionisti senior che torneranno a svolgere attività operative di costruzione. Sima ha descritto una forza lavoro a forma di bilanciere, con contributor individuali esperti a un’estremità e lavoratori junior nativi dell’AI all’altra. In quel modello, i ruoli intermedi ad alta intensità di coordinamento subiscono la pressione maggiore.

Queste previsioni restano valutazioni informate, non dati occupazionali consolidati. Le aziende differiscono notevolmente per maturità della sicurezza, obblighi normativi e capacità di connettere gli agenti ai sistemi interni. L’adozione dipenderà anche dalla capacità dei fornitori di dimostrare risultati affidabili al di fuori di esempi controllati.

Tuttavia, il cambiamento a livello di attività è più facile da osservare. Gli analisti che trascorrono ore a spostare informazioni tra sistemi di ticketing, telemetria e threat intelligence svolgeranno meno raccolta manuale. Dedicheranno più tempo a definire percorsi investigativi, rivedere eccezioni e migliorare l’automazione stessa.

I ruoli junior non scompariranno semplicemente, ma il loro percorso di apprendimento cambierà. Gli analisti tradizionali spesso acquisivano esperienza elaborando grandi code di avvisi. Se gli agenti svolgeranno quel lavoro, le organizzazioni dovranno creare modalità deliberate per insegnare investigazione, gestione delle prove e giudizio sugli incidenti.

Ciò crea un potenziale problema di competenze. Gli esperti senior hanno sviluppato l’intuito attraverso l’esposizione ripetuta a casi ordinari prima di affrontare quelli insoliti. Un’azienda non può presumere che i nuovi lavoratori acquisiscano lo stesso giudizio semplicemente supervisionando l’output delle macchine.

La formazione dovrebbe includere simulazioni, esercitazioni avversariali e revisioni sia delle decisioni degli agenti riuscite sia di quelle fallite. I professionisti junior hanno bisogno di opportunità per mettere in discussione il sistema, non solo per accettarne le raccomandazioni. Altrimenti, l’automazione può nascondere le debolezze finché un incidente raro non le rivela.

Anche i professionisti senior dovranno sviluppare nuove competenze. Dovranno tradurre le policy di sicurezza in vincoli applicabili dalle macchine, valutare sistemi probabilistici e comprendere come l’identità degli agenti modifichi la progettazione degli accessi. L’esperienza resta preziosa, ma solo se accompagnata da un coinvolgimento tecnico attivo.

I fornitori affrontano una propria pressione di ristrutturazione. I prodotti di sicurezza hanno accumulato interfacce specializzate, modelli di dati proprietari e avvisi sovrapposti. Gli agenti possono diventare un livello di controllo condiviso che interroga e coordina tali sistemi attraverso linguaggio naturale e azioni delle macchine.

Sima ha descritto l’AI come l’interfaccia e il collante tra prodotti frammentati. Litty ha offerto un’interpretazione più cauta, sostenendo che gli strumenti esistenti evolveranno anziché produrre un’esplosione di nuovi strumenti. Entrambe le visioni indicano una battaglia per il control plane.

Se gli agenti mediano il lavoro di sicurezza, il prodotto che controlla identità, contesto e orchestrazione acquisisce influenza sul resto dello stack. I fornitori di endpoint, cloud, identità, osservabilità e ticketing competeranno per diventare quel livello operativo.

Le più ampie tendenze tecnologiche di Gartner includono cybersecurity preventiva, provenienza digitale e piattaforme di sicurezza AI tra i propri temi strategici. Tale raggruppamento suggerisce che il mercato stia passando da assistenti isolati verso sistemi che coordinano prevenzione, fiducia e supervisione.

Il risultato non sarà un unico agente di sicurezza universale. I grandi ambienti necessitano di agenti specializzati con autorizzazioni limitate e responsabilità chiare. Un livello centrale di policy può coordinarli preservando al contempo la separazione tra indagine, raccomandazione, esecuzione e audit.

Per i professionisti della sicurezza, il vantaggio duraturo è il giudizio sostenuto da una solida profondità tecnica. Gli agenti possono raccogliere più prove di una singola persona, ma qualcuno deve decidere cosa l’organizzazione valorizza, quali fallimenti può tollerare e quando l’automazione ha oltrepassato il proprio mandato.

Tre segnali mostreranno se la cybersecurity agentica è pronta

Il prossimo test non sarà un’altra dimostrazione impressionante, ma un’autorità misurabile in condizioni di produzione.

Il primo segnale è l’espansione dall’arricchimento degli avvisi alla risposta circoscritta. I fornitori mostrano già agenti che indagano sui casi e generano rilevamenti. La prova più significativa arriverà quando i clienti consentiranno a questi sistemi di eseguire un contenimento reversibile su workload reali.

Osservate il confine delle autorizzazioni, non l’etichetta di marketing. Un SOC autonomo resta perlopiù un assistente se ogni azione richiede una traduzione manuale in un’altra console. Diventa operativamente significativo quando policy predefinite gli consentono di agire direttamente.

Il secondo segnale è una misurazione indipendente della qualità della remediation. I soli conteggi di rilevamento possono premiare sistemi rumorosi. Gli acquirenti hanno bisogno di risultati che coprano rilevamenti validi, accuratezza della prioritizzazione, accettazione delle correzioni, ricorrenza, falsi contenimenti e tempo necessario per ripristinare le normali operazioni.

Queste prove devono estendersi oltre la scansione del codice sorgente. Gli ambienti aziendali comprendono percorsi di identità, configurazioni di runtime, servizi di terze parti e sistemi legacy. Prestazioni affidabili su questi livelli rafforzerebbero l’argomentazione secondo cui la difesa autonoma può andare oltre compiti circoscritti.

Il terzo segnale è una governance degli agenti applicabile. Le organizzazioni dovrebbero poter inventariare ogni agente di sicurezza, identificarne il proprietario, ispezionarne le autorizzazioni, ricostruirne le azioni e disabilitarlo rapidamente. Standard e controlli dei fornitori devono rendere queste capacità una prassi ordinaria.

I progressi nella governance ridurrebbero la principale barriera di fiducia. Aiuterebbero inoltre i CISO a distinguere la delega controllata dall’automazione ombra, in cui dipendenti o strumenti creano agenti senza una chiara titolarità.

Il mancato riscontro di questi segnali indebolirebbe le previsioni della Cloud Security Alliance sulla sicurezza dell’AI. Gli agenti potrebbero comunque migliorare la produttività, ma resterebbero assistenti all’interno di strutture operative familiari. Il successo produrrebbe un SOC diverso, basato su policy, orchestrazione e gestione delle eccezioni.

I CISO non devono attendere una piattaforma pienamente autonoma. Possono individuare un flusso di lavoro ad alto volume, documentarne i requisiti probatori e concedere a un agente le autorizzazioni più ristrette necessarie per migliorarlo. Possono quindi testarne le prestazioni rispetto ad analisti esperti.

I responsabili della sicurezza e dell’ingegneria dovrebbero inoltre esaminare le informazioni ricevute dagli agenti. Registri architetturali, proprietà degli asset, eccezioni operative e cronologia degli incidenti determinano se le raccomandazioni automatizzate siano adatte all’ambiente reale. Modelli migliori non possono compensare l’assenza di contesto istituzionale.

La domanda immediata è concreta: quale decisione nel vostro SOC attuale è abbastanza ripetitiva, misurabile, reversibile e vincolata da poter essere delegata in sicurezza? Partite da lì, registrate ogni risultato ed estendete l’autorità solo quando le evidenze lo giustificano. Questo approccio preserva la velocità promessa dalla cybersecurity agentica senza fingere che la velocità produca automaticamente fiducia.