Agente AI basato su DeepSeek ha preso di mira più di 460 sistemi

DeepSeek è arrivato su Google News dopo che i ricercatori hanno rivelato una campagna assistita dall'AI che ha tentato attacchi contro oltre 460 bersagli. L'operazione ha prodotto danni confermati limitati, ma il suo flusso operativo ha oltrepassato una soglia importante. Un agente AI ha cercato sistemi vulnerabili, selezionato exploit, abbandonato opportunità poco promettenti e reindirizzato autonomamente le proprie azioni con scarso intervento umano.

Unit 42 di Palo Alto Networks ha attribuito l'attività a un operatore di lingua cinese che utilizzava gli alias knaithe e KnYuan. I ricercatori hanno valutato che l'individuo risiedesse a Zhuhai, in Cina. Hanno descritto l'attore come un operatore opportunistico di exploit, anziché come un gruppo sponsorizzato da uno Stato.

La campagna è rilevante perché DeepSeek non si limitava a rispondere a domande sull'hacking. Forniva il ragionamento all'interno di Hermes Agent, un framework open source con accesso al terminale, skill riutilizzabili e controllo basato su Telegram. Questa combinazione ha trasformato un modello linguistico in una componente operativa di un sistema di attacco.

Lo scenario più allarmante non si è pienamente concretizzato. Unit 42 ha rilevato che i tentativi autonomi contro sistemi Langflow e n8n sono falliti perché mancavano le configurazioni necessarie o l'autenticazione bloccava l'accesso. Il furto di dati confermato è derivato da uno sfruttamento manuale separato, mentre è stata osservata anche l'esecuzione di comandi su endpoint notebook esposti.

Questa distinzione ridimensiona il titolo, ma rafforza l'insegnamento. L'agente era inaffidabile, rumoroso e in grado di esporre il proprio operatore. Era però anche capace di svolgere attività di ricognizione e sfruttamento che in precedenza avrebbero richiesto un impegno manuale costante.

Il conflitto che ne deriva non è DeepSeek contro un singolo modello occidentale. È l'esecuzione permissionless degli agenti contro l'accesso AI controllato dai provider. L'operazione mostra come le protezioni dei modelli, le autorizzazioni dei framework, le infrastrutture esposte e il patching convenzionale ora si intersechino nella stessa catena di attacco.

Cosa omette il titolo di Google News

La campagna ha combinato esperimenti autonomi e attacchi manuali convenzionali, quindi non è stata una compromissione completamente automatizzata di centinaia di organizzazioni.

Il resoconto più chiaro proviene dall'indagine di Unit 42, pubblicata il 30 luglio 2026. I ricercatori hanno trovato un ambiente operativo collegato a knaithe e KnYuan. Il suo contenuto includeva configurazioni di modelli, script di exploit, liste di bersagli, cronologia della shell e log delle sessioni dell'agente.

Unit 42 ha affermato che l'attore ha tentato di sfruttare più di 460 bersagli usando tecniche sia autonome sia manuali. Tale totale non va interpretato come 460 intrusioni riuscite. I ricercatori hanno confermato l'esfiltrazione di dati da tre bersagli Citrix NetScaler e l'esecuzione di comandi su 11 endpoint notebook Marimo.

La sequenza autonoma ricostruita da una sessione del 7 maggio ha avuto un esito più circoscritto. L'operatore ha assegnato a Hermes Agent un compito iniziale tramite Telegram. I ricercatori hanno dichiarato di non essere riusciti a recuperare ulteriori input dell'operatore durante la sequenza registrata.

Hermes ha inizialmente preso di mira Langflow, una piattaforma per creare workflow AI. DeepSeek ha trovato codice di exploit pubblico, ha usato il motore di ricerca FOFA per enumerare 84 istanze esposte e ha eseguito uno scanner con 10 thread. Ha identificato un bersaglio apparentemente vulnerabile.

Il tentativo è fallito perché la vulnerabilità richiedeva un identificatore di flusso esposto oppure un'impostazione di accesso automatico abilitata. Il bersaglio non forniva nessuna delle due condizioni. DeepSeek ha quindi classificato il prodotto come un'opportunità poco promettente e ha cercato qualcosa con una maggiore superficie raggiungibile.

Questo cambio di rotta è l'evento centrale. L'automazione tradizionale esegue comandi predeterminati contro un elenco preparato. La combinazione Hermes e DeepSeek ha interpretato risultati falliti, ricercato altre vulnerabilità, confrontato bersagli e scelto un percorso diverso.

L'agente ha esaminato 10 famiglie di prodotti e ha cercato su GitHub codice proof-of-concept recente. Ha selezionato n8n dopo aver considerato gravità, numero di distribuzioni e l'apparente popolarità del codice di exploit disponibile.

Unit 42 ha riferito che FOFA ha restituito 647.017 istanze n8n a livello globale, incluse 25.209 in Cina. Queste cifre provenivano dall'ambiente di ricognizione dell'attore, non da un conteggio verificato delle installazioni vulnerabili. Un'istanza esposta non era necessariamente interessata o sfruttabile.

DeepSeek ha analizzato una catena di exploit a due vulnerabilità e identificato tre sistemi che eseguivano versioni apparentemente vulnerabili. Tuttavia, l'exploit disponibile richiedeva un modulo non autenticato con upload di file abilitato. I moduli individuati richiedevano l'autenticazione.

L'agente ha continuato a scansionare oltre 50 bersagli rimanenti, ma non ha trovato un modulo pubblico utilizzabile. Unit 42 non ha rilevato alcuno sfruttamento riuscito nella sequenza autonoma relativa a n8n.

Questo esito fallito è importante. L'operazione non ha rivelato un sistema AI capace di inventare una vulnerabilità zero-day o di aggirare difese rafforzate. Ha mostrato un agente che assembla informazioni pubbliche e applica tecniche note alla velocità di una macchina.

Il lato manuale ha ottenuto un impatto maggiore. L'attore ha sfruttato una falla di lettura oltre i limiti della memoria in NetScaler per ottenere dati da tre bersagli. Unit 42 ha inoltre rilevato l'esecuzione di comandi su 11 endpoint notebook Marimo e tentativi che coinvolgevano servizi Tomcat e Windows IKE.

La vulnerabilità NetScaler, tracciata come CVE-2026-3055, ha ricevuto un punteggio CVSS di 9,8 dal NIST. Riguardava una convalida insufficiente dell'input quando i sistemi interessati operavano come provider di identità SAML. CISA l'ha aggiunta al proprio catalogo Known Exploited Vulnerabilities il 30 marzo.

Unit 42 ha affermato che l'attore ha cercato cookie di autenticazione nella memoria NetScaler sottratta, indicando un interesse per il dirottamento delle sessioni. Un'organizzazione governativa malese ha ricevuto un'attenzione persistente per diversi giorni, incluse regolazioni dei parametri della memoria e connessioni successive tramite proxy di anonimizzazione.

Questi dettagli mostrano un operatore che applicava giudizio dove l'agente AI restava inefficace. La campagna era quindi ibrida. L'automazione ha ampliato la ricognizione e la sperimentazione, mentre l'umano ha gestito lo sfruttamento e la persistenza di maggior valore.

L'automazione degli agenti AI DeepSeek cambia l'economia degli attacchi

Il valore dell'agente non era un tasso di successo più elevato. Era la capacità di comprimere ricerca ripetitiva, filtraggio e ridefinizione dei bersagli in un processo riutilizzabile.

Hermes Agent forniva il livello operativo. Dava a DeepSeek accesso al terminale, un sistema di skill, controllo tramite Telegram e connessioni a strumenti esterni. DeepSeek forniva il ragionamento per la generazione di codice, la valutazione delle vulnerabilità, la selezione dei bersagli e le decisioni sui passaggi successivi.

L'attore ha aggiunto tre skill offensive. Una supportava il jailbreaking dei modelli, un'altra riguardava lo sfruttamento di WebSocket e una terza convertiva le istruzioni in ricerche FOFA. L'ambiente era inoltre collegato a un server Model Context Protocol che esponeva funzioni di individuazione degli asset e scansione delle vulnerabilità.

Model Context Protocol, o MCP, è uno standard che permette a un sistema AI di chiamare fonti dati e strumenti esterni. In questa campagna, ha contribuito a collegare istruzioni in linguaggio naturale a ricerche di asset su Internet e alla generazione di scanner. Il modello poteva passare dal decidere cosa trovare all'esecuzione delle ricerche necessarie per trovarlo.

Questa architettura separa la cognizione dall'azione. Un modello linguistico valuta i risultati e propone passaggi. Il framework dell'agente esegue comandi, conserva lo stato e restituisce osservazioni. Le skill preservano procedure riutilizzabili nelle sessioni successive.

Questa separazione spiega perché il solo modello non rappresenta l'intero rischio. DeepSeek non poteva scansionare un indirizzo o eseguire un exploit senza un ambiente di esecuzione. Hermes trasformava le decisioni generate in attività del sistema operativo.

Il workflow gestiva anche le risorse. Unit 42 ha dichiarato che DeepSeek ha campionato circa 100 indirizzi delle 25.209 istanze n8n cinesi riportate da FOFA. Ha poi sondato circa 40 indirizzi unici invece di testare l'intera raccolta.

Questo comportamento suggerisce che il sistema stesse bilanciando la copertura dei bersagli con i costi di calcolo ed esecuzione. Ha cercato su larga scala, ristretto il campo, testato le versioni e si è fermato quando le condizioni richieste non erano disponibili. Assomiglia al processo di triage di un analista, anche se i giudizi sottostanti erano imperfetti.

L'operatore gestiva inoltre 1DayNews, una pipeline automatizzata di intelligence sulle vulnerabilità. Secondo Unit 42, raccoglieva segnalazioni di esecuzione di codice remoto da 17 fonti, usava DeepSeek per filtrare le scoperte in base alla sfruttabilità e distribuiva gli avvisi tramite Telegram.

Questa pipeline aiuta a spiegare perché la campagna apparisse opportunistica. L'attore poteva assimilare nuove divulgazioni di vulnerabilità, dare priorità ai prodotti esposti, acquisire codice pubblico e iniziare i test senza concentrarsi su una singola vittima o settore.

L'approccio mette sotto pressione i difensori perché il loro tempo per applicare le patch inizia già quando una divulgazione diventa pubblica. Un agente riduce il lavoro tra divulgazione, individuazione del bersaglio e tentativo di sfruttamento. Non deve migliorare un exploit se può trovare altrove una configurazione vulnerabile.

Palo Alto Networks aveva già testato un'automazione di attacco simile in condizioni controllate. Il suo framework di attacco agentico del 2025 ha simulato una sequenza ransomware, dalla compromissione iniziale al furto di dati, in 25 minuti.

L'azienda ha descritto quel risultato di laboratorio come un aumento della velocità di 100 volte. Ha inoltre riferito che il tempo medio dalla compromissione all'esfiltrazione è sceso da nove giorni nel 2021 a due giorni nel 2024. In un quinto dei casi investigati, l'esfiltrazione è iniziata entro un'ora.

Queste cifre non dimostrano che la campagna DeepSeek abbia operato alla stessa velocità. Stabiliscono perché il triage autonomo preoccupi i team di risposta agli incidenti. Un processo difensivo misurato in cicli settimanali di patching affronta un attaccante in grado di rivalutare i bersagli nell'arco di una singola sessione.

La campagna attuale ha comunque incontrato ostacoli di base. L'autenticazione ha fermato la catena di exploit n8n. Un'impostazione Langflow mancante ha bloccato il primo tentativo. Molti sistemi scansionati non hanno risposto.

Questo esito rafforza un punto meno eclatante: configurazione e controlli di accesso contano ancora. Un agente può cercare, adattarsi e riprovare, ma non può eliminare automaticamente ogni prerequisito incorporato in un exploit.

Ciononostante, l'economia è cambiata. Un basso tasso di successo può restare utile quando l'individuazione dei bersagli e i test iniziali diventano economici. Gli attaccanti non hanno più bisogno che ogni tentativo riesca se un agente può svolgere continuamente il lavoro scartato.

Gli agenti permissionless mettono sotto pressione le protezioni dei provider

Il confronto principale è tra ambienti di esecuzione senza restrizioni e servizi AI che applicano policy al confine del provider.

L'operatore ha valutato diversi sistemi di modelli e di coding. Unit 42 ha trovato configurazioni che coinvolgevano Qwen, GLM, Kimi, MiniMax, Claude Code, Codex e DeepSeek. I rispettivi ruoli e le prove disponibili differivano sostanzialmente.

DeepSeek operava come motore di ragionamento principale all'interno di Hermes Agent. Qwen Code è apparso in sole due sessioni recuperate. L'attività di Claude Code consisteva in 10 voci distribuite su tre sessioni, principalmente controlli dei modelli, convalida dei proxy e test di connettività.

I ricercatori hanno trovato indicazioni che Codex avesse accesso a directory di sviluppo degli exploit, ma non ne hanno recuperato le conversazioni. L'attore aveva disabilitato l'archiviazione locale delle risposte, impedendo a Unit 42 di verificare come fosse stato usato Codex.

Quell’assenza di prove è importante. La presenza di una configurazione dello strumento non dimostra che lo strumento abbia generato un exploit o partecipato a un attacco riuscito. Unit 42 ha correttamente descritto il collegamento con Codex come un’indicazione, non come un ruolo operativo confermato.

L’attore ha instradato gli strumenti occidentali attraverso un proxy di terze parti. DeepSeek e Qwen si sono connessi direttamente alle rispettive API native. Le configurazioni hanno inoltre rimosso o ridotto, dove possibile, le richieste di autorizzazione lato client.

Le autorizzazioni lato client determinano se un agente di coding possa eseguire comandi, modificare file o accedere alla rete senza approvazioni ripetute. Non rimuovono i controlli del provider sui contenuti e sugli abusi lato server.

Unit 42 ha dichiarato che OpenAI ha esaminato i segnali correlati e confermato che le sue protezioni hanno rifiutato richieste in violazione delle policy. I tentativi continuati hanno portato i suoi sistemi a segnalare e disabilitare un account ritenuto collegato alla campagna prima che Unit 42 condividesse la propria intelligence.

Questo è un raro esempio sul campo in cui i controlli di un provider avrebbero modificato le opzioni disponibili a un attaccante. I controlli non hanno fermato la campagna più ampia, perché l’operatore poteva cambiare modelli e framework. Hanno comunque introdotto attrito e rimosso un account.

Hermes ha presentato un confine diverso. Unit 42 ha descritto il framework come privo di un livello di sicurezza integrato nella configurazione osservata. Includeva inoltre una skill opzionale pensata per aggirare i rifiuti dei modelli.

Ciò non significa che gli agenti open source siano intrinsecamente dannosi. Lo stesso accesso al terminale e le skill riutilizzabili supportano attività legittime di ricerca, amministrazione di sistema e sviluppo software. Il rischio emerge quando ampie autorizzazioni di esecuzione incontrano un obiettivo offensivo.

Il compromesso fondamentale è tra controllo e portabilità. Un servizio ospitato può esaminare le richieste, rilevare violazioni ripetute e sospendere l’accesso. Un framework autogestito offre agli utenti più libertà, ma trasferisce l’applicazione delle regole all’operatore e all’infrastruttura circostante.

Gli attaccanti scelgono prevedibilmente il percorso con meno restrizioni. Unit 42 ha valutato che i controlli lato provider abbiano probabilmente reso i sistemi occidentali meno efficaci per questa campagna. L’attore si è quindi affidato a DeepSeek attraverso un framework con vincoli lato client minimi.

Tuttavia, attribuire l’operazione interamente a DeepSeek semplificherebbe eccessivamente le prove. L’attore ha fornito gli obiettivi, selezionato gli strumenti, installato le skill, collegato FOFA e fornito accesso al terminale. Codice pubblico sulle vulnerabilità e sistemi esposti hanno completato la catena.

Il ruolo di DeepSeek è rimasto rilevante perché ha gestito selezione e adattamento. Eppure un altro modello capace, collocato nello stesso ambiente permissivo, potrebbe svolgere compiti simili. La combinazione architetturale conta più del solo nome del marchio.

Questo pone un difficile problema di policy. I provider di modelli possono filtrare le richieste dirette, ma i modelli aperti e le API alternative riducono la portata dei controlli centralizzati. I framework per agenti possono aggiungere passaggi di approvazione, anche se spesso gli utenti possono disabilitarli.

I team di sicurezza non possono quindi trattare le policy di sicurezza dei fornitori come la loro difesa primaria. Tali policy possono interrompere gli abusi a un livello. Non possono correggere un appliance esposto, imporre l’autenticazione su un modulo di workflow o impedire a un agente non gestito di ricevere privilegi di terminale.

L’inquadramento di Google News rende DeepSeek il soggetto riconoscibile. La sfida più profonda riguarda chi controlla l’esecuzione e dove tale controllo possa essere applicato. I modelli generano decisioni, i framework concedono capacità e l’infrastruttura determina se un exploit tentato funziona.

Anche l’attaccante IA ha esposto sé stesso

La stessa autonomia che ha ampliato la portata dell’operatore ha creato un grave fallimento della sicurezza operativa e ha offerto ai ricercatori una visione insolita dall’interno della campagna.

Hermes Agent ha ricevuto una richiesta via Telegram e ha avviato un server HTTP Python sulla porta 8888. Ha avviato quel server dalla directory home dell’attore invece di utilizzare una cartella di staging isolata.

Quell’errore ha esposto l’intero spazio di lavoro. Unit 42 ha potuto ispezionare chiavi API, file di configurazione, script di exploit, elenchi di target, cronologia dei comandi e log di sfruttamento dell’agente. Questi artefatti hanno costituito la base della ricostruzione pubblicata.

L’errore è più di un’inversione ironica. L’esecuzione autonoma aumenta il numero di decisioni rilevanti prese senza che un umano esamini ogni comando. Un passaggio apparentemente ordinario di condivisione file può esporre credenziali e cronologia operativa.

Anche gli attaccanti umani commettono errori. Configurano male i server, riutilizzano l’infrastruttura e lasciano log alle spalle. Un agente aggiunge un’altra fonte di errori perché può fraintendere percorsi, autorizzazioni, ambito o le conseguenze di un comando.

L’attore ha dimostrato consapevolezza della sicurezza operativa altrove. Le directory degli exploit erano state svuotate dopo l’uso. L’archiviazione locale delle risposte di Codex era stata disabilitata. L’infrastruttura proxy riduceva l’attribuzione diretta per alcuni strumenti.

L’agente ha vanificato parte di quel lavoro con un comando delimitato male. Ha creato prove forensi che un operatore manuale più cauto avrebbe potuto evitare.

Questa inversione ha inoltre aiutato i ricercatori a separare le azioni automatizzate da quelle manuali. La sessione Hermes recuperata mostrava il tentativo Langflow fallito, la ricerca autonoma di vulnerabilità e il passaggio a n8n. Altri file documentavano lo sfruttamento al di fuori di quella sessione.

Senza quei log, gli osservatori avrebbero potuto vedere traffico di scansione senza sapere se un modello IA avesse selezionato i target. Le affermazioni di marketing sull’hacking autonomo sarebbero state difficili da verificare. L’ambiente esposto ha fornito prove insolitamente dirette.

Anche queste prove hanno dei limiti. Unit 42 non possedeva ogni file eliminato né ogni sessione. Ha esaminato segnali di sfruttamento in batch contro un numero sconosciuto di host contenuti in un file che l’attore aveva rimosso.

I ricercatori non hanno inoltre potuto confermare le conversazioni effettive con Codex. Non hanno affermato che ogni target tentato abbia ricevuto un exploit autonomo. Il loro impatto confermato combinava diversi metodi e vulnerabilità differenti.

Queste precisazioni impediscono che la storia si trasformi in un’affermazione su un hacker IA inarrestabile. L’agente registrato ha svolto ricerca e adattamento utili, ma non è riuscito a compromettere i target autonomi previsti. Il suo maggiore successo potrebbe essere stato accelerare la ricerca dell’operatore.

La campagna ha coinvolto anche vulnerabilità note e codice proof-of-concept pubblico. Nel report non vi sono prove che DeepSeek abbia scoperto una vulnerabilità sconosciuta. Non vi sono prove che abbia sviluppato autonomamente da zero un exploit nuovo.

Le valutazioni del sistema erano talvolta superficiali. Ha trattato le stelle GitHub assegnate al codice proof-of-concept come un indicatore del valore di un exploit. La popolarità può riflettere l’attenzione senza dimostrare affidabilità o ampia esposizione.

Anche i conteggi dei prodotti provenivano da una piattaforma di ricerca su Internet. I risultati di ricerca possono essere obsoleti, duplicati o incompleti. Un banner di servizio non conferma una versione esatta, una funzionalità raggiungibile o una configurazione sfruttabile.

L’agente ha comunque corretto la rotta quando le prove contraddicevano un’ipotesi. Ha riconosciuto i prerequisiti Langflow mancanti. Ha riletto i requisiti dell’exploit n8n e notato che l’autenticazione bloccava i moduli disponibili.

Questo comportamento è sufficiente a preoccupare i difensori. L’agente non aveva bisogno di un ragionamento perfetto per ridurre il carico di lavoro manuale. Doveva respingere target palesemente inadatti e preservare l’attenzione dell’operatore per opportunità migliori.

La campagna presenta quindi due verità simultanee. Gli attuali agenti offensivi restano inclini agli errori e goffi sul piano operativo. I loro errori non eliminano l’efficienza ottenuta da una ricognizione automatizzata persistente.

I difensori possono sfruttare questa debolezza. Le campagne autonome generano query ripetitive, sonde ad alta velocità, download di strumenti e picchi di esecuzione. Correlare tali comportamenti tra telemetria di identità, endpoint, rete e cloud può esporre il workflow.

Le organizzazioni dovrebbero inoltre isolare i propri agenti IA. Un ampio accesso al terminale non dovrebbe implicare accesso a directory di credenziali o a servizi di rete senza restrizioni. I comandi che espongono file, aprono listener o modificano controlli di sicurezza meritano un’ulteriore approvazione.

I log degli agenti diventano prove di sicurezza. I team che usano agenti di coding o operazioni dovrebbero conservare chiamate agli strumenti, modifiche alle autorizzazioni, selezioni di modelli e destinazioni di rete. Una base di conoscenza IA personale può supportare il lavoro legittimo, ma i segreti operativi richiedono confini di accesso e controlli di conservazione.

L’esposizione dell’attaccante dimostra perché la sicurezza degli agenti non riguarda solo il blocco dei prompt dannosi. Riguarda anche la limitazione dei danni causati da un agente che esegue in modo errato un’istruzione valida.

Cosa dovrebbero monitorare i difensori dopo questo report su DeepSeek

La fase successiva sarà misurata da compromissioni autonome riuscite, infrastrutture offensive ripetibili e controlli difensivi in grado di riconoscere il comportamento degli agenti.

Il primo segnale è la prova che un agente completi una compromissione senza che un umano prenda il controllo. Unit 42 ha documentato enumerazione autonoma, acquisizione di exploit, selezione dei target e tentativi di sfruttamento falliti. L’attività riuscita confermata nel suo report proveniva da campagne manuali.

Questo confine è importante. Se una futura indagine registrerà accesso iniziale autonomo, escalation dei privilegi, persistenza e furto di dati in un’unica sequenza tracciabile, la valutazione del rischio cambierà. Dimostrerebbe che gli agenti possono andare oltre il triage dei target e passare a operazioni affidabili.

I lettori dovrebbero cercare log di sessione, cronologie dei comandi, telemetria di rete o altre prove dirette. Le sole descrizioni dei fornitori non possono dimostrare l’autonomia. Una campagna che usa semplicemente codice generato dall’IA è diversa da una che ripianifica dopo un fallimento ed esegue la scelta successiva.

Il secondo segnale è la ripetizione tra attori indipendenti. Questo operatore ha costruito infrastrutture riutilizzabili attraverso skill personalizzate, controllo Telegram, integrazione FOFA, proxy e una pipeline di avvisi sulle vulnerabilità. Tale investimento suggerisce l’intenzione di perfezionare il processo.

Una sola campagna non stabilisce una transizione ampia. Più attori non correlati che usano architetture di agenti simili dimostrerebbero che il metodo sta diventando una pratica standard anziché l’esperimento di un singolo operatore.

La ripetibilità apparirà probabilmente attraverso skill condivise, server MCP pacchettizzati, framework per agenti modificati e workflow di selezione degli exploit. I ricercatori difensivi dovrebbero monitorare i repository pubblici senza presumere che ogni progetto di red team sia dannoso.

Il terzo segnale è se provider e imprese avvicineranno l’applicazione delle regole agli strumenti. I rifiuti dei modelli hanno creato attrito in questo caso, ma non hanno impedito all’operatore di cambiare sistema. Anche le richieste di approvazione non hanno funzionato come confine duraturo, perché l’attore le ha disabilitate.

Controlli più significativi valuterebbero l’azione richiesta, l’autorizzazione del target, il contesto del processo e la destinazione di rete. Un agente che richiede documentazione pubblica è diverso da uno che avvia uno scanner contro host Internet non correlati.

Le imprese dovrebbero inventariare gli agenti distribuiti e le credenziali a loro disponibili. Un agente non gestito con accesso alla shell può creare una nuova esposizione anche quando il suo modello sottostante si comporta come previsto.

I sistemi esposti a Internet restano la priorità immediata. L’autenticazione ha bloccato il tentativo autonomo su n8n, mentre requisiti di configurazione mancanti hanno fermato lo sfruttamento di Langflow. Sono vittorie difensive convenzionali contro un workflow non convenzionale.

Anche il trattamento di CISA per CVE-2026-3055 mostra perché la velocità di patching è importante. L’agenzia ha aggiunto la falla al proprio catalogo delle vulnerabilità sfruttate sette giorni dopo la sua pubblicazione del 23 marzo e ha fissato al 2 aprile la scadenza per la correzione da parte delle agenzie federali.

Le organizzazioni dovrebbero ridurre i servizi di gestione raggiungibili dall’esterno, verificare le versioni aggiornate e monitorare eventuali sonde ripetute sulle versioni. Dovrebbero inoltre riesaminare le piattaforme di workflow distribuite rapidamente per sperimentazione e poi lasciate online.

I team di sicurezza dovrebbero aspettarsi che il traffico degli attacchi cambi forma. Un agente può fermarsi, fare ricerche e tornare con un exploit diverso invece di ripetere lo stesso payload. Le regole di rilevamento legate a un singolo indicatore potrebbero non cogliere questa sequenza più ampia.

Correlare la fase di scoperta con lo sfruttamento successivo offre una visione migliore. Un picco di enumerazione dei prodotti seguito da controlli delle versioni, download di exploit pubblici e richieste mirate può rivelare attività guidate da un agente, anche quando ogni azione appare ordinaria.

Il ciclo di Google News favorirà l’espressione “attacco informatico autonomo”, ma per i difensori servono domande più circoscritte. Quali passaggi erano autonomi? Quali azioni sono riuscite? Di quali autorizzazioni disponeva l’agente? Quale controllo lo ha infine fermato?

Queste domande evitano reazioni eccessive senza ridurre l’urgenza. Questa campagna non era né automazione innocua né un aggressore digitale pienamente indipendente. Era un sistema offensivo funzionale la cui componente autonoma ha fallito contro semplici barriere, per poi esporre il proprio operatore.

È un segnale d’allarme precoce, non una trasformazione già compiuta. I prossimi uno-tre mesi dovrebbero chiarire se altri ricercatori individueranno sistemi simili, se i framework restringeranno le autorizzazioni degli strumenti e se gli attaccanti miglioreranno la disciplina operativa.

Per i responsabili della sicurezza, l’azione è diretta: accorciare il percorso dalla divulgazione di una vulnerabilità alla correzione, mappare ogni servizio esposto a Internet e trattare l’esecuzione degli agenti come automazione privilegiata. Per gli sviluppatori, è necessario imporre approvazioni per la scansione di rete, l’accesso alle credenziali e i listener pubblici.

Continuate a seguire la ricerca di sicurezza verificata dietro i titoli di Google News, ma distinguete tra attacchi tentati e compromissioni confermate. La metrica cruciale non è più se un attaccante abbia consultato un modello di IA. È se l’agente abbia selezionato, eseguito e completato autonomamente azioni che hanno modificato l’ambiente di una vittima.