La difesa dalle minacce AI di Google incontra aggressori che si muovono alla velocità delle macchine
Google ha documentato una prima ondata di attacchi operativi basati sull'AI che condensano ore di ricognizione, programmazione e furto di credenziali in un unico flusso di lavoro automatizzato. Il suo aggiornamento di sicurezza del 16 settembre contrappone la Google AI threat defense ad avversari che ora impiegano agenti in diverse fasi dell'attacco.
Il conflitto centrale non riguarda più analisti umani in competizione con autori di phishing più rapidi. Google afferma che gli aggressori stanno collegando modelli, infrastrutture cloud, account rubati e strumenti di hacking convenzionali in sistemi capaci di pianificare e adattarsi. Un'indagine di Mandiant ha rilevato che una campagna di credenziali abilitata da agenti è stata completata in meno di sei ore.
La risposta di Google combina diversi modelli con telemetria interna, contesto cloud, indagini automatizzate e correzione del software. L'azienda sostiene che i difensori mantengano un vantaggio perché comprendono il proprio codice, le identità, le configurazioni e i sistemi in esecuzione. Tuttavia, tale vantaggio esiste solo quando le organizzazioni riescono a collegare queste fonti di dati e a fidarsi delle azioni difensive automatizzate.
Questa precisazione è importante. Google fornisce gran parte delle prove a sostegno sia della diagnosi della minaccia sia della soluzione proposta. Framework indipendenti di NIST e MITRE supportano il modello di rischio più ampio, ma non convalidano ogni dichiarazione sui prodotti.
Il risultato è un test rilevante per la sicurezza aziendale. Gli aggressori stanno riducendo il ritardo tra intenzione ed esecuzione. I difensori devono decidere se i sistemi AI connessi possano ridurre i propri ritardi senza creare un ulteriore livello opaco e privilegiato all'interno della rete.
La Google AI Threat Defense parte da tre cambiamenti nel modello di minaccia
L'aggiornamento di Google considera l'AI un rischio per la catena di fornitura del software, una nuova superficie di attacco e un acceleratore operativo per gli aggressori.
Sandra Joyce, vicepresidente di Google Threat Intelligence, ha organizzato la valutazione dell'azienda attorno a questi tre cambiamenti strutturali. L'argomentazione compare nell'edizione di settembre di Google Cloud di Cloud CISO Perspectives.
Il primo cambiamento inizia durante lo sviluppo del software. Gli assistenti di programmazione AI possono consigliare pacchetti, generare file di configurazione, modificare repository e avviare strumenti. Queste capacità creano maggiori opportunità affinché una dipendenza avvelenata o un'istruzione dannosa entri in un flusso di lavoro fidato.
Google Threat Intelligence Group, o GTIG, collega le pratiche di coding assistito dall'AI alle grandi compromissioni della catena di fornitura del software osservate nel 2025 e all'inizio del 2026. Descrive aggressori che prendono di mira insieme sviluppatori, registri di pacchetti, assistenti AI e scanner automatizzati.
UNC6780, chiamato anche TeamPCP, illustra tale schema. Google afferma che il gruppo con motivazioni finanziarie ha utilizzato più di sei tecniche che coinvolgono strumenti AI e pratiche di sviluppo open source.
I suoi metodi avrebbero incluso toolkit AI dirottati, pacchetti avvelenati, prompt injection e istruzioni progettate per interferire con gli scanner AI. Alcuni file dannosi erano nascosti nelle directory di progetto usate dagli assistenti di programmazione e dagli ambienti di sviluppo.
Questo posizionamento è importante perché un assistente AI può interpretare le istruzioni del repository come contesto di progetto legittimo. Uno sviluppatore può quindi ereditare comportamenti dannosi senza eseguire deliberatamente un binario sconosciuto.
Google afferma che UNC6780 ha inoltre compromesso account di sviluppatori e pubblicato versioni trojanizzate di risorse Model Context Protocol. Model Context Protocol, o MCP, consente alle applicazioni AI di connettersi con strumenti e dati esterni.
In un'altra tecnica, il codice dannoso tentava di acquisire token dai sistemi di integrazione continua. Token validi potrebbero far apparire affidabili i pacchetti compromessi ai controlli automatizzati.
Il secondo cambiamento strutturale riguarda gli stessi sistemi AI. Modelli, prompt, istruzioni degli agenti, codice sorgente, credenziali e quote di calcolo sono diventati obiettivi di valore.
Secondo Google, Mandiant ha indagato diverse operazioni di estorsione tramite furto di dati durante il secondo trimestre del 2026. Gli aggressori hanno sottratto modelli proprietari, prompt, competenze, codice sorgente e ricerca correlata.
Questi incidenti hanno colpito organizzazioni oltre i laboratori AI di frontiera. Google ha identificato vittime nei settori della tecnologia, della sanità, dei media e dell'intrattenimento in Nord America e in Europa.
L'azienda segnala anche una domanda persistente di account AI rubati. Venditori nei mercati clandestini pubblicizzavano alcuni account consumer con sconti fino al 99 per cento rispetto ai prezzi al dettaglio.
Queste credenziali servono a diversi scopi. Gli aggressori possono evitare i controlli di identità, oscurare l'attribuzione, accedere a capacità limitate o trasferire i costi di inferenza sulle vittime.
Google definisce una versione di questo abuso LLMJacking. Un aggressore ruba l'accesso al cloud e distribuisce carichi di lavoro AI non autorizzati, lasciando alla vittima il costo del consumo dell'infrastruttura.
Il terzo cambiamento riguarda il ritmo operativo. L'ultimo AI threat tracker descrive avversari che passano da prompt isolati a flussi di lavoro agentici.
L'AI agentica indica software in grado di selezionare azioni, usare strumenti, valutare risultati e proseguire verso un obiettivo con una supervisione umana ridotta. Questa autonomia può eliminare le pause tra le fasi convenzionali di un attacco.
Nessuna di queste categorie è del tutto nuova. Avvelenamento dei pacchetti, furto di credenziali, abuso del cloud e scansione automatizzata esistevano prima dell'AI generativa.
Ciò che è cambiato è la loro integrazione. I modelli possono tradurre obiettivi in linguaggio naturale in script, risolvere problemi nei passaggi falliti, selezionare strumenti e conservare istruzioni operative in file riutilizzabili.
Questa integrazione definisce la tensione centrale dell'articolo. Google vede emergere attacchi alla velocità delle macchine da tecniche familiari, mentre molti team di sicurezza continuano a indagare su tali tecniche tramite code scollegate.
Una campagna di credenziali di sei ore mostra perché i team di sicurezza sono sotto pressione
Lo sviluppo più importante non è una nuova primitiva di hacking, ma il collasso del tempo tra pianificazione, esecuzione e scala.
Durante il secondo trimestre del 2026, Mandiant ha indagato un'intrusione che coinvolgeva un framework autonomo multi-agente all'interno di un'infrastruttura cloud compromessa. Google attribuisce l'attività a un presunto attore con motivazioni finanziarie.
L'aggressore ha utilizzato un chatbot AI per la programmazione, un prompt e istruzioni per agenti preparate in anticipo. Insieme, questi componenti hanno pianificato, creato ed eseguito una raccolta massiva di credenziali in meno di sei ore.
Google afferma che il framework ha gestito la scansione delle vulnerabilità, risolto errori operativi e trattato la rotazione degli IP con un intervento umano limitato. Alla fine ha compromesso migliaia di credenziali di terze parti.
Operare dall'ambiente cloud di una vittima offriva un ulteriore vantaggio. Il traffico di attacco proveniva da un'infrastruttura legittima anziché da un server palesemente ostile.
La cifra di sei ore merita un'interpretazione prudente. Deriva da una sola campagna investigata, non da una mediana valida per l'intero settore. Google non ha pubblicato un numero sufficiente di casi comparabili per stabilire un tasso di accelerazione universale.
Tuttavia, il caso mostra perché le attuali operazioni di sicurezza subiscano pressioni. Gli analisti umani lavorano spesso su avvisi statici dopo che gli strumenti hanno rilevato separatamente eventi relativi a identità, endpoint, codice e cloud.
Un framework di attacco autonomo non rispetta questi confini organizzativi. Può testare una credenziale, scoprire un servizio esposto, modificare uno script e proseguire senza aprire ticket separati.
Google ha inoltre identificato un ambiente di comando e controllo esposto associato alla ricognizione automatizzata. La sua dashboard era progettata per organizzare e convalidare oltre 23.800 segreti raccolti.
Il sistema conteneva, secondo quanto riportato, file di configurazione degli agenti e documenti di conoscenza riutilizzabili. La struttura suggerisce che gli aggressori stiano trattando le istruzioni e il contesto accumulato come infrastruttura operativa.
Un esempio separato di spionaggio rafforza il modello. Google ha osservato un gruppo legato alla Cina sperimentare CC Switch, uno strumento per instradare attività tra diversi modelli AI.
L'attore avrebbe alternato Claude, Codex e Gemini. Ha selezionato modelli diversi per scripting di exploit, redazione di esche e correzione degli errori.
Si tratta di un cambiamento significativo rispetto all'idea di un singolo criminale che usa un solo chatbot. Il modello emergente assomiglia a una pipeline software coordinata con molteplici componenti specializzati.
I difensori subiscono quindi pressioni da due direzioni. Devono proteggere le proprie risorse AI rispondendo al contempo ad avversari che usano l'AI per coordinare attacchi convenzionali.
Gli sviluppatori avvertono per primi la pressione perché gli assistenti ora agiscono all'interno di repository, editor, terminali e sistemi di build. Una dipendenza dannosa può raggiungere la produzione prima che inizi una revisione di sicurezza separata.
I team delle operazioni di sicurezza affrontano il ritardo successivo. Devono ricostruire le relazioni tra identità, risorse cloud, artefatti software, modelli e dati dopo la comparsa di comportamenti sospetti.
Anche gli acquirenti aziendali affrontano un problema di governance. Un agente può disporre di accesso legittimo a vari sistemi, rendendo più difficile distinguere le azioni dannose dall'automazione autorizzata.
Per questo Google paragona le protezioni per gli sviluppatori a un correttore ortografico. L'azienda vuole che i controlli operino all'interno dell'editor e del flusso di lavoro degli agenti, dove possano segnalare immediatamente pacchetti o istruzioni sospetti.
L'analogia è utile ma incompleta. Una correzione ortografica raramente attiva codice, modifica diritti di accesso o influenza l'infrastruttura di produzione.
Le evidenze di sicurezza dipendono inoltre da un contesto che l'editor non possiede. Un modello di codice può essere sicuro isolatamente, ma pericoloso quando è collegato a un carico di lavoro esposto o a un'identità privilegiata.
La risposta necessaria è quindi più ampia dell'aggiunta di un altro scanner. Le organizzazioni necessitano di collegamenti tra attività di sviluppo e infrastruttura operativa, oltre a policy che disciplinino a cosa gli agenti possano accedere e cosa possano eseguire.
Questo requisito solleva la questione competitiva alla base della strategia di Google. Un sistema difensivo connesso può rispondere abbastanza rapidamente senza concentrare troppa fiducia nella propria automazione?
La sfida è tra automazione degli aggressori e contesto dei difensori
La principale affermazione di Google è che gli aggressori hanno velocità, ma i difensori possono vincere combinando la velocità con un contesto interno superiore.
Gli aggressori spesso iniziano dall'esterno dell'ambiente bersaglio. Analizzano servizi esposti, testano credenziali rubate, deducono l'architettura e cercano percorsi utili.
I difensori sanno già molto di più. Possono vedere quali identità sono privilegiate, quali servizi sono esposti a internet e quali archivi di dati contengono informazioni sensibili.
Sanno anche quale codice ha prodotto un carico di lavoro e quale configurazione lo governa. In teoria, queste relazioni consentono a un modello difensivo di dare priorità al percorso di attacco che crea un rischio aziendale reale.
La strategia di Google dipende dalla trasformazione di questa teoria in un grafo di sicurezza connesso. Un grafo di sicurezza mappa le relazioni tra codice, risorse cloud, dati, modelli, vulnerabilità e identità.
Dopo l'acquisizione di Wiz, Google posiziona il Wiz Security Graph come livello contestuale nella sua più ampia architettura di AI Threat Defense. Il framework incorpora inoltre Gemini, l'intelligence di Mandiant, CodeMender e Google Security Operations.
Google afferma che questa architettura può identificare percorsi di attacco tossici, dare priorità ai rischi, indagare le attività e supportare la remediation. È un'ambiziosa dichiarazione di integrazione di prodotto, non un risultato dimostrato in modo indipendente.
L'architettura riflette anche un più ampio cambiamento nel settore. Le piattaforme di sicurezza competono sempre più sull'efficacia con cui collegano i segnali, non semplicemente sul numero di avvisi che generano.
Un pacchetto vulnerabile ha un peso diverso quando compare in un progetto di test isolato. Lo stesso pacchetto diventa urgente all'interno di un servizio esposto a Internet con accesso ai segreti di produzione.
L'identità aggiunge un ulteriore livello. Un problema di configurazione a bassa gravità può diventare critico quando un agente dispone di autorizzazioni estese e può richiamare strumenti esterni.
Anche la provenienza dei dati è importante. Registra l'origine delle informazioni, il modo in cui i sistemi le hanno trasformate e i modelli o le applicazioni che le hanno utilizzate.
Google sostiene che queste relazioni debbano informare ogni fase della difesa. L'analisi del codice dovrebbe considerare l'esposizione a runtime, mentre il monitoraggio cloud dovrebbe risalire dalle debolezze alla loro origine.
Questo approccio mette sotto pressione i fornitori che vendono controlli di sicurezza isolati. Uno scanner autonomo può rilevare un difetto, ma non avere il contesto necessario per valutarne l'impatto effettivo.
Mette inoltre sotto pressione le aziende con responsabilità frammentate. I team di sviluppo, cloud, identità, operazioni di sicurezza e governance dell'AI spesso mantengono inventari separati.
Una piattaforma integrata non può dedurre relazioni affidabili quando tali inventari sono incompleti. La qualità della difesa dalle minacce AI di Google dipende quindi in parte dal lavoro che i clienti devono completare autonomamente.
Le organizzazioni necessitano di informazioni accurate su responsabilità, confini dell'identità, inventari software e classificazioni dei dati. Altrimenti, il grafo può collegare un'ampia telemetria senza coglierne il significato aziendale.
Questa dipendenza rende la conoscenza interna una risorsa di sicurezza. I team di ingegneria necessitano di documentazione accessibile che spieghi perché gli agenti dispongono di determinate autorizzazioni, quali repository alimentano la produzione e chi è responsabile di ogni workflow.
Una base di conoscenza ricercabile può sostenere questo livello documentale. Non sostituisce la telemetria di sicurezza, i controlli di accesso o la risposta agli incidenti.
La competizione decisiva non è quindi Google contro un singolo rivale nominato. È l'automazione degli attaccanti contro il contesto dei difensori.
La tesi di Google riesce quando il contesto aziendale è completo, aggiornato e disponibile ai sistemi difensivi. Si indebolisce quando i dati organizzativi restano frammentati o le autorizzazioni superano le necessità operative.
Perché Google usa più modelli per la cybersecurity AI
Google respinge l'idea che un singolo modello di frontiera possa rilevare in modo affidabile ogni vulnerabilità, istruzione malevola e difetto logico.
L'azienda descrive un approccio deliberatamente multi-modello alla sicurezza. Orchestra Gemini insieme a modelli commerciali e open source, quindi confronta i rispettivi risultati.
Google afferma che questo processo può ridurre i falsi positivi, individuare difetti complessi e generare remediation che un singolo modello non rileva. La tesi affronta una debolezza reale della sicurezza basata su un unico modello.
Ogni modello presenta punti ciechi caratteristici. Dati di addestramento, filtri di policy, limiti di contesto, istruzioni di sistema e accesso agli strumenti determinano ciò che riesce a rilevare.
Gli attaccanti possono sondare questi confini. Google ha osservato commenti JavaScript malevoli contenenti testo estremo che apparentemente mirava a provocare rifiuti di sicurezza negli scanner basati su LLM.
Il payload malevolo si trovava sotto tali istruzioni. Se uno scanner rifiutasse l'intera analisi, l'attaccante potrebbe usare il comportamento di sicurezza del modello come tecnica per eludere le difese.
Google riferisce che le salvaguardie di Gemini hanno risposto al contenuto. Afferma inoltre che l'intelligence risultante ha contribuito a rafforzare i classificatori e a interrompere account e infrastrutture associati.
Un'architettura multi-modello può ridurre la dipendenza da una sola policy di rifiuto. Se un modello rifiuta un'attività o trascura uno schema, un altro può comunque identificare comportamenti sospetti.
La convalida incrociata può anche aiutare a distinguere debolezze reali da risultati plausibili ma errati. I modelli restano inclini a generare spiegazioni convincenti che non corrispondono al codice eseguibile.
Tuttavia, l'aggiunta di modelli non produce automaticamente un consenso affidabile. Più modelli possono condividere fonti di addestramento, architetture comuni o fallimenti di valutazione simili.
L'orchestrazione introduce una propria superficie d'attacco. Il sistema deve decidere quale modello riceva i dati, quali strumenti ogni modello possa richiamare e in che modo risultati contrastanti influenzino le azioni in produzione.
Anche costi e latenza contano. L'analisi ripetuta da parte di più modelli richiede maggiore capacità di calcolo e può rallentare decisioni sensibili al tempo.
La risposta proposta da Google è la prioritizzazione contestuale. L'analisi costosa può concentrarsi su codice e asset collegati a sistemi esposti o privilegiati.
Questo crea un meccanismo a due parti. Più modelli ampliano il rilevamento, mentre il grafo di sicurezza restringe l'attenzione ai risultati con conseguenze operative reali.
CodeMender rappresenta il lato della remediation. Google lo descrive come un agente AI che trova e corregge vulnerabilità software, spostando parte del lavoro difensivo dal rilevamento alle modifiche del codice sorgente.
Il patching automatizzato potrebbe ridurre il tempo di esposizione, soprattutto per schemi di vulnerabilità ricorrenti. Tuttavia, le modifiche al codice richiedono rigorosi controlli di test, revisione e rollback.
Una patch che elimina una debolezza può modificare il comportamento dell'applicazione o crearne un'altra. Gli agenti di remediation ad alto privilegio necessitano quindi di autorizzazioni più ristrette di quanto le loro capacità tecniche potrebbero consentire.
Qui diventano utili linee guida indipendenti. Il Cyber AI Profile in sviluppo del NIST separa il campo nella protezione dei sistemi AI, nella conduzione di difese abilitate dall'AI e nel contrasto degli attacchi abilitati dall'AI.
Queste categorie si allineano strettamente al modello di minaccia di Google. Impediscono inoltre alle organizzazioni di trattare un prodotto di sicurezza AI come un programma di governance completo.
MITRE ha ampliato ATLAS, il proprio framework di minacce avversarie per l'AI, per includere sistemi agentici e modelli linguistici di grandi dimensioni. La sua espansione di ATLAS del 2026 riflette la necessità di tecniche e mitigazioni condivise tra fornitori.
I framework condivisi sono importanti perché i clienti necessitano di metodi portabili per testare le dichiarazioni difensive. Il benchmark interno di un fornitore non può rivelare come il suo sistema operi sulle autorizzazioni e sui workflow di un'altra organizzazione.
La sicurezza multi-modello è quindi un meccanismo, non una prova di superiorità. Il suo valore dipende dalla diversità dei fallimenti, dall'accesso controllato agli strumenti, da risultati misurabili e da una remediation sicura.
La difesa dalle minacce AI di Google presenta un'architettura credibile per questo meccanismo. I clienti necessitano comunque di prove che mostrino quanto costantemente funzioni in condizioni di produzione.
Le prove indicano urgenza, non una cyberguerra autonoma
La telemetria di Google mostra un'automazione significativa, ma non dimostra che gli attaccanti conducano su larga scala intrusioni end-to-end completamente autonome.
Questa distinzione è l'essenziale angolazione scettica dell'articolo. I titoli sugli attacchi alla velocità delle macchine possono implicare che sistemi autonomi abbiano già sostituito gli operatori qualificati.
La reportistica dettagliata di Google è più prudente. GTIG afferma che gli avversari stanno integrando l'AI in ricognizione, sviluppo di exploit, ingegneria sociale, troubleshooting e raccolta di credenziali.
Il gruppo afferma inoltre di non aver ancora osservato pipeline completamente autonome condurre lo sfruttamento di zero-day contro obiettivi nel mondo reale.
Le prove mostrano invece una graduale maturità operativa. Gli attaccanti usano modelli commerciali e open-weight esistenti per accelerare attività note, soprattutto dopo che le vulnerabilità diventano pubbliche.
Un caso ha coinvolto artefatti generati dall'AI che prendevano di mira una vulnerabilità di Firefox già corretta. Google ha rilevato script che progredivano da sonde diagnostiche verso catene di esecuzione più complete.
Gli artefatti sono comparsi circa un mese dopo che il fornitore aveva rilasciato una patch. L'esempio suggerisce un'iterazione più rapida su vulnerabilità note, non la scoperta autonoma confermata di un difetto sconosciuto.
Un altro caso ha riguardato un tentativo di framework automatizzato per penetration test. GTIG afferma che l'attore responsabile cercava di costruire un agente capace di scoperta ed esecuzione.
Google ha disabilitato gli asset associati e il rapporto descrive il lavoro come un tentativo. Non dovrebbe essere presentato come una compromissione autonoma riuscita.
La campagna di credenziali di sei ore è una prova più solida perché Mandiant ne ha osservato l'uso operativo. Anche in quel caso, un attaccante ha fornito il prompt, il chatbot, le istruzioni e l'infrastruttura compromessa.
Il sistema ha ridotto il coinvolgimento umano, ma le prove pubbliche non dimostrano una completa indipendenza. Termini come “velocità delle macchine” dovrebbero quindi descrivere la compressione dei workflow, non un'autonomia illimitata.
Anche la visibilità di Google ha dei confini. I suoi rapporti attingono da indagini di Mandiant, segnali di abuso di Gemini, monitoraggio degli attori delle minacce e difese delle piattaforme Google.
Si tratta di un dataset significativo, ma non copre ogni fornitore di modelli, implementazione privata, cloud o ambiente delle vittime.
I modelli open-weight eseguiti su hardware compromesso possono eludere il monitoraggio delle API commerciali. Google cita un attore legato alla Cina che ha implementato modelli locali all'interno dell'infrastruttura delle vittime per questo motivo.
Le lacune di copertura contano quando si valutano le dichiarazioni di interruzione. Disabilitare un account Google può interrompere un'operazione, spingendone però un'altra verso strumenti locali o servizi concorrenti.
L'automazione difensiva crea un'incertezza parallela. Google sostiene che un ricco contesto interno renda i difensori più rapidi e accurati degli attaccanti.
È ragionevole sul piano generale, ma l'accuratezza deve essere misurata rispetto a falsi positivi, attacchi mancati, tempi di indagine e remediation non sicure. L'azienda non ha pubblicato metriche di produzione comparabili in questo annuncio.
La ricerca del NIST aggiunge un'altra cautela. Il suo lavoro del giugno 2026 sul monitoraggio continuo sostiene che guardrail fissi non possono restare universalmente affidabili contro prompt avversari adattivi.
Questo risultato sostiene l'approccio di feedback continuo di Google. Significa inoltre che nessun classificatore, insieme di modelli o livello di policy dovrebbe essere considerato sicuro in modo permanente.
Il rischio è particolarmente elevato quando gli agenti difensivi ricevono privilegi estesi. Una conclusione errata di uno strumento osservativo genera rumore. Lo stesso errore da parte di un agente di remediation può modificare i sistemi di produzione.
Le organizzazioni dovrebbero richiedere un'autonomia graduata. Le azioni a basso rischio possono essere eseguite automaticamente, mentre le azioni distruttive o che modificano l'identità richiedono revisione.
Dovrebbero inoltre isolare le credenziali degli agenti, registrare le chiamate agli strumenti, testare le procedure di rollback e conservare le prove per le indagini umane. L'automazione senza verificabilità sposta semplicemente l'incertezza più rapidamente.
L'aggiornamento di Google sostiene la necessità di una preparazione urgente. Non giustifica l'affermazione che la cyberguerra autonoma sia arrivata o che una piattaforma integrata abbia risolto il problema.
Tre segnali metteranno alla prova la tesi di Google sulla difesa dalle minacce AI
Il prossimo test sarà verificare se Google riuscirà a trasformare rapporti sugli incidenti di forte impatto in risultati difensivi misurabili in modo indipendente.
Il primo segnale è rappresentato dalle prove operative delle implementazioni di AI Threat Defense. I clienti dovrebbero cercare riduzioni documentate dei tempi di indagine, dei falsi positivi, della durata dell'esposizione e degli incidenti ripetuti.
I diagrammi architetturali non possono rispondere a queste domande. I case study necessitano di condizioni iniziali chiare, periodi di valutazione e spiegazioni delle azioni rimaste sotto controllo umano.
Le prove in ambienti diversi rafforzerebbero la tesi di Google. I risultati ottenuti in un singolo ambiente cloud ben strumentato rivelerebbero meno sulle organizzazioni frammentate e multicloud.
Metriche deboli o selettive indebolirebbero l’affermazione secondo cui il contesto integrato produce un vantaggio asimmetrico. Gli acquirenti dovrebbero anche chiedersi come la piattaforma gestisca l’assenza di responsabilità chiare o una telemetria incompleta.
Il secondo segnale è l’ulteriore ricorso degli attaccanti a pipeline autonome e multi-agente. I prossimi report sulle minacce di Google dovrebbero distinguere tra esperimenti, operazioni assistite e campagne end-to-end riuscite.
Un aumento delle campagne ripetibili della durata di sei ore rafforzerebbe la diagnosi di un’operatività alla velocità delle macchine. Lo sfruttamento autonomo confermato di vulnerabilità precedentemente sconosciute alzerebbe ulteriormente la posta.
Al contrario, una dipendenza continuativa da vulnerabilità note, playbook forniti da esseri umani e infrastrutture rubate sosterrebbe una conclusione più circoscritta. L’AI resterebbe comunque rilevante, ma soprattutto come acceleratore delle tecniche già esistenti.
Gli analisti dovrebbero monitorare come gli attaccanti ripartiscono il lavoro tra i modelli. L’esempio di CC Switch suggerisce che gli avversari sceglieranno gli strumenti in base al compito, anziché restare fedeli a un singolo fornitore.
Questa diversità di modelli complica l’interruzione delle attività a livello di fornitore. Supporta inoltre i test difensivi su più famiglie di modelli e comportamenti di rifiuto.
Il terzo segnale è se gli standard condivisi producano controlli verificabili per la sicurezza agentica. Il Cyber AI Profile di NIST e MITRE ATLAS offrono alle organizzazioni un linguaggio vendor-neutral per affrontare il problema.
Progressi utili includerebbero controlli concreti su autorizzazioni degli strumenti, inventari dei modelli, prompt injection, provenienza dei dati, registrazione degli incidenti e remediation autonoma. Tali controlli dovrebbero essere associati a evidenze osservabili.
La loro adozione rafforzerebbe l’argomentazione più ampia di Google secondo cui la difesa AI richiede operazioni connesse e continue. Impedirebbe inoltre a Google di definire il successo interamente attraverso le proprie categorie di prodotti.
La tesi si indebolisce se le linee guida del settore restano astratte mentre gli agenti acquisiscono privilegi in produzione. Le imprese si troverebbero allora di fronte a un’automazione più rapida senza metodi coerenti per testarla o sottoporla ad audit.
I responsabili della sicurezza non dovrebbero aspettare standard perfetti. Possono già censire gli asset AI, restringere le autorizzazioni degli agenti, collegare il codice all’esposizione in runtime e testare i workflow di gestione degli incidenti.
Gli sviluppatori dovrebbero trattare le istruzioni dei repository e i file di configurazione AI come un rischio eseguibile. I team di sicurezza dovrebbero monitorare le risorse cloud alla ricerca di workload di modelli non autorizzati e utilizzi insoliti delle credenziali.
I dirigenti dovrebbero porsi una domanda diretta: l’organizzazione dispone di un contesto sufficientemente affidabile da consentire a un difensore automatizzato di agire in sicurezza?
La difesa dalle minacce AI di Google offre una risposta, collegando modelli, threat intelligence, remediation del codice, operazioni di sicurezza e un grafo cloud. Il suo report di settembre sostiene questa tesi con incidenti insolitamente specifici.
Le prove dimostrano che gli attacchi assistiti dall’AI stanno diventando più coordinati e rapidi. Non dimostrano che l’autonomia elimini gli attaccanti umani o garantisca una difesa autonoma.
I prossimi tre mesi dovrebbero chiarire se altre campagne ripeteranno lo schema delle sei ore, se i clienti pubblicheranno risultati misurabili e se gli standard raggiungeranno gli agenti dotati di privilegi.
Fino ad allora, le organizzazioni dovrebbero considerare il report di Google sia un avvertimento sia una sfida progettuale. Collegate il contesto che i difensori già possiedono, limitate ciò che gli agenti possono fare e misurate ogni vantaggio di velocità dichiarato.
