Quando centinaia di agenti AI attaccano in parallelo, la catena decisionale umana diventa il primo punto di rottura
Il tempo non è più dalla vostra parte
Da zero a domain admin in sei ore. Undici organizzazioni compromesse in ventisei secondi. Non si tratta di un esercizio di red teaming né di una simulazione accademica. Le evidenze di settore più recenti documentano uno scenario operativo reale: centinaia di agenti AI, addestrati in ambienti di laboratorio, sono stati lanciati simultaneamente contro quasi quattrocento organizzazioni distribuite in quarantotto paesi. L'obiettivo erano istanze di software di stampa esposte a Internet. L'esecuzione di codice remoto è avvenuta in meno di quattro ore. Il primo domain admin è caduto nelle due ore successive. Poi, la compromissione si è estesa a sciame.
L'attore, con ogni probabilità russofono, ha dimostrato una capacità che fino a dodici mesi fa restava confinata nei paper di ricerca: orchestrazione agentica lungo l'intero ciclo di attacco, dalla scansione alla lateralizzazione. Come osserva Kelli Vanderlee, Senior Manager del Threat Intelligence Group di Google, gli attori più avanzati stanno già integrando capacità agentiche operative, non sperimentali. E la disponibilità crescente di modelli open-weight sta rendendo queste capacità accessibili ben oltre la cerchia degli stati-nazione.
Un problema di architettura, non di competenze
La reazione istintiva è chiedere più analisti, più strumenti, più budget per il SOC. Ma il dato dice altro. Se uno sciame di agenti AI può compromettere un dominio Active Directory in sei ore e colpire undici organizzazioni in ventisei secondi, il modello difensivo tradizionale, detect, triage, escalate, respond, non è lento: è strutturalmente inadeguato. Non è una questione di skill degli operatori. È una questione di architettura difensiva e di proporzionalità tra investimento e velocità della minaccia.
C'è un secondo elemento che il board deve considerare. Il fenomeno del LLMJacking, il dirottamento delle risorse AI aziendali per alimentare attacchi, trasforma l'investimento in intelligenza artificiale dell'organizzazione in una superficie d'attacco aggiuntiva. L'infrastruttura che avete finanziato per l'efficienza operativa può diventare l'arma dell'attaccante. La domanda per il comitato rischi non è se il SOC sia abbastanza veloce. È se il livello di automazione difensiva sia proporzionato alla velocità offensiva che oggi è documentata e misurabile.
La governance come collo di bottiglia
Qui si apre la frizione che nessun tool può risolvere. Il responsabile della sicurezza può disporre degli strumenti più avanzati sul mercato. Ma se l'isolamento di un segmento di rete richiede l'approvazione del change management, se l'attivazione dell'incident response passa per una catena di escalation che coinvolge tre livelli gerarchici, se la comunicazione al board è subordinata a una validazione legale, il gap temporale tra attacco e risposta diventa incolmabile.
L'attacco AI-driven non aspetta l'approvazione. Non rispetta le finestre di manutenzione. Non tiene conto dell'agenda del comitato esecutivo. La governance tradizionale, costruita su processi sequenziali e validazioni umane, diventa il primo collo di bottiglia della resilienza operativa. Non perché sia mal progettata, ma perché è stata disegnata per una velocità offensiva che non esiste più. Il punto cieco non è tecnologico. È organizzativo. La responsabilità di risolverlo non è delegabile a chi gestisce la sicurezza operativa: appartiene a chi disegna i processi decisionali dell'organizzazione.
Il metro di misura normativo
Il quadro regolatorio europeo, pur senza disciplinare direttamente gli attacchi a sciame, offre un metro di misura preciso contro cui valutare la vostra postura. L'articolo 21 della Direttiva NIS2 impone misure di gestione del rischio proporzionate, inclusa la gestione degli incidenti e la sicurezza della supply chain. La velocità di compromissione oggi documentata interroga frontalmente l'adeguatezza dei tempi di risposta dichiarati nei piani di incident response. Se il vostro piano prevede un tempo di contenimento di ventiquattro ore, e la compromissione completa avviene in sei, la sproporzione è oggettiva e verificabile.
Il Regolamento DORA, agli articoli 5 e 6, impone alle entità finanziarie di testare la capacità di risposta e la resilienza operativa digitale. Uno scenario di attacco a sciame che colpisce undici organizzazioni in ventisei secondi diventa un benchmark implicito: i vostri test di resilienza contemplano questa scala temporale? Il dibattito europeo sull'AI Act, infine, tocca il tema della responsabilità nella distribuzione di modelli open-weight utilizzabili per scopi offensivi, ma il collegamento resta contestuale e non produce oggi obblighi diretti. Il terreno normativo solido è NIS2 e DORA: lì si misura la vostra adeguatezza.
La domanda che il board non può rinviare
Cliff Steinhauer, Director of Information Security and Engagement della National Cybersecurity Alliance, sottolinea un punto che merita attenzione a livello di vertice: l'igiene di sicurezza resta necessaria, ma non è più sufficiente a garantire resilienza contro attacchi che operano su scale temporali incompatibili con i processi decisionali umani. Il vero nodo non è se avete un piano di incident response. È se quel piano è dimensionato su tempi che esistono ancora.
Sei ore per la compromissione completa. Ventisei secondi per la propagazione laterale. I vostri processi di escalation, approvazione e risposta sono stati progettati per reggere questa pressione? Oppure sono stati disegnati in un'epoca in cui l'attaccante era umano, sequenziale e ragionevolmente prevedibile? La risposta a questa domanda non è tecnica. È una scelta di governance che definisce il livello reale di resilienza dell'organizzazione. E quella scelta spetta al board, non al SOC.
Se il vostro piano di risposta agli incidenti è ancora calibrato sulla velocità di un attaccante umano, non avete un piano. Avete un documento.