Il rapporto di Google sulle minacce informatiche dell'AI avverte: gli attaccanti stanno colmando il divario di capacità

Google ha documentato attaccanti che hanno sviluppato ed eseguito una campagna di raccolta massiva di credenziali nell'arco di sei ore, pur non disponendo delle risorse normalmente associate a operazioni sponsorizzate da uno Stato.

Il rapporto di Google sulle minacce informatiche dell'AI descrive un passaggio dall'assistenza isolata dei chatbot a flussi di lavoro autonomi multi-agente. Questi sistemi possono gestire scansioni, risolvere malfunzionamenti, ruotare l'infrastruttura e raccogliere credenziali con un coinvolgimento umano limitato.

Questa distinzione conta più del fatto che l'AI inventi tecniche di attacco interamente nuove. I gruppi criminali possono ora coordinare tecniche note con una velocità e una scala che un tempo richiedevano team più grandi, operatori specializzati e infrastrutture consistenti.

Il Google Threat Intelligence Group, o GTIG, ha basato il suo rapporto dell'8 settembre su indagini di Mandiant, monitoraggio delle minacce e attività osservate sulle piattaforme Google. Le sue conclusioni affiancano criminali mossi da motivazioni finanziarie a gruppi collegati agli Stati cinese, iraniano, russo e nordcoreano che impiegano l'AI nell'intero ciclo delle operazioni informatiche.

La competizione non è più semplicemente AI degli attaccanti contro AI dei difensori. È un'offensiva automatizzata contro processi di risposta umani che dipendono ancora da code, passaggi di consegne e revisioni programmate.

Il rapporto di Google sulle minacce informatiche dell'AI documenta un attacco di sei ore

Il cambiamento più evidente è operativo: gli agenti AI stanno passando da ruoli consultivi al ciclo di esecuzione.

Nel secondo trimestre del 2026, Mandiant ha indagato su un sospetto soggetto motivato finanziariamente che aveva compromesso l'infrastruttura cloud di un'organizzazione. L'attaccante ha distribuito un framework autonomo contenente più agenti, ciascuno incaricato di una parte dell'operazione di raccolta delle credenziali.

Secondo Google, il soggetto ha fornito a un chatbot AI per la programmazione un prompt e una raccolta di istruzioni per gli agenti. Tali istruzioni fungevano da playbook operativi riutilizzabili.

Nell'arco di sei ore, il framework ha pianificato, realizzato ed eseguito una campagna di raccolta massiva di credenziali. Secondo GTIG, ha compromesso migliaia di credenziali di terze parti.

Gli agenti hanno fatto più che generare script. Hanno gestito una pipeline di scansione delle vulnerabilità, diagnosticato errori e amministrato la rotazione degli Internet Protocol senza una guida continua dell'operatore.

Questa automazione ha ridotto la latenza human-in-the-loop, ossia il tempo di attesa creato ogni volta che il software necessita di una persona per approvare o correggere la sua azione successiva. Ha inoltre aiutato l'attaccante a sostenere l'attività su un ampio insieme di obiettivi.

L'ambiente cloud compromesso ha fornito un ulteriore vantaggio. Il traffico dell'attacco poteva transitare attraverso indirizzi IP legittimi associati all'infrastruttura della vittima, complicando il rilevamento basato esclusivamente sulla reputazione.

Separatamente, GTIG ha individuato un server di comando e controllo esposto che eseguiva un framework automatizzato di ricognizione e gestione delle credenziali chiamato Recon. Il framework conteneva file di istruzioni e conoscenza progettati per il funzionamento agentico.

La sua directory includeva file quali AGENTS.md, KNOWLEDGE.md e agentic_vuln_research.md. Conteneva inoltre directory modulari per strumenti, memoria e flussi di lavoro automatizzati.

Dopo che GTIG ha rilevato il server esposto, la directory sarebbe diventata una dashboard di produzione. Tale dashboard poteva organizzare, convalidare e gestire in tempo reale oltre 23.800 segreti raccolti.

Questi segreti includevano credenziali per piattaforme cloud e servizi AI. Il caso ha quindi collegato tre rischi che le organizzazioni spesso trattano separatamente: furto di credenziali, compromissione del cloud e accesso non autorizzato all'AI.

Google ha definito l'operazione un passaggio dagli infostealer passivi sugli endpoint a una raccolta agentica offensiva. Gli agenti hanno studiato vulnerabilità, analizzato infrastrutture server e tentato lo sfruttamento mirato con un intervento minimo.

Questo è l'avvertimento centrale del rapporto di Google sulle minacce informatiche dell'AI. Un operatore con risorse modeste può codificare istruzioni una sola volta e lasciare poi che il software le ripeta su migliaia di opportunità.

La tempistica di sei ore non significa che ogni attaccante possa improvvisamente condurre spionaggio di livello élite. Mostra che la capacità di orchestrazione, un tempo limitata dalla disponibilità di personale, può essere sempre più noleggiata, rubata o automatizzata.

L'automazione AI cambia l'orologio dei difensori

I team di sicurezza affrontano ora un problema di tempistiche prima ancora di trovarsi davanti a una classe di exploit del tutto nuova.

La risposta tradizionale agli incidenti presuppone che i difensori dispongano di un certo margine temporale tra ricognizione, sfruttamento, uso delle credenziali e movimento laterale. I sistemi di monitoraggio rilevano gli eventi, gli analisti li convalidano e team distinti coordinano il contenimento.

L'AI agentica comprime queste fasi. Un framework può analizzare, adattarsi, ritentare e passare all'obiettivo successivo mentre un avviso resta ancora da esaminare.

John Hultquist, analista capo di GTIG, ha dichiarato a IT Pro che le organizzazioni dovrebbero presumere che gli attori delle minacce utilizzino già l'AI in qualche misura. Ha avvertito che i criminali privilegeranno attacchi che si muovono più rapidamente di quanto i difensori riescano a rispondere.

La pressione ricade soprattutto sulle organizzazioni i cui controlli di sicurezza generano avvisi senza consentire un contenimento rapido. Un volume maggiore di avvisi offre poca protezione quando gli analisti non possono esaminarli prima che le credenziali rubate diventino percorsi di attacco attivi.

Il problema va oltre i centri operativi di sicurezza. Team dedicati all'identità, amministratori cloud, sviluppatori e manutentori open source controllano tutti risorse raggiungibili da una campagna automatizzata.

La rotazione delle credenziali offre un esempio semplice. Un'organizzazione potrebbe scoprire un segreto esposto nel giro di ore, ma richiedere più approvazioni prima di revocarlo. A un agente dell'attaccante bastano pochi secondi per testare quel segreto altrove.

L'infrastruttura cloud accentua lo squilibrio. Le credenziali rubate possono fornire capacità di elaborazione, posizioni di rete affidabili e accesso a servizi aggiuntivi.

GTIG definisce una forma di questa attività LLMjacking. Gli attaccanti rubano credenziali di piattaforme AI o dirottano ambienti cloud per eseguire carichi di lavoro sui modelli non autorizzati.

Questa pratica consente agli attaccanti di evitare costi diretti per l'infrastruttura. Può inoltre celare la loro attività perché l'elaborazione avviene all'interno dell'account di un'organizzazione legittima.

Nell'aprile 2026, Mandiant ha osservato un soggetto usare accessi rubati a infrastrutture AI per predisporre risorse di elaborazione grafica ad alte prestazioni. La vittima ha assorbito il carico di lavoro e la spesa risultanti.

Lo stesso schema è apparso in una campagna collegata allo Stato cinese monitorata come UNC6508. Google afferma che il gruppo ha distribuito un modello locale a pesi aperti in ambienti cloud compromessi.

L'esecuzione locale del modello ha aiutato il gruppo a evitare il monitoraggio dei servizi AI commerciali. Ha inoltre trasferito il carico computazionale alla vittima.

Questi casi spingono i responsabili della sicurezza a ridefinire la superficie protetta. Modelli, prompt, istruzioni per gli agenti, credenziali API, quote cloud e strumenti di sviluppo si affiancano ora ad applicazioni e server convenzionali.

Ronald Lewis, responsabile della governance della cybersecurity di Black Duck, ha dichiarato a IT Pro che questi rischi stanno evolvendo più rapidamente di quanto molte organizzazioni riescano a misurare e governare. Ha sostenuto che i team di sicurezza debbano proteggere i sistemi AI mentre affrontano attaccanti che usano la stessa tecnologia.

Questo crea la competizione principale: un'offensiva alla velocità delle macchine contro organizzazioni i cui sistemi di risposta restano organizzati attorno a decisioni alla velocità umana.

Gli attaccanti con meno risorse possono ottenere una scala da Stato-nazione

L'AI restringe il divario nelle capacità operative, anche quando non elimina le differenze nell'accesso all'intelligence, nei finanziamenti o nella pazienza strategica.

I gruppi statali mantengono tradizionalmente vantaggi che il solo software non può riprodurre. Possono attingere a intelligence classificata, finanziamenti di lungo periodo, infrastrutture personalizzate, copertura diplomatica e team con conoscenze regionali specialistiche.

Tuttavia, molte caratteristiche visibili delle operazioni avanzate derivano da un'esecuzione ripetibile. Tra queste figurano ricognizione continuativa, phishing localizzato, modifica del codice, rotazione dell'infrastruttura e rapida risoluzione dei problemi.

L'AI può automatizzare o accelerare ciascuna di queste attività. Ciò offre ai gruppi più piccoli parte della portata operativa precedentemente associata a organizzazioni più grandi.

La campagna di credenziali di sei ore illustra questo meccanismo. L'attaccante non aveva bisogno di un agente per concepire un concetto di attacco senza precedenti.

Il framework ha invece coordinato attività note senza attendere un operatore umano in ogni fase. Il suo vantaggio derivava da persistenza, attività parallela e rapido recupero dagli errori di routine.

Questo modello cambia il modo in cui i difensori dovrebbero interpretare la sofisticazione. Un elevato volume di attacchi, esche curate o rapide modifiche al codice non dimostrano più che dietro un'operazione vi sia un grande team.

Un piccolo gruppo può riutilizzare istruzioni tra gli agenti. Può anche indirizzare modelli diversi verso ricognizione, programmazione, traduzione e analisi dei dati.

I gruppi collegati agli Stati stanno adottando lo stesso approccio. GTIG ha osservato un attore cinese dedito allo spionaggio sperimentare una pipeline automatizzata di sfruttamento e post-sfruttamento.

L'attore ha utilizzato CC Switch, uno strumento in grado di instradare il lavoro tra diversi modelli linguistici. Google afferma che ha interrogato Claude, Gemini e Codex per script di exploit, contenuti di phishing e assistenza nel debugging.

Il flusso di lavoro combinava il sondaggio manuale con Burp Suite e attività automatizzate tramite Phalanx, un framework open source per i test di penetrazione. Dopo aver ottenuto l'accesso, l'operatore poteva distribuire strumenti aggiuntivi per comando e controllo e raccolta delle credenziali.

Google ha inoltre descritto BASIN CASTLE, un gruppo collegato allo Stato cinese, mentre utilizzava l'AI generativa nelle successive fasi di attacco. Le sue attività includevano profilazione dei bersagli, creazione di esche localizzate, offuscamento del malware e risoluzione dei problemi post-sfruttamento.

CALANQUE ION, noto anche come APT42, ha usato l'AI per ricognizione, individuazione di email, traduzione e ingegneria sociale, secondo GTIG. L'attore collegato all'Iran ha inoltre studiato sviluppo dell'infrastruttura e reverse engineering del software.

RAVINE CASTLE, un altro gruppo collegato alla Cina, ha utilizzato Gemini per raccolta di intelligence, ricerca sugli exploit e operazioni di influenza. Google ha osservato il gruppo studiare metodi per anonimizzare le fughe di dati e distribuirle attraverso canali mediatici.

SANDWORM RELIC, collegato alla Russia, ha utilizzato Gemini per perfezionare script di password spraying e automatizzare la profilazione degli host. Ha inoltre esplorato l'instradamento tramite proxy progettato per nascondere l'infrastruttura di comando e controllo.

Cluster nordcoreani hanno utilizzato modelli per la profilazione dei bersagli, materiali di candidatura lavorativa fabbricati, esche tecniche e sviluppo di codice malevolo. Un cluster avrebbe registrato un gran numero di account di modelli attraverso identità dirottate.

Questi esempi mostrano come l'automazione delle minacce informatiche tramite AI si stia diffondendo tra attori con motivazioni molto diverse. I gruppi di spionaggio cercano intelligence, mentre i gruppi criminali perseguono estorsione, vendita di credenziali e furto di criptovalute.

La tecnologia non rende questi attori identici. Offre loro accesso a uno strato condiviso di automazione operativa.

Questa differenza è importante. Una portata di livello statale descrive scala e velocità di esecuzione, non un trasferimento completo delle capacità di intelligence statale ai criminali comuni.

La supply chain del software sta diventando una superficie di attacco per gli agenti

Gli aggressori stanno prendendo di mira le istruzioni e i segnali di fiducia usati dai sistemi di programmazione AI, non soltanto il software che tali sistemi producono.

GTIG ha collegato gran parte di questa attività a UNC6780, noto anche come TeamPCP. Da marzo 2026, il gruppo a movente finanziario ha preso di mira PyPI, npm e Docker Hub.

Questi servizi distribuiscono pacchetti utilizzati nei moderni progetti software. Un pacchetto compromesso può entrare in più organizzazioni attraverso installazioni di routine o build automatizzate.

Secondo quanto riportato, TeamPCP ha compromesso account legittimi di sviluppatori e pubblicato fork malevoli di server Model Context Protocol. MCP è uno standard che consente alle applicazioni AI di connettersi a strumenti e dati esterni.

Il gruppo ha inoltre iniettato codice malevolo in repository ufficiali di organizzazioni. Ciò conferiva alle risorse avvelenate l'aspetto di asset affidabili del progetto.

Un componente malevolo, DUSTMAKER, cercava token di identità negli ambienti di integrazione continua. Quei token potevano autorizzare la pubblicazione di pacchetti attraverso flussi di lavoro affidabili per gli sviluppatori.

Google afferma che i pacchetti compromessi potrebbero includere attestazioni SLSA Build Level 3 valide. SLSA è un framework per documentare e proteggere l'integrità delle build software.

Un'attestazione valida può convincere sistemi automatizzati che un pacchetto ha seguito un processo di build approvato. Tuttavia, non può rendere affidabile un'identità di pubblicazione rubata.

È qui che i sistemi di programmazione AI creano un rischio specifico. Gli agenti spesso valutano nomi dei pacchetti, metadati, contesto del repository e segnali di fiducia leggibili dalle macchine prima di raccomandare o installare una dipendenza.

Gli aggressori possono modellare questi segnali. Possono avvelenare i metadati, nascondere istruzioni nei file del progetto o sfruttare la propensione dell'agente a completare un'attività di sviluppo.

DUSTMAKER collocava contenuti malevoli all'interno di directory nascoste usate da strumenti di programmazione e ambienti di sviluppo. Gli esempi includevano le directory .claude, .vscode e .cursor.

I file in queste posizioni possono confondersi con la normale attività dello spazio di lavoro. Possono anche influenzare strumenti che analizzano automaticamente la configurazione del progetto.

Google ha rilevato configurazioni malevole progettate per attivare comandi durante normali interazioni degli sviluppatori. Uno sviluppatore potrebbe quindi attivare il malware semplicemente aprendo o lavorando all'interno di un progetto compromesso.

Il malware creava anche attività di pipeline con nomi plausibili legati all'AI. Un esempio utilizzava l'etichetta “Copilot Setup” mentre cercava ulteriori credenziali e chiavi di accesso.

Dopo l'esecuzione, il malware poteva eliminare i log del workflow. Ciò riduceva la probabilità che gli sviluppatori notassero attività sospette tramite l'interfaccia di un repository.

Un'altra tattica prendeva di mira gli scanner di sicurezza basati sull'AI. Gli aggressori incorporavano richieste estreme e vietate nei commenti sopra JavaScript malevolo.

L'obiettivo apparente era indurre i controlli di sicurezza a rifiutare l'analisi prima di raggiungere il malware effettivo. Si tratta di una prompt injection indiretta, in cui contenuti nascosti manipolano un sistema AI che esamina materiale non attendibile.

La strategia mette in luce un conflitto nello sviluppo automatizzato. I team vogliono che gli agenti di programmazione leggano un ampio contesto del progetto, eppure ogni file aggiuntivo diventa un possibile canale di istruzioni.

Gli scanner tradizionali trattano generalmente i commenti come testo non eseguibile. Uno scanner AI potrebbe trattare gli stessi commenti come istruzioni operative o contenuti sensibili alle policy.

Le scoperte sulla supply chain vanno quindi oltre il rilevamento di pacchetti malevoli. Le organizzazioni devono esaminare il modo in cui gli agenti scelgono le dipendenze, interpretano i file dello spazio di lavoro e approvano i comandi.

Gli sviluppatori hanno inoltre bisogno di visibilità sulle azioni eseguite per loro conto. Un agente che installa silenziosamente pacchetti o esegue script di configurazione può trasformare un errore di raccomandazione in una compromissione immediata.

La provenienza della conoscenza è importante in questo contesto. I team devono distinguere le istruzioni operative affidabili dal testo raccolto tramite repository, ticket, documentazione e pagine esterne.

Una base di conoscenza tecnica ricercabile può sostenere questa distinzione quando le regole di accesso e il contesto della fonte restano visibili. Non sostituisce la verifica dei pacchetti né l'isolamento in fase di esecuzione.

La lezione più ampia è che gli agenti AI ereditano le debolezze dei loro input. Trasformano inoltre alcuni input fuorvianti in azioni, aumentando il costo della fiducia mal riposta.

Le prove di Google sono serie, ma il divario di capacità non è scomparso

Il rapporto supporta una concreta tesi di accelerazione, ma non dimostra che ogni piccolo aggressore disponga ora di capacità complete da Stato-nazione.

GTIG dispone di una visibilità insolitamente ampia grazie al lavoro di risposta agli incidenti, al tracciamento delle minacce, all'infrastruttura cloud e al monitoraggio degli abusi di Gemini. Questo rende preziosi i suoi casi di studio.

Tuttavia, il rapporto presenta operazioni osservate selezionate, anziché una misurazione completa del comportamento degli aggressori a livello globale. Non fornisce una base di riferimento che mostri quale percentuale degli attacchi utilizzi agenti autonomi.

La campagna di sei ore è inoltre iniziata dopo che l'aggressore aveva compromesso un'infrastruttura cloud. L'accesso iniziale rimane un ostacolo significativo, anche quando gli agenti accelerano le fasi successive.

Allo stesso modo, “migliaia di credenziali” descrive la scala di raccolta della campagna, non il numero di account sfruttati con successo. Alcuni segreti potrebbero essere scaduti, limitati, duplicati o altrimenti inutilizzabili.

Le organizzazioni dovrebbero quindi evitare di considerare ogni script generato dall'AI come una minaccia persistente avanzata. L'attribuzione e la valutazione delle capacità richiedono ancora infrastruttura, vittimologia, malware, modelli operativi e intelligence umana.

Google stessa ha segnalato dei limiti. Nelle operazioni informative osservate durante il secondo trimestre, l'AI ha migliorato la produttività ma non ha creato capacità qualitativamente nuove.

Gli attori hanno utilizzato i modelli per generare contenuti, identità sintetiche, traduzioni e rifinitura delle narrazioni. Al momento della pubblicazione, GTIG non aveva osservato agenti interattivi sperimentali impiegati in operazioni di influenza dal vivo.

Questa conclusione complica le interpretazioni allarmistiche. L'AI sembra più efficace nell'automatizzare attività strutturate e ripetibili con feedback misurabili.

Le operazioni informatiche offrono esattamente queste condizioni. Uno scanner può stabilire se un host risponde, se le credenziali funzionano e se un comando non è riuscito.

Lo spionaggio a lungo termine richiede di più. Gli operatori devono comprendere le relazioni organizzative, selezionare intelligence strategicamente utile, evitare l'esposizione e interpretare risultati ambigui.

L'AI introduce anche rischi operativi per gli aggressori. I modelli possono allucinare codice, esporre infrastrutture, attivare il monitoraggio delle piattaforme o produrre schemi riconoscibili.

I fornitori commerciali possono disabilitare account e migliorare le protezioni dei modelli. Google afferma di aver interrotto asset associati e aggiornato i classificatori e il comportamento di rifiuto di Gemini dopo aver osservato gli abusi.

L'applicazione delle policy da parte dei fornitori ha tuttavia dei limiti. Gli aggressori possono alternare account fraudolenti, rubare credenziali legittime o passare a modelli ospitati localmente.

Anthropic ha osservato un modello di migrazione simile nelle operazioni di sorveglianza. I suoi ricercatori sulle minacce hanno dichiarato che alcuni attori sono passati a modelli aperti quando le protezioni commerciali creavano un attrito eccessivo.

Le scoperte sulla sorveglianza rafforzano inoltre l'osservazione più ampia di Google. I governi hanno usato l'AI per ridurre il fabbisogno di personale e aumentare il volume delle analisi, anche senza i più recenti sistemi di frontiera.

Ciò non rende irrilevanti i controlli di sicurezza. Il monitoraggio delle piattaforme crea opportunità di intelligence e ostacola gli operatori meno disciplinati.

Significa però che la chiusura degli account non può costituire l'ultimo livello difensivo. I workflow sottostanti possono sopravvivere quando gli aggressori conservano dati, istruzioni e capacità di calcolo alternative.

Google ricopre inoltre un doppio ruolo in questo dibattito. Sviluppa modelli ampiamente accessibili, mentre vende prodotti di sicurezza cloud, threat intelligence e difesa AI.

Questa posizione fornisce a Google telemetria utile, ma i lettori dovrebbero distinguere gli incidenti osservati dalle affermazioni sui prodotti. Le prove mostrano un'accelerazione senza stabilire che la difesa automatizzata neutralizzerà sistematicamente l'offensiva automatizzata.

La stessa cautela vale per l'estrazione dei modelli. Google ha segnalato campagne coordinate che superavano i 100 milioni di prompt contro capacità proprietarie.

L'azienda afferma di aver implementato controlli in tempo reale che riducono l'utilità di modelli studente non autorizzati. Le prove indipendenti sull'efficacia duratura di queste difese rimangono limitate.

Una lettura equilibrata evita due estremi. L'AI non si limita né ad aiutare gli aggressori a scrivere email migliori né trasforma ogni criminale in un servizio di intelligence.

Sta eliminando vincoli di lavoro e coordinamento da parti selezionate del ciclo di vita dell'attacco. Questo cambiamento da solo può sopraffare difese progettate per avversari più lenti.

Tre segnali mostreranno se i difensori riusciranno a tenere il passo

La prossima fase sarà decisa dalla velocità di contenimento, dalla governance degli agenti e dalla migrazione verso modelli controllati dagli aggressori.

Il primo segnale è il tempo tra l'esposizione delle credenziali e il contenimento automatizzato. Le organizzazioni dovrebbero misurare quanto rapidamente riescono a revocare segreti, isolare workload e bloccare sessioni sospette.

Questa metrica conta più del volume degli avvisi. Un attacco di sei ore diventa meno efficace quando rilevamenti ad alta confidenza attivano il contenimento in pochi minuti.

Diventa più pericoloso quando la risposta dipende da più team che si scambiano ticket. Incidenti ripetuti che coinvolgono credenziali utilizzabili rafforzerebbero l'avvertimento di Google sulle finestre difensive compresse.

Il secondo segnale è il modo in cui le piattaforme software proteggono le azioni degli agenti. Registri di pacchetti, host di codice, fornitori cloud e vendor di modelli necessitano di controlli che distinguano i suggerimenti generati dall'esecuzione autorizzata.

Misure utili includono autorizzazioni limitate per gli agenti, build isolate, blocco delle versioni delle dipendenze, release firmate e requisiti di approvazione per i comandi sensibili. Il logging deve inoltre conservare ciò che un agente ha letto e il motivo per cui ha agito.

Una grave compromissione di un registro causata da istruzioni AI avvelenate rafforzerebbe la tesi del rapporto sulla supply chain. Un'adozione più ampia di un efficace isolamento degli agenti ne indebolirebbe l'impatto previsto.

Il terzo segnale è lo spostamento degli aggressori dai servizi commerciali monitorati verso modelli locali e capacità di calcolo rubata. Questa migrazione riduce la visibilità disponibile per fornitori come Google e Anthropic.

GTIG ha già osservato UNC6508 eseguire un modello open-weight all'interno di infrastrutture compromesse. Una crescita continua di questa tattica renderebbe l'applicazione delle policy a livello di modello meno decisiva.

I difensori dovrebbero monitorare il provisioning inatteso di processori grafici, download insoliti di modelli, traffico di inferenza anomalo e credenziali di servizi AI appena create. Questi eventi possono indicare un furto di risorse prima che compaia un avviso di intrusione convenzionale.

Il precedente caso zero-day offre un parametro di riferimento correlato. Google ha affermato che dei criminali sembravano aver usato l'AI durante la scoperta e l'armamento di una falla di autenticazione precedentemente sconosciuta.

Se i casi confermati indipendentemente dovessero diventare abituali, il rischio andrebbe oltre lo sfruttamento più rapido di debolezze note. Gli aggressori otterrebbero una maggiore disponibilità di nuove opportunità.

Per ora, le prove più solide riguardano l'automazione e la scala. L'automazione delle minacce informatiche tramite AI aiuta gli attori a ripetere attività note, coordinare strumenti e recuperare più rapidamente dagli errori operativi.

Questo richiede comunque una postura di sicurezza diversa. Le organizzazioni dovrebbero inventariare ogni agente con accesso a codice, credenziali, contenuti esterni o sistemi di produzione.

Dovrebbero inoltre separare l'accesso al modello dall'autorità di esecuzione. Un assistente che può raccomandare un comando non necessita automaticamente dell'autorizzazione per eseguirlo.

I team possono iniziare verificando una domanda pratica: un account controllato da un agente può modificare la produzione, pubblicare un pacchetto o esporre segreti senza l’intervento di un secondo controllo?

La risposta rivela se l’automazione supporta i difensori o amplia silenziosamente il percorso degli attaccanti. Il report di Google AI sulle minacce informatiche chiarisce l’urgenza: questa valutazione deve rientrare nei piani di sicurezza attuali, non in una roadmap futura.