Hugging Face violata da un agente AI: perché il primo attacco autonomo segna una svolta per la cybersecurity


Per anni l’idea di un attacco informatico condotto interamente da un agente di Intelligenza Artificiale è rimasta confinata ai laboratori di ricerca e alle presentazioni dei vendor. Oggi non è più così. La piattaforma Hugging Face, punto di riferimento mondiale per lo sviluppo e la distribuzione di modelli AI open source, ha confermato di essere stata colpita da quello che descrive come un attacco condotto dall’inizio alla fine da un sistema autonomo di agenti AI.  L’episodio rappresenta molto più di una violazione informatica: è probabilmente il primo caso documentato in cui un’infrastruttura di produzione di una realtà di una certa rilevanza viene compromessa da un sistema capace di pianificare ed eseguire autonomamente una campagna offensiva complessa, senza che un operatore umano debba guidarne ogni fase.

L’attacco è partito dalla supply chain dei dati

Secondo quanto comunicato da Hugging Face, gli aggressori hanno sfruttato una superficie d’attacco peculiare delle piattaforme AI: la pipeline che elabora dataset caricati dagli utenti. Un dataset malevolo ha abusato di due percorsi di esecuzione del codice, un loader che consentiva l’esecuzione di codice remoto e una vulnerabilità di template injection nella configurazione del dataset, ottenendo l’esecuzione di codice su un nodo di elaborazione.  Da quel momento il comportamento dell’attaccante è stato quello tipico di un’Advanced Persistent Threat: escalation dei privilegi, raccolta di credenziali cloud e di cluster, movimento laterale tra diversi sistemi e accesso non autorizzato a dataset interni e credenziali di servizio. Hugging Face precisa di non aver trovato evidenze di manomissioni ai modelli pubblici, ai dataset disponibili agli utenti, agli Spaces o alla propria software supply chain, ma l’incidente dimostra quanto le piattaforme AI introducano superfici di attacco nuove rispetto alle applicazioni tradizionali.

La novità non è la vulnerabilità, ma chi ha guidato l’attacco

La vulnerabilità sfruttata non rappresenta l’aspetto più innovativo dell’incidente. Ciò che cambia realmente è il modo in cui è stata sfruttata. Secondo la ricostruzione dell’azienda, l’operazione è stata eseguita da un framework agentico capace di svolgere decine di migliaia di azioni distribuite su una moltitudine di ambienti temporanei, con infrastrutture di comando e controllo che migravano automaticamente tra servizi pubblici per ridurre la probabilità di essere individuate.

In pratica, l’AI non si è limitata a generare codice o suggerire una sequenza di exploit: ha eseguito autonomamente una campagna offensiva articolata, adattandosi durante le diverse fasi dell’intrusione. È lo scenario dell’agentic attacker di cui il settore della cybersecurity discute da tempo e che oggi sembra essersi concretizzato.

L’AI ha difeso Hugging Face da un’altra AI

L’altro elemento interessante dell’incidente è che anche la risposta è stata in larga parte automatizzata. Hugging Face spiega di aver utilizzato sistemi basati su LLM per analizzare la telemetria di sicurezza, correlare gli eventi e ricostruire rapidamente la cronologia dell’attacco. Gli agenti di analisi hanno elaborato oltre 17.000 eventi, permettendo ai team di incident response di individuare gli indicatori di compromissione e distinguere le attività realmente dannose da quelle create per depistare gli analisti. Secondo l’azienda, un’attività che normalmente richiederebbe diversi giorni è stata completata in poche ore grazie all’automazione. Il risultato è un assaggio di quello che potrebbe diventare il nuovo paradigma della cybersecurity: AI contro AI, con attaccanti e difensori che operano entrambi a velocità macchina.

Il problema tanto temuto dei guardrail ciechi

Tra gli aspetti più curiosi emersi dal post mortem c’è un problema che fino a poco tempo fa sarebbe sembrato marginale. Durante l’analisi forense, Hugging Face ha inizialmente provato a utilizzare modelli commerciali accessibili tramite API. Tuttavia, le richieste contenevano exploit, payload, comandi di attacco e indicatori di compromissione reali: elementi che i sistemi di sicurezza dei modelli hanno interpretato come contenuti pericolosi, bloccandone l’elaborazione.

Per completare l’analisi, l’azienda ha quindi utilizzato un modello open-weight eseguito sulla propria infrastruttura, evitando sia le limitazioni imposte dai guardrail sia il trasferimento all’esterno di dati sensibili e credenziali compromesse. Questo ci riporta a un tema che è stato affrontato più volte dall’arrivo degli LLM al grande pubblico: è giusto limitarne le capacità quando gli unici che ne fanno davvero le spese sono gli utenti che li usano per scopi leciti? Ovviamente, la risposta è lunga e articolata, ma sembra abbastanza ovvio che qualcosa debba esser ripensato, a partire dalla disponibilità di servizi AI deputati all’analisi forense e al blue teaming.

Le piattaforme AI diventano una nuova superficie di attacco

L’attacco ad HuggingFace ci dice molte cose. Innanzitutto, la scelta del bersaglio è quantomeno curiosa e ovviamente tesa a dimostrare che con l’IA non si scherza. Secondo il mio modesto parere, questo attacco è stato un atto dimostrativo per mettere in guardia un’industria che è ancora largamente indecisa se correre a più non posso o imparare qualcuna delle dure lezioni che il cybercrimine ha impartito negli anni passati. Inoltre, sottolinea che la diffusione degli agenti AI amplia la superficie di attacco ben oltre il già tartassato modello linguistico, ma comprende dataset, memoria dell’agente, strumenti esterni, protocolli come MCP, supply chain delle estensioni e contesto operativo. Le minacce si spostano sempre più dal codice ai dati e alle interazioni runtime, rendendo necessari approcci di sicurezza che trattino ogni elemento esterno come potenzialmente non affidabile. Questo significa che la protezione delle piattaforme AI deve (sì, già oggi) estendersi ben oltre i tradizionali controlli su endpoint e reti, includendo controlli specifici sulla provenienza dei dati, sull’esecuzione degli strumenti e sulle informazioni che alimentano gli agenti.

Una nuova fase per la cybersecurity che potremmo non esser pronti ad affrontare

Il caso Hugging Face non dimostra che gli attaccanti abbiano improvvisamente acquisito capacità “sovrumane”. Dimostra però che l’automazione sta riducendo drasticamente il costo operativo degli attacchi e che fare automazione complessa oggi diventa sempre più semplice. Un sistema autonomo può eseguire migliaia di tentativi, adattare continuamente la propria strategia, sfruttare nuove opportunità e operare ventiquattro ore su ventiquattro senza la supervisione costante di un essere umano. Per le organizzazioni significa che i tempi di reazione disponibili continueranno a ridursi. Se gli attacchi si muovono a velocità macchina, anche il rilevamento, la correlazione degli eventi e la risposta dovranno essere sempre più automatizzati. Nik Zur (CTO di  Palo Alto) lo dice da tempo (ed era il suo slogan nel lancio di una serie di prodotti di qualche tempo fa), ma la massima continua a restare valida. Solo a marzo ho parlato con il capo dei laboratori di Mandiant che mi diceva che “ancora non accade, ma accadrà in futuro”. Il futuro è arrivato dopo neanche 4 mesi… Il problema più grande della sicurezza (e di tutta la società umana) è riuscire a tenere il passo dell’evoluzione… e non sarà facile.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/07/21/hugging-face-violata-da-un-agente-ai-perche-il-primo-attacco-autonomo-segna-una-svolta-per-la-cybersecurity/?utm_source=rss&utm_medium=rss&utm_campaign=hugging-face-violata-da-un-agente-ai-perche-il-primo-attacco-autonomo-segna-una-svolta-per-la-cybersecurity




Gli assistenti AI di coding sono sicuri? Il caso xAI


Gli strumenti di AI per lo sviluppo software promettono di aumentare la produttività degli sviluppatori, ma una recente analisi indipendente riaccende il dibattito sulla sicurezza dei dati affidati agli assistenti di coding. Al centro della vicenda c’è Grok Build, il tool a riga di comando di xAI, accusato di aver trasmesso (in chiaro) ai server dell’azienda interi repository Git, cronologia compresa, insieme a file contenenti credenziali e altri dati sensibili. Secondo il ricercatore che ha condotto l’analisi, inoltre, il comportamento sarebbe avvenuto anche dopo aver attivato l’opzione di esclusione dall’addestramento del modello.

Un’analisi del traffico di rete fa emergere il problema

La vicenda nasce dall’analisi del traffico di rete effettuata dal ricercatore noto come cereblab, che ha instradato Grok Build attraverso mitmproxy per osservare nel dettaglio le comunicazioni tra il client e i server remoti. L’obiettivo era verificare quali dati venissero realmente inviati durante una normale sessione di sviluppo. I risultati non sono stati quelli sperati. Secondo il report, il software avrebbe aperto due canali distinti di comunicazione: uno destinato alle richieste del modello AI e un secondo utilizzato per il caricamento del codice (un comportamento decisamente non atteso e che ha allarmato il ricercatore).

Nel test effettuato su un repository Git di circa 12 GB, il traffico destinato al modello AI sarebbe stato limitato a circa 192 KB, mentre il canale di storage avrebbe trasferito 5,10 GiB di dati suddivisi in 73 blocchi da circa 75 MB ciascuno. Il rapporto tra i due flussi supera le 27.800 volte, un valore incompatibile con il semplice invio del contesto necessario alla conversazione con il modello e che di solito giustifica connessioni parallele. L’analisi sostiene inoltre che il contenuto inviato corrispondesse a un bundle Git completo, comprendente non solo i file correnti ma anche la cronologia del repository.

Anche i segreti sarebbero finiti nel trasferimento

Ancora più delicata è la parte relativa ai secret presenti nel progetto. Durante il test il ricercatore ha inserito volutamente un file .env contenente chiavi API e credenziali fittizie facilmente identificabili. Secondo quanto documentato, tali informazioni sarebbero state trasmesse integralmente durante la comunicazione con i server di xAI. Inoltre, ricostruendo il bundle Git catturato durante il trasferimento, il ricercatore afferma di aver recuperato anche un file che l’agente era stato esplicitamente istruito a non leggere, suggerendo che il caricamento del repository fosse indipendente dalle operazioni realmente effettuate dal modello.

Uno degli aspetti più controversi, secondo cerelab, riguarda l’impostazione “Improve the model”, utilizzata per escludere i propri dati dall’addestramento dell’intelligenza artificiale. Secondo la sua analisi, la disattivazione di questa opzione non avrebbe impedito il trasferimento del repository, ma soltanto il suo eventuale utilizzo per l’addestramento del modello. In altre parole, il codice continuerebbe comunque a lasciare la macchina dello sviluppatore per essere archiviato sui sistemi remoti. Si tratta di una distinzione importante, perché trasmissione, archiviazione e addestramento rappresentano tre aspetti differenti dal punto di vista della sicurezza e della conformità normativa.

xAI avrebbe già modificato il comportamento del servizio

La vicenda, tuttavia, sembra aver avuto un’evoluzione molto rapida. Nei giorni successivi alla pubblicazione del report, lo stesso ricercatore ha ripetuto i test osservando un comportamento differente. In sei prove consecutive non sarebbe più stato rilevato alcun caricamento del repository tramite l’endpoint dedicato allo storage. Al suo posto sarebbero comparsi nuovi flag server-side, tra cui disable_codebase_upload, che sembrerebbero disattivare la funzione senza richiedere un aggiornamento del client. Al momento, però, xAI non ha pubblicato alcun advisory di sicurezza, né un changelog che spieghi ufficialmente la modifica o chiarisca quale sia stato l’impatto del problema sugli utenti che hanno utilizzato Grok Build prima della mitigazione. Anche le note di rilascio più recenti del progetto non fanno riferimento alla questione.

Una lezione per tutti gli agenti di coding

Al di là del singolo caso, l’episodio evidenzia una criticità destinata a diventare sempre più rilevante con la diffusione degli AI coding agent. Molti sviluppatori tendono infatti a considerare questi strumenti come semplici assistenti locali, mentre nella maggior parte dei casi il lavoro viene svolto su infrastrutture cloud. Per le organizzazioni questo significa che repository, codice proprietario, segreti applicativi e informazioni sensibili potrebbero lasciare il perimetro aziendale se non vengono definite precise policy di utilizzo. E addirittura, questo potrebbe succedere anche se le opzioni di non condivisione sono attive, richiedendo una infrastruttura di controllo che vada oltre la semplice policy.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/07/14/gli-assistenti-ai-di-coding-sono-sicuri-il-caso-xai/?utm_source=rss&utm_medium=rss&utm_campaign=gli-assistenti-ai-di-coding-sono-sicuri-il-caso-xai




La guerra ucraina cambia la cybersecurity delle infrastrutture critiche


La guerra in Ucraina non si combatte solo sul terreno, nel mare o nello spazio aereo. Il cyberspazio è uno degli scenari più attivi, dove vengono perpetrati quotidianamente decine di attacchi mirati alle infrastrutture civili e militari. Il continuo bersagliamento di infrastrutture energetiche, reti di comunicazione e servizi pubblici ha praticamente trasformato l’intero Paese in un enorme laboratorio dove si sviluppa la cyber-resilienza. Ma una cosa è proteggere le infrastrutture critiche civili, un’altra quelle militari e, ovviamente, l’Ucraina non ha abbastanza risorse interne per far fronte all’enorme numero di problemi da affrontare. Per questo è stato creato il Tallinn Mechanism, un’iniziativa internazionale nata per sostenere la resilienza digitale delle infrastrutture civili del Paese e che, indirettamente, sta contribuendo ad accrescere anche le capacità difensive delle aziende europee. Ne abbiamo parlato con Alessio Aceti, CEO di HWG Sababa, azienda impegnata in prima fila.

Cos’è il Tallinn Mechanism

Nonostante il nome possa trarre in inganno, il Tallinn Mechanism non è un organismo con sede in Estonia. Il nome deriva semplicemente dalla città in cui si è svolto il primo incontro istituzionale. Si tratta di un programma internazionale di cooperazione civile che coinvolge diversi Paesi europei, insieme a Stati Uniti e Canada, con l’obiettivo di sostenere la digitalizzazione e la sicurezza delle infrastrutture civili ucraine, comprese quelle considerate critiche. Un elemento distintivo dell’iniziativa è la sua natura prettamente civile. Pur essendo presente come osservatore, la NATO non partecipa direttamente alle attività operative.

Il meccanismo funziona come una piattaforma di collaborazione tra settore pubblico e privato. Le istituzioni ucraine pubblicano le proprie esigenze attraverso un portale dedicato, mentre aziende e organizzazioni dei Paesi aderenti partecipano a bandi finanziati dai governi per fornire competenze, tecnologie e servizi. Dal 1° luglio al 31 dicembre, inoltre, l’Italia assume il coordinamento del programma, con il compito di facilitare la collaborazione tra istituzioni e industria.

La formazione OT per le infrastrutture ucraine e il ritorno per l’Italia

Come già accennato, tra le realtà coinvolte figura HWG Sababa che insieme al Competence Center Cyber 4.0 e a partner francesi si è aggiudicata un progetto dedicato alla formazione sulla sicurezza OT (Operational Technology). L’attività è rivolta ai tecnici che operano nelle infrastrutture critiche ucraine, in particolare nei settori della produzione e distribuzione dell’energia.

L’approccio adottato si discosta dalla formazione tradizionale. Le esercitazioni sono infatti costruite attorno a laboratori pratici nei quali gli operatori lavorano direttamente su PLC, sistemi SCADA e digital substation, simulando attacchi realistici e imparando tecniche di rilevamento, contenimento e risposta in uno scenario caratterizzato da minacce costanti. L’aspetto forse più interessante emerso dall’esperienza raccontata durante l’intervista riguarda il valore che queste attività generano anche per il sistema Paese. L’Ucraina rappresenta infatti uno degli ambienti in cui vengono sperimentate per prime nuove tecniche, tattiche e procedure (TTP) adottate dagli attaccanti. Molte delle infrastrutture utilizzate nel Paese impiegano gli stessi sistemi industriali presenti anche nelle aziende italiane, inclusi prodotti di vendor internazionali come Schneider Electric e ABB. Questo consente agli specialisti coinvolti di osservare direttamente modalità di attacco che potrebbero arrivare successivamente anche nell’Europa occidentale. L’esperienza maturata sul campo permette quindi di anticipare le difese, identificando vulnerabilità e sviluppando contromisure prima che determinate campagne diventino una minaccia concreta anche per le organizzazioni italiane.

La guerra cambia anche il cybercrime

Un altro elemento evidenziato durante l’intervista riguarda l’evoluzione delle minacce. Le tecniche sviluppate dai gruppi riconducibili agli Stati-nazione tendono infatti, con il passare del tempo, a essere riutilizzate anche dalla criminalità informatica tradizionale. Secondo gli esperti, questo fenomeno rischia di accelerare ulteriormente con la diffusione dell’Intelligenza Artificiale, che potrebbe abbassare le competenze necessarie per sviluppare campagne offensive sempre più sofisticate. Di conseguenza, strumenti e metodologie oggi osservati in scenari di guerra potrebbero trasformarsi domani nelle tecniche utilizzate dai gruppi ransomware contro aziende di ogni dimensione.

Cybersecurity e sovranità digitale viaggiano insieme

L’esperienza del Tallinn Mechanism alimenta anche una riflessione più ampia sul tema della sovranità digitale. Secondo quanto emerso nell’intervista, costruire competenze nazionali, sviluppare servizi ad alto valore aggiunto e rafforzare la collaborazione tra imprese italiane rappresenta un elemento fondamentale per ridurre la dipendenza tecnologica dall’estero. In quest’ottica, la federazione di competenze e servizi diventa un fattore strategico non soltanto per la cybersecurity, ma anche per la competitività industriale del Paese.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/07/10/la-guerra-ucraina-cambia-la-cybersecurity-delle-infrastrutture-critiche/?utm_source=rss&utm_medium=rss&utm_campaign=la-guerra-ucraina-cambia-la-cybersecurity-delle-infrastrutture-critiche




OpenAI lancia GPT-5.6 Sol, Terra e Luna: anteprima limitata e nuovi controlli cyber (in accordo col Governo Usa)

OpenAI avvia l’anteprima limitata della nuova serie GPT-5.6. La famiglia comprende tre modelli: Sol, il più potente; Terra, bilanciato per il lavoro quotidiano; e Luna, progettato per offrire capacità solide al costo più basso. Secondo l’azienda, Terra garantisce prestazioni competitive rispetto a GPT-5.5 a metà costo, mentre Luna punta su velocità ed efficienza economica.

Il lancio non sarà subito aperto a tutti. OpenAI prevede di rendere GPT-5.6 Sol, Terra e Luna disponibili in modo più ampio nelle prossime settimane, ma la prima fase sarà riservata a un piccolo gruppo di partner fidati. La decisione arriva dopo un confronto con il governo degli Stati Uniti, a cui l’azienda ha presentato in anticipo piani e capacità dei nuovi modelli.

OpenAI precisa di non voler trasformare questo processo in una regola stabile per i futuri rilasci. Un accesso troppo condizionato dal governo, spiega l’azienda, rischierebbe di rallentare utenti, sviluppatori, imprese, difensori cyber e partner internazionali. La scelta viene quindi presentata come misura temporanea, legata allo sviluppo del quadro previsto dall’Executive Order americano sulla cybersicurezza.

Sol, Terra e Luna

Con GPT-5.6 cambia anche la nomenclatura. Il numero indica la generazione del modello, mentre Sol, Terra e Luna identificano tre livelli di capacità, costo e velocità.

Sol è il modello di punta, pensato per compiti complessi in coding, ricerca scientifica, cybersecurity e workflow agentici. Terra è la versione intermedia, con un equilibrio tra prestazioni e prezzo. Luna è il modello più rapido ed economico.

La logica è offrire a sviluppatori e aziende scelte più chiare: più intelligenza con Sol, più equilibrio con Terra, più efficienza con Luna.

Coding, biologia e cybersecurity

OpenAI presenta GPT-5.6 Sol come il modello più potente sviluppato finora. Le prime valutazioni mostrano miglioramenti nel coding, nella biologia e nella cybersecurity.

Nel coding, Sol raggiunge risultati di vertice su Terminal-Bench 2.1, benchmark che misura workflow complessi da riga di comando. Nella modalità Ultra, che usa subagenti per accelerare lavori articolati, il modello arriva al 91,9%.

Nella biologia, Sol migliora le prestazioni su GeneBench v1, benchmark dedicato ad analisi di genomica e biologia quantitativa su orizzonti lunghi, usando meno token rispetto a GPT-5.5.

La parte più sensibile riguarda però la cybersecurity. OpenAI definisce Sol il suo modello più capace finora in questo ambito. Su ExploitBench, GPT-5.6 Sol risulta competitivo con Mythos Preview usando circa un terzo dei token di output. Su ExploitGym, Sol, Terra e Luna mostrano miglioramenti al crescere dello sforzo di ragionamento.

Cyber più forte, misure di sicurezza più forti

OpenAI sostiene di aver sviluppato GPT-5.6 con il proprio stack di sicurezza più robusto finora. L’obiettivo è consentire usi legittimi, come revisione del codice, ricerca di vulnerabilità, sviluppo di patch, debugging e test difensivi, rendendo però più difficile l’uso offensivo vietato.

Secondo l’azienda, GPT-5.6 Sol è più efficace nell’aiutare a trovare e correggere vulnerabilità che nell’eseguire attacchi end-to-end. Nelle valutazioni interne non supera la soglia Cyber Critical del Preparedness Framework. Nei test su Chromium e Firefox ha individuato bug e primitive di sfruttamento, ma non ha prodotto autonomamente una catena di exploit completa e funzionante.

Per ridurre i rischi, OpenAI userà controlli a più livelli: protezioni integrate nel modello, classificatori in tempo reale per uso improprio cyber e biologico, monitoraggio, revisione a livello di account, accesso differenziato e test continui. In alcuni casi la generazione potrà essere sospesa per una verifica aggiuntiva prima di mostrare l’output all’utente.

Red teaming e rilascio graduale

L’azienda afferma di aver dedicato oltre 700mila ore GPU equivalenti ad A100 al red teaming automatizzato, con l’obiettivo di individuare jailbreak universali e rafforzare le protezioni. A questo si aggiunge il lavoro di tester esterni, che continuerà durante l’anteprima.

Il rilascio graduale servirà anche a verificare se i controlli bloccano davvero gli abusi senza ostacolare troppo il lavoro legittimo, soprattutto nelle aree dual-use come la cybersecurity.

Prezzi e disponibilità

Durante l’anteprima, GPT-5.6 sarà disponibile tramite API e Codex per partner e organizzazioni selezionati. OpenAI prevede poi di estendere l’accesso a ChatGPT, Codex e API.

I prezzi sono differenziati: Sol costa 5 dollari per milione di token in input e 30 dollari in output; Terra 2,50 dollari in input e 15 dollari in output; Luna 1 dollaro in input e 6 dollari in output.

A luglio, OpenAI lancerà anche GPT-5.6 Sol su Cerebras fino a 750 token al secondo, inizialmente per clienti selezionati.

Il lancio di GPT-5.6 mostra quanto i modelli di frontiera siano ormai entrati nel perimetro della sicurezza nazionale. OpenAI vuole allargare l’accesso, ma parte da una preview limitata dopo il confronto con Washington.

Novità su Google, per aggiungere Key4Biz tra le tue fonti preferite, clicca qui

Aggiungi Key4Biz tra le tue fonti preferite

Leggi le altre notizie sull’home page di Key4biz

https://www.key4biz.it/openai-lancia-gpt-5-6-sol-terra-e-luna-anteprima-limitata-e-nuovi-controlli-cyber-in-accordo-col-governo-usa/579505/




AI, il nuovo fronte della sicurezza: il red teaming diventa indispensabile


L’intelligenza artificiale sta entrando nelle aziende con una velocità che non ha precedenti, ma la sua diffusione sta facendo emergere una realtà che molti responsabili della sicurezza stanno iniziando a sperimentare direttamente: i tradizionali strumenti di difesa non sono stati progettati per proteggere sistemi che ragionano attraverso il linguaggio naturale. Firewall, Web Application Firewall e sistemi di protezione delle reti continuano a svolgere il loro ruolo, ma davanti a chatbot, agenti AI e Large Language Model si apre una superficie di attacco completamente nuova.

Secondo Gartner, entro quest’anno l’80% delle organizzazioni utilizzerà soluzioni basate sull’intelligenza artificiale, una crescita che supera in velocità perfino quella vissuta in passato da cloud computing, dispositivi mobili e Internet. Una diffusione tanto rapida quanto impegnativa dal punto di vista della cybersecurity.

Quando la conversazione diventa la superficie di attacco

L’evoluzione dell’AI segue percorsi differenti. Alcune aziende si limitano all’utilizzo di strumenti come ChatGPT, Copilot o Gemini per aumentare la produttività individuale, mentre altre stanno sviluppando chatbot interni, assistenti per il customer care oppure sistemi agentici capaci di eseguire attività autonome.

Ma in queste implementazioni più avanzate, la sicurezza cambia completamente natura. Il problema non riguarda più esclusivamente il codice o il traffico di rete, ma il modo in cui il modello interpreta, elabora e restituisce informazioni attraverso il linguaggio naturale. Una conversazione non può essere filtrata come un pacchetto IP. È questo il motivo per cui molti controlli tradizionali risultano inefficaci contro gli attacchi rivolti ai sistemi di AI.

Infatti, secondo i dati riportati da F5, il 75% dei CISO ha già registrato incidenti di sicurezza legati all’intelligenza artificiale, mentre il 91% dichiara di aver individuato tentativi di attacco contro la propria infrastruttura AI. Ancora più significativo è il fatto che il 94% considera ormai prioritario sottoporre le applicazioni AI a test di sicurezza specifici.

Dagli errori logici ai nuovi attacchi cognitivi

Le vulnerabilità che colpiscono le piattaforme di AI non sono necessariamente nuove dal punto di vista tecnico, ma assumono caratteristiche completamente differenti quando vengono inserite in sistemi basati su Large Language Model. Un errore nell’isolamento dei tenant, ad esempio, può trasformarsi nella restituzione di informazioni appartenenti ad altre organizzazioni direttamente all’interno di una conversazione naturale, rendendo molto difficile individuare il problema. Anche i classici attacchi di prompt injection possono avere conseguenze particolarmente gravi quando il modello dispone dell’autorizzazione a utilizzare strumenti esterni o ad interagire con sistemi aziendali. Se il controllo delle autorizzazioni viene affidato al modello anziché all’infrastruttura applicativa, il rischio aumenta sensibilmente.

Accanto a questi scenari stanno emergendo nuove categorie di minacce, che comprendono tecniche di jailbreak sempre più sofisticate, data poisoning durante l’addestramento e meccanismi di token compression, nei quali istruzioni malevole vengono nascoste in forme comprensibili al modello ma praticamente invisibili agli operatori umani.

Perché i test tradizionali non bastano più

Uno degli aspetti più complessi dell’AI riguarda il fatto che non ci si trova più davanti a software deterministico. Ogni conversazione può produrre risultati differenti in base al contesto, alla memoria dell’agente, ai documenti recuperati tramite retrieval oppure agli strumenti che il modello può utilizzare. Questo rende estremamente difficile applicare i normali processi di vulnerability assessment. Mentre in passato era sufficiente verificare il comportamento di un’applicazione seguendo scenari relativamente prevedibili, oggi le possibili combinazioni diventano praticamente infinite. Testarle manualmente è semplicemente irrealistico, soprattutto quando un’organizzazione gestisce decine o centinaia di chatbot o agenti AI.

Per questo diventa indispensabile strutturare un sistema di AI Red Teaming, ovvero la simulazione sistematica di attacchi contro sistemi basati sull’intelligenza artificiale per verificarne il comportamento in condizioni ostili. L’obiettivo non è soltanto individuare vulnerabilità tecniche, ma comprendere come il sistema reagisce a prompt malevoli, tentativi di manipolazione, richieste ambigue o scenari progettati per aggirare i controlli di sicurezza. Un approccio che deve produrre risultati riproducibili, permettendo agli sviluppatori di identificare esattamente quali conversazioni hanno generato il comportamento indesiderato e quali condizioni lo hanno reso possibile.

Normative e compliance spingono verso test continui

L’importanza del red teaming non nasce esclusivamente da esigenze tecnologichema anche dal quadro normativo che sta evolvendo rapidamente. L’AI Act europeo introduce esplicitamente attività di adversarial testing per determinate categorie di sistemi AI, mentre negli Stati Uniti organizzazioni come NIST e CISA stanno promuovendo procedure di verifica sempre più strutturate, soprattutto nei contesti considerati mission critical. La sicurezza dell’intelligenza artificiale diventa quindi non soltanto una misura di protezione, ma anche un requisito di conformità e governance.

Ma c’è un risvolto per alcuni versi “inatteso”. Storicamente, possiamo tutti ricordare l’avversione delle proprietà nei confronti della cybersecurity, troppo spesso vista come una spesa e addirittura un fastidio che tendeva a rallentare il business. Nel caso dell’intelligenza artificiale potrebbe invece verificarsi il contrario. Disporre di test automatizzati, evidenze documentate e verifiche continue consente infatti di portare più rapidamente in produzione nuovi casi d’uso, offrendo ai team di compliance e agli auditor elementi concreti per valutare il rischio.

L’AI red teaming si sta quindi trasformando da semplice attività specialistica a componente fondamentale della sicurezza delle applicazioni AI, permettendo alle aziende di adottare chatbot, agenti e workflow intelligenti con un livello di fiducia molto superiore rispetto agli approcci tradizionali. Purtroppo, non mancano le sfide. Molte delle competenze necessarie per fare AI Red Teaming sono ancora rare, ma si spera che verranno formate in tempi ragionevolmente brevi dal settore accademico e, soprattutto, dalle stesse aziende.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/07/06/ai-il-nuovo-fronte-della-sicurezza-il-red-teaming-diventa-indispensabile/?utm_source=rss&utm_medium=rss&utm_campaign=ai-il-nuovo-fronte-della-sicurezza-il-red-teaming-diventa-indispensabile




In Other News: Canadian Hacker Jailed, Open Source Zero-Days, Two Sentenced for ATM Jackpotting

SecurityWeek’s cybersecurity news weekly roundup offers a concise overview of important developments that may not receive full standalone coverage but remain relevant to the broader threat landscape.

This curated summary highlights key stories across vulnerability disclosures, emerging attack methods, policy updates, industry reports, and other noteworthy events to help readers maintain a well-rounded awareness of the evolving cybersecurity environment.

Here are this week’s highlights:

Anonymous-linked hacker Aubrey Cottle jailed over Texas GOP cyberattack

Aubrey Cottle, a Canadian hacker associated with the hacktivist group Anonymous, has been sentenced to 18 months in prison for his involvement in a cyberattack on the Texas Republican Party’s website in September 2021. Cottle, 39, of Oshawa, Ontario, pleaded guilty to defacing the website, exfiltrating data from a Texas GOP server, and publishing the data online.

14 million impacted by KDDI data breach

Advertisement. Scroll to continue reading.

Japanese telecoms provider KDDI has disclosed (PDF) a data breach likely impacting the email addresses and passwords of 14,22 million people. The incident affected five ISP operators, including BIGLOBE, Chubu Telecommunications C., JCOM Co., NIFTY Corporation, and STNet. 

Push Security targeted in poisoned tenant attack

Three years after detailing the poisoned tenant attack, Push Security was targeted using the technique via OpenAI’s organization invitation feature. Multiple employees received an OpenAI invitation to join Push Security Inc. After they would join the tenant, the attacker could spy on their activities or target them with further social engineering. 

Rust-based PamStealer targeting macOS

Jamf has detailed PamStealer, an information stealer targeting macOS that validates the harvested credentials via Pluggable Authentication Modules (PAM) before using them. The malware is distributed as a compiled AppleScript file impersonating the open source clipboard manager Maccy.

Russian hackers behind the 2025 Jaguar Land Rover hack

The cyberattack that severely disrupted Jaguar Land Rover’s operations in September 2025 was mounted by Russian hackers, The New York Times says. Microsoft reportedly notified the car manufacturer about the hacking group, with Mandiant, Palo Alto Networks, and US and UK law enforcement agencies also involved in the investigation. 

Pegasus spyware targeted a European Parliament member investigating it

Former member of the European Parliament Stelios Kouloglou was hacked with NSO Group’s Pegasus spyware while he was investigating Pegasus abuse cases, as part of the PEGA committee, Citizen Lab discovered. The targeting has not been attributed to a specific government, and there is no evidence that the Greek Government was involved. 

Researcher drops dozens of zero-days in open source projects

A researcher known as Bikini has published proof-of-concept (PoC) code targeting dozens of zero-day vulnerabilities in multiple open source projects, including FFmpeg, Gogs, Gitea, Ghidra, 7-Zip, OpenVPN, and VLC. Nine of the security defects have been assigned a CVE identifier. The issues, the researcher says, were surfaced via LLM fuzzing. 

Pro-Russia influence operations are shifting

Four years into Russia’s invasion of Ukraine, pro-Russia influence operations are shifting from their single focus on Ukraine to pre-war objectives, Google says. Covert pro-Russia influence operations are targeting the US, European Union members, NATO, Russia’s neighbors, the Middle East and Africa, and internal entities. They focus on global events, elections, the war in Ukraine, and emerging geopolitical developments and events, and are increasingly relying on generative AI. 

Venezuelans sentenced in the US over ATM jackpotting

Two illegal aliens from Venezuela, Carlos Javier Padron, 36, and Arnoldo Cabrera Torrealba, 37, have been sentenced to 78 months in prison in the US for their involvement in ATM jackpotting activities. As part of a sophisticated criminal group, they built and deployed a variant of the Ploutus malware on ATMs across the US and used it to withdraw money without authorization. They were also ordered to jointly pay $1.5 million in restitution. 96 other defendants have been charged over their roles in the operation. 

Cisco and Synology patches

Cisco has released fixes for seven ClamAV vulnerabilities impacting Secure Endpoint Connector for Windows, Linux, and macOS, and Secure Endpoint Private Cloud, and for one flaw in Catalyst Center. Synology resolved three security defects in MailPlus Server, including two critical bugs that could allow attackers to read or write arbitrary files and cause DoS conditions.

Join the AI Risk Summit | Ritz-Carlton, Half Moon Bay

https://www.securityweek.com/in-other-news-canadian-hacker-jailed-open-source-zero-days-two-sentenced-for-atm-jackpotting/




Chat Control 2.0, gli esiti incerti della contestata proposta di regolamento europeo

Lunedì 29 giugno l’Unione Europea è tornata a discutere del Regolamento 2022/0155 CSAR (Child Sexual Abuse Regulation), più noto come “Chat Control 2.0”.

Presentato nel 2022, negli anni il testo è stato oggetto di numerosi round negoziali tra Parlamento, Consiglio e Commissione UE; allo stesso tempo è finito al centro di accese critiche legate al rischio di avallare forme di sorveglianza digitale sugli utenti.

Per meglio inquadrare l’esito dell’incontro, nel presente articolo ripercorriamo l’iter normativo, i contenuti e le principali criticità della proposta di regolamento.

L’iter della proposta CSAR

Il passaggio iniziale risale all’11 maggio 2022, quando la Commissione Europea annunciò di voler introdurre un regolamento mirato a “prevenire e combattere l’abuso sessuale sui minori”.

Alla luce dell’evoluzione delle tecnologie e del mutato panorama di rischio, la proposta si affiancava alla precedente Direttiva 2011/93 e abrogava il Regolamento 2021/1232 – noto come “Chat Control 1.0” – che prevedeva una deroga temporanea alla direttiva ePrivacy del 2002, per consentire agli erogatori dei servizi digitali la scansione volontaria delle conversazioni sulle proprie piattaforme a fini di rilevazione e rimozione del Child Sexual Abuse Material (CSAM).

La nuova formulazione assegnava ai gestori dei servizi un ruolo più stringente, prevedendo uno scanning non più volontario ed episodico ma preventivo e massivo, allo scopo di contrastare più efficacemente lo CSAM e i fenomeni di grooming.

Negli anni seguenti, tuttavia, diversi pareri e relazioni tecniche degli organi comunitari avrebbero evidenziato le possibili insidie di simili ingerenze nelle comunicazioni private dei cittadini.

Nonostante tali criticità, inizialmente gran parte degli Stati membri annunciò il proprio favore per l’adozione della normativa; ma in seguito si diffusero crescenti dubbi verso le misure proposte, tanto che le consultazioni avvenute nell’ottobre 2025 terminarono con esito negativo (mentre il 26 novembre il Consiglio avrebbe poi raggiunto una posizione comune).

Dopo una parziale revisione del testo, svoltasi sotto la Presidenza danese del Consiglio UE, alla fine del 2025 si è quindi aperto un processo negoziale – tuttora in corso – che ha coinvolto Parlamento, Consiglio e Commissione europea.

L’iter ha registrato un’evoluzione fondamentale a marzo, quando la Commissione Giustizia, Libertà civili e Affari interni (LIBE) ha respinto la deroga provvisoria alla direttiva ePrivacy con 28 voti favorevoli e 38 contrari; pochi giorni dopo, anche il Parlamento si sarebbe pronunciato a sfavore, portando alla scadenza della proroga il 3 aprile 2026.

Il nodo della crittografia end-to-end

Uno dei principali nodi critici della proposta risiede nella previsione di una sorveglianza preventiva generalizzata, che permetterebbe alle aziende tech di accedere a chat di messaggistica ed email di milioni di persone senza necessità di alcun controllo giudiziario, così violando il principio di riservatezza della vita privata sancito dall’art. 8 della Convenzione Europea sui Diritti Umani (CEDU).

Questo richiederebbe di verificare i messaggi mediante il client-side scanning, analizzando i contenuti direttamente sul dispositivo dell’utente prima di applicare la crittografia end-to-end (E2E); ne deriverebbero serie implicazioni anche per le aziende responsabili dei servizi, costrette a monitorare costantemente i contenuti condivisi dai propri utenti alla ricerca di materiali illeciti.

È ovvio che l’unico modo per garantire tale monitoraggio su un’immensa mole di conversazioni sarebbe implementare forme di scansione automatizzata delegate a sistemi basati sull’AI, con quanto ne consegue in termini di falsi positivi ed errori dagli effetti potenzialmente molto gravi per la vita e la reputazione dei cittadini coinvolti, come del resto aveva rilevato sin da subito il parere congiunto EDPB–EDPS n. 4/2022.

Anche l’imposizione di meccanismi di age verification avrebbe serie conseguenze in termini di identificazione e profilazione degli utenti, portando a una sostanziale cancellazione del diritto all’anonimato online.

Soprattutto, minare la crittografia end-to-end significherebbe esporre a seri pericoli gruppi di persone già particolarmente vulnerabili alla sorveglianza digitale: come giornalisti investigativi, oppositori politici e perfino vittime di cyber stalking, che non potrebbero più contare su alcuna garanzia circa la segretezza delle proprie comunicazioni online.

Gli attuali contenuti: “Chat Control 2.0”

Allo scopo dichiarato di proteggere i minori da ogni forma di abuso, il testo del regolamento abilita il mass scanning preventivo sulle email e i messaggi privati dei cittadini, rischiando di fatto di introdurre forme di sorveglianza digitale generalizzata sugli utenti europei.

Dopo la revisione avvenuta alla fine del 2025 si è tornati a parlare, come già nel Chat Control 1.0, di “scansione volontaria” e non obbligatoria; tuttavia, si continuano a prevedere misure obbligatorie di risk assessment (Art. 3) e risk mitigation (Art. 4) a carico delle aziende erogatrici di servizi di comunicazione digitale.

Si sancisce poi l’obbligo di introdurre meccanismi di verifica dell’età per i servizi di hosting e comunicazione, richiedendo l’esibizione di un documento d’identità o l’utilizzo di credenziali biometriche per accedere a servizi e piattaforme online.

Nel regolamento viene infine anticipata la costituzione di un nuovo centro di controllo europeo incaricato di coordinare le attività di prevenzione e contrasto della violenza sui minori, con cui le aziende tecnologiche saranno tenute a collaborare attivamente.

La posizione dell’Italia sul Regolamento

Inizialmente tra i sostenitori della proposta, negli ultimi due anni l’Italia ha progressivamente sfumato la propria posizione sul regolamento CSAR.

Tuttavia, pur continuando a dichiararsi contraria alla previsione di forme di scansione massiva sulle comunicazioni private, nel Coreper di novembre il nostro Paese ha scelto non di esprimere un voto contrario ma di astenersi, come ha fatto anche la Germania.

Una scelta ambigua, che lascia aperte numerose domande sulla reale posizione del governo circa una normativa che potrebbe impattare profondamente la privacy dei propri cittadini.

Le iniziative della società civile

Com’era prevedibile, nei quasi cinque anni trascorsi dalla sua proposizione il Regolamento non è rimasto esente da valutazioni negative.

Le più accese provengono dalle associazioni per i diritti digitali, le quali hanno lanciato una petizione contro l’approvazione della normativa, evidenziando che prevedere una scansione generalizzata su email e servizi di messaggistica equivale a sancire la fine della privacy come concepita in seno all’Unione Europea.

Anche numerosi esperti di cybersecurity si sono pronunciati contro la proposta, ricordando come sancire l’aggirabilità della crittografia E2E significhi, tra le altre cose, aprire la porta ad ogni tipo di vulnerabilità sui dispositivi degli utenti.

E se i proponenti parlano di un “vuoto normativo” da colmare con urgenza, gli oppositori continuano a ricordare che esistono altre strade per combattere un fenomeno odioso come lo CSAM, senza necessariamente imporre a milioni di cittadini incolpevoli di rinunciare alla privacy delle loro comunicazioni digitali.

Gli esiti dell’incontro del 29 giugno

Qualora nel trilogo di lunedì 29 giugno 2026 fosse stato raggiunto un accordo, l’adozione formale del regolamento CSAR sarebbe probabilmente arrivata entro la fine di luglio.

L’incontro non ha invece saputo individuare una posizione comune su tutti i punti in discussione, avendo come esito un’ennesima proroga dei lavori.

Si conferma l’esistenza di un consenso diffuso rispetto alla maggior parte delle misure proposte, come le definizioni del fenomeno da contrastare o le funzioni del futuro Centro Europeo per la protezione dei Minori; restano tuttavia irrisolti gli aspetti relativi alla scansione automatica dei messaggi privati, da sempre il punto più contestato della normativa.

Intanto, secondo quanto riportano alcune fonti (italiane ed estere), il Coreper avrebbe nuovamente calendarizzato un incontro per procedere a revisionare la versione del regolamento in cui era prevista la scansione delle comunicazioni su base volontaria oggetto della proroga scaduta ad aprile, ossia il noto “Chat Control 1.0”.

Ciò significherebbe aggirare la volontà espressa dal Parlamento per riproporre una proposta ormai definitivamente decaduta: di fatto una lesione senza precedenti ai meccanismi democratici comunitari, che – se confermata – non mancherà di suscitare nuove critiche e reazioni, ulteriormente complicando la già lunga e travagliata strada per l’approvazione del regolamento CSAR.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/chat-control-2-0/




Falsa skill elude gli scanner e a raggiunge più di 26.000 agenti AI


La rapida diffusione degli Agenti AI sta creando un ecosistema sempre più complesso nel quale modelli linguistici, strumenti esterni e componenti aggiuntivi collaborano per svolgere attività operative. Questa architettura modulare, però, sta aprendo una nuova superficie di attacco che ricorda da vicino le vulnerabilità già viste nel mondo open source e nei marketplace di applicazioni.

Un caso recente evidenziato dai ricercatori ha mostrato come una falsa skill per agenti AI sia riuscita a superare i controlli automatici di sicurezza e a raggiungere oltre 26.000 agenti, dimostrando quanto siano ancora immature molte delle difese implementate nei marketplace dedicati agli agenti intelligenti.

Quando il problema non è il modello ma l’estensione

Molte piattaforme agentiche consentono agli utenti di installare componenti aggiuntivi, spesso chiamati skill, tool o plug-in. Questi moduli permettono all’agente di accedere a nuove funzionalità, interagire con servizi esterni o automatizzare processi complessi.

Il problema è che la sicurezza di questi ecosistemi non dipende soltanto dal modello AI utilizzato, ma anche dall’affidabilità delle estensioni installate. Se una skill malevola riesce a superare i controlli preliminari, può ottenere accesso a dati sensibili, credenziali e processi aziendali eseguiti dall’agente.

Secondo una recente analisi su quasi 4.000 skill distribuite in diversi marketplace, i ricercatori hanno identificato 76 payload malevoli confermati, mentre il 13,4% delle skill analizzate presentava almeno una vulnerabilità classificata come critica.

Come è stata aggirata la scansione automatica

L’aspetto più interessante della vicenda riguarda il modo in cui la falsa skill è riuscita a sfuggire agli strumenti di verifica.

Gli scanner automatici utilizzati da molte piattaforme si concentrano prevalentemente sull’analisi statica del codice e sulla ricerca di pattern noti. Gli autori della skill hanno invece sfruttato tecniche di offuscamento e comportamenti attivati solo in determinate condizioni operative, rendendo difficile individuare la componente malevola durante le verifiche preliminari.

Il rischio per le aziende

La vicenda evidenzia un problema destinato a crescere nei prossimi anni. Sempre più aziende concedono agli agenti AI accesso a repository di codice, documentazione interna, strumenti di produttività, piattaforme cloud e una skill compromessa potrebbe diventare un vettore privilegiato per attività di esfiltrazione dati, raccolta di credenziali, installazione di backdoor o manipolazione dei workflow aziendali. I ricercatori hanno già osservato casi reali di skill progettate per sottrarre informazioni sensibili o modificare il comportamento degli agenti ospitanti. La criticità è amplificata dal fatto che molti agenti operano con privilegi elevati e possono accedere direttamente a servizi interni o risorse normalmente non esposte a utenti esterni.

Verso una nuova generazione di controlli

La diffusione degli AI Agent sta riproponendo dinamiche già note nel mondo del software tradizionale. Così come repository open source e store di applicazioni sono diventati obiettivi privilegiati degli attacchi supply chain, anche i marketplace delle skill stanno emergendo come un nuovo bersaglio.

Per le aziende che intendono adottare agenti autonomi sarà quindi fondamentale introdurre processi di validazione indipendenti, sandbox dedicate, monitoraggio continuo e controlli granulari sui privilegi concessi alle estensioni installate.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/06/21/una-falsa-skill-elude-gli-scanner-e-a-raggiunge-piu-di-26-000-agenti-ai/?utm_source=rss&utm_medium=rss&utm_campaign=una-falsa-skill-elude-gli-scanner-e-a-raggiunge-piu-di-26-000-agenti-ai




Infrastrutture Critiche e Geopolitica: è l’Era dell’Antifragilità


Il nuovo assetto geopolitico mondiale ha messo a nudo una serie di problematiche che sono state trascurate troppo a lungo. In pratica, quello che per anni abbiamo visto accadere nel software, ovvero l’entusiasmo per le nuove feature che andava a coprire la necessità di rendere sicuro il loro utilizzo, si è applicato anche in mille altri settori lontanissimi dal coding. L’esperienza di Alessio Fasano, Country Manager della Southern EMEA Region di FireMon con un passato da CSO in una primaria Telco nazionale, ci offre una prospettiva privilegiata su come l’Europa e l’Italia stiano affrontando queste minacce.

Il conflitto tra Ucraina e Russia ha riacceso i riflettori su vulnerabilità che vanno ben oltre il semplice sabotaggio fisico. Sebbene incidenti come il taglio dei cavi sottomarini nel Mar Rosso rappresentino un rischio concreto di interruzione della connettività, la preoccupazione principale degli esperti riguarda le cosiddette landing station. Questi nodi, dove i cavi approdano e il traffico viene aggregato, sono apparati critici che richiedono una visibilità totale. Il timore non è solo l’assenza di segnale, ma che la rete stessa diventi il veicolo per infiltrazioni profonde nei sistemi informatici aziendali e governativi, sfruttando ogni possibile punto d’accesso tra i cinque domini, dal sottomarino allo spaziale.

Una situazione poco omogenea

La preparazione del sistema Paese rispetto a tali scenari appare oggi variegata, definibile come una situazione a macchia di leopardo. Mentre i settori utility e finanziario hanno mostrato una maggiore maturità, le telecomunicazioni e i trasporti si trovano a gestire una complessità tecnologica e operativa senza precedenti. In questo contesto, le normative europee e nazionali hanno agito come una leva fondamentale per scuotere la consapevolezza dei board. In Italia, il Perimetro di Sicurezza Nazionale Cibernetica ha imposto un primo importante risveglio, passando da una gestione puramente burocratica a implementazioni tecniche reali sui sistemi. Tuttavia, il percorso è ancora lungo e si prevede che la NIS2, il regolamento DORA e l’AI Act spingeranno ulteriormente le aziende verso una postura di sicurezza non più tattica ma strategica, finalizzata alla sovranità digitale europea.

Le Telco stanno cambiando

Un elemento di ulteriore complicazione è rappresentato dalla recente ondata di consolidamento e acquisizioni nel settore Telco. Le operazioni finanziarie che portano alla creazione di “super-telco” generano un’amplificazione della complessità operativa immediata. I tecnici si trovano improvvisamente a gestire un numero di device moltiplicato, dovendo far convivere infrastrutture diverse e proteggere contemporaneamente segmenti corporate e business.

Senza strumenti avanzati di Network Security Policy Management che garantiscano automazione e semplificazione, queste realtà rischiano fermi disastrosi a seguito di attacchi mirati. La difficoltà principale nel risolvere queste inefficienze non è però tecnologica, ma organizzativa: persistono ancora silos invalicabili tra chi gestisce la sicurezza, il networking e le operazioni, con ogni dipartimento impegnato a difendere il proprio status quo invece di collaborare per una visibilità comune.

Il CISO deve evolvere insieme alla situazione

Il superamento di queste barriere è oggi guidato dalla figura del CISO, il cui ruolo è profondamente maturato negli ultimi anni. Grazie alle responsabilità introdotte dalle nuove normative, il responsabile della sicurezza ha finalmente ottenuto un posto al tavolo delle decisioni, sebbene rimangano margini di miglioramento nella segregazione dei compiti e nei riporti gerarchici, che dovrebbero puntare direttamente al CEO per garantire massima efficacia. Il CISO moderno è colui che deve traghettare l’azienda oltre il concetto di resilienza, tipicamente legato alla ridondanza dei sistemi gestita dal COO, per approdare a quello di antifragilità. Essere antifragili significa avere la capacità di reagire all’imprevedibile e di adattarsi velocemente durante una crisi. In un mondo in cui la domanda non è più se si verrà attaccati, ma quando accadrà, la chiave del successo risiede nel training costante, nelle simulazioni in War Room e nella capacità di gestire l’incidente con strumenti che permettano risposte rapide e basate sui dati.

Condividi l’articolo



Articoli correlati

Altro in questa categoria


https://www.securityinfo.it/2026/06/09/infrastrutture-critiche-e-geopolitica-e-lera-dellantifragilita/?utm_source=rss&utm_medium=rss&utm_campaign=infrastrutture-critiche-e-geopolitica-e-lera-dellantifragilita




Forensics by design e art. 220 c.p.p.: come si processa un agente AI in un tribunale italiano

Il primo contenzioso italiano fondato sull’operato di un agente autonomo non si giocherà soltanto sui log, ma sulla ricostruibilità della chain of delegation. Tradurre la tesi della forensics by design nel quadro della perizia tecnica italiana, fra schema OpenTelemetry GenAI, ricevute hash-chained, Non-Human Identity per-agente e metodologia Daubert-grade, significa anticipare oggi il contraddittorio di domani.

Una scena già reale: l’agente AI come fonte di prova

Un agente AI integrato nei sistemi di una banca approva un bonifico anomalo. Un altro, in una catena di delega multi-livello, modifica un parametro nel gestionale di un’azienda sanitaria. Un terzo, nei processi documentali della pubblica amministrazione, opera firme digitali su atti automatizzati. Nessuno di questi scenari appartiene al futuro: tutti rientrano nei perimetri operativi documentati dagli studi 2025-2026 di Cloud Security Alliance, ENISA e OWASP. Quando una di queste catene si rompe, qualcosa di nuovo entra nel circuito processuale italiano: una fonte di prova non umana, una condotta mediata da sistemi autonomi, una catena decisionale che non coincide più linearmente con l’azione di una persona fisica.

Il problema, per giudici, periti e difensori, non è la quantità di tracce lasciate dall’agente. È la loro tenuta probatoria. Il punto non sarà stabilire soltanto se un agente abbia eseguito un’azione, ma se quell’azione fosse il risultato di una delega umana verificabile, limitata nello scope e conservata in una forma tecnicamente opponibile.

È la sintesi che, alla 14ª Cyber Crime Conference (Roma, 6-7 maggio 2026), il consulente tecnico Cosimo de Pinto (IISFA, ONIF, Tribunale di Roma) ha condensato in una formula destinata a circolare: una risposta plausibile non è ancora una risposta difendibile. Una linea di ricerca che attraversa l’iniziativa OWASP Agentic Security (ASI), i gruppi di lavoro OpenTelemetry GenAI e la prima letteratura forense peer-reviewed sostiene la stessa tesi su scala sistemica: senza un’infrastruttura forense incorporata nel ciclo di vita dei sistemi agentic, l’evidenza digitale non sopravvive al controesame. È il principio del forensics by design: non si raccoglie ex post ciò che il sistema non è stato progettato per produrre ex ante.

Perché la digital forensics classica si incrina

La forensica informatica italiana ha un impianto consolidato. La legge 48/2008 di ratifica della Convenzione di Budapest ha imposto, modificando il codice di rito, che le attività di ispezione, perquisizione e sequestro di sistemi informatici siano condotte con “misure tecniche dirette ad assicurare la conservazione dei dati originali e a impedirne l’alterazione”. L’art. 260 comma 2 c.p.p. prescrive che la copia avvenga “su adeguati supporti, mediante procedura che assicuri la conformità della copia all’originale e la sua immodificabilità”. Sul piano operativo, le norme ISO/IEC 27037:2012, 27041:2015, 27042:2015 e 27043:2015 hanno definito il quadro procedurale: identificazione, raccolta, acquisizione, preservazione, analisi, con catena di custodia continua e impronta crittografica.

Questo apparato presuppone un oggetto stabile. Un disco è uguale a se stesso; una mailbox, un server log, uno snapshot sono riproducibili a parità di input. Un agente AI no. Uno studio empirico di Gruber e Hilgert (arXiv 2604.05589, aprile 2026) ha documentato che l’esecuzione mediata da agente introduce un livello di astrazione e una quantità di non-determinismo assenti nel software a regole: a parità di prompt, di contesto e di stato, lo stesso agente può scegliere un tool diverso, generare un piano differente, produrre un esito divergente.

È in questo punto che si gioca, sul piano forense, la differenza fra indizio operativo e prova: l’output non auditabile orienta l’indagine, ma non regge la contestazione, la ripetizione, la controperizia in dibattimento.

L’effetto sul processo penale italiano si misura su un punto preciso. La dicotomia fra accertamento tecnico ripetibile ex art. 359 c.p.p. e irripetibile ex art. 360 c.p.p. è il cardine procedurale della prova informatica: dal primo dipende la possibilità di operare senza preavviso alle parti; dal secondo discende il contraddittorio anticipato, con avviso al difensore e facoltà di nominare consulente tecnico di parte.

La giurisprudenza, dopo decenni di oscillazione, è arrivata a un punto di sintesi: la copia forense di un disco è atto ripetibile se condotta con metodologie idonee a non alterare l’originale. L’agente agentic, invece, opera per definizione in uno stato esso stesso mutevole. Come ha osservato di recente la dottrina, molti accertamenti sono ora “formalmente ripetibili” e “materialmente irripetibili”: si possono rifare in laboratorio, ma il risultato non sarà identico. È in questo scarto che la perizia su sistemi agentic deve trovare la propria forma.

I quattro pilastri del forensics by design

L’argomento operativo che sta maturando nella comunità tecnica si articola su quattro pilastri convergenti, che giudici e periti dovranno presto saper interrogare.

  1. Uno schema comune di evidenza su OpenTelemetry GenAI

OpenTelemetry, standard de facto di osservabilità sostenuto dalla Cloud Native Computing Foundation, ha avviato in aprile 2024 un Special Interest Group dedicato alle convenzioni semantiche per GenAI. La specifica (status Development, versione 1.41.0 al maggio 2026) definisce uno schema unificato di attributi gen_ai.
per descrivere chiamate ai modelli, esecuzioni di tool, invocazioni di agenti e workflow multi-agente. Le convenzioni OpenTelemetry per agenti prevedono span tipizzati per le operazioni create_agent, invoke_agent, invoke_workflow ed execute_tool, con relazioni che ricostruiscono la gerarchia dell’esecuzione.

Il rilievo forense è immediato. Uno schema condiviso consente al perito di leggere telemetria proveniente da vendor e framework diversi (Google ADK, LiveKit, Spring AI, CrewAI, Microsoft Agent Framework) con una grammatica uniforme. Significa poter porre al sistema le stesse domande indipendentemente da chi l’ha costruito, condizione necessaria perché un accertamento sia metodologicamente confrontabile in dibattimento.

  1. Ricevute hash-chained: dalla traccia all’evidenza

La telemetria, da sola, non è prova. Un log è un’asserzione di chi lo emette: può essere manipolato, sostituito, sovrascritto, e nelle architetture cloud condivise spesso non lascia neppure traccia di un’eventuale manomissione. La seconda linea di sviluppo introduce strutture append-only di tipo Merkle per registrare gli eventi del ciclo di vita degli agenti, producendo ricevute concatenate in hash che rendono tamper-evident ogni passo dell’esecuzione. La letteratura più recente sulla Context Lineage Assurance per Non-Human Identity in sistemi multi-agente critici (arXiv 2509.18415) formalizza il principio: ogni evento entra in un registro crittografico verificabile in modo indipendente.

Nel quadro italiano questo strato colma il vuoto che la legge 48/2008 ha lasciato intenzionalmente. La norma prescrive il risultato (conformità all’originale, immodificabilità), non il metodo, e demanda alle best practice il quadro procedurale. Per i sistemi agentic serve un’estensione: le ricevute concatenate operano non sui bit, ma sugli eventi semantici (la decisione di invocare un tool, la delega a un sotto-agente, il consumo di una credenziale). Resta utile, come quadro di partenza, la sintesi sulla legge 48/2008 e standard internazionali già pubblicata da questa rivista.

  1. Non-Human Identity per-agente

Il terzo pilastro tocca un nervo che la Cloud Security Alliance ha definito “the defining security gap of the agentic AI era”. In molte implementazioni reali gli agenti operano con account di servizio condivisi, credenziali ereditate dall’utente che li invoca, token OAuth riutilizzati lungo catene di delega. Le rilevazioni Entro Labs H1 2025 stimano un rapporto NHI/identità umane di 144:1 nei contesti cloud-native; un’analisi CSA 2026 registra che oltre il 16% delle organizzazioni non traccia affatto la creazione di identità AI.

L’OWASP Top 10 for Agentic Applications (dicembre 2025), tra i cui co-lead figura John Sotiropoulos (Head of AI Security di Kainos e board member OWASP GenAI Security Project), colloca questo problema all’item ASI03, Identity and Privilege Abuse: catene di delega, credenziali ereditate e attribuzione debole abilitano privilege escalation e confused deputy. Per la prova in giudizio l’attribuzione è il punto di rottura: se cinque agenti hanno operato sotto lo stesso service account, dimostrare chi ha fatto cosa diventa congettura. La direzione tecnica indicata dal framework OWASP va verso la Non-Human Identity per-agente, con credenziali a vita breve, workload attestation runtime e policy legata al singolo task.

  1. Metodologia Daubert-grade

Il quarto pilastro è già parzialmente riconosciuto dalla giurisprudenza italiana, ma chiede di essere esteso. La sentenza Cozzini (Cass. pen., Sez. IV, 17 settembre 2010, dep. 13 dicembre 2010, n. 43786) ha portato nel sistema italiano i criteri Daubert (testabilità, sottoposizione a peer review, tasso di errore noto, accettazione nella comunità scientifica), seppur, secondo costante dottrina, come criteri di valutazione e non di pura ammissibilità.

La perizia su un agente AI, per essere Daubert-grade, deve poter rispondere a quesiti operativi: il sistema è stato sottoposto a red-teaming documentato? Esistono protocolli di replay deterministici per ricostruire una decisione passata? Qual è il tasso di errore misurato e su quale base di test? Le procedure di validazione sono pubblicate o oggetto di documentazione tecnica ispezionabile?

Sul versante peritale italiano, la traduzione operativa più asciutta del criterio è stata proposta da de Pinto attraverso la catena di auditabilità a sei anelli: identità del modello (nome, versione, build, commit hash); provenienza dell’input (origine documentata, hash SHA-256); trasformazioni (normalizzazione, tokenizzazione, pulizia); parametri (prompt template, temperatura, Top-p, iperparametri); log di inferenza (timestamp UTC, session id, risorse, chiamate API); output duale, ossia la separazione documentale fra responso grezzo della macchina e interpretazione del consulente.

Se manca anche uno solo degli anelli, la prova si indebolisce: «firma il perito, attesta la macchina, e nessuno dei due può parlare per l’altro». Sulla stessa direttrice si muove la dottrina italiana più aggiornata: Giulio Ubertis, in Perizia, prova scientifica e intelligenza artificiale nel processo penale (in S. Patti, R. Poli, a cura di, La consulenza tecnica d’ufficio, Giappichelli, 2024; anche in Sistema Penale, 2024), sostiene che la perizia, lungi dal restare “prova neutra”, è il presidio attraverso cui garantire un meaningful human control sull’uso giudiziale dell’intelligenza artificiale.

Art. 220 c.p.p. e il perito davanti a un sistema non deterministico

Sul piano interno, l’art. 220 c.p.p. è strumento sufficientemente elastico per assorbire la sfida: la formula “specifiche competenze tecniche, scientifiche o artistiche” ammette, e di fatto già accoglie, la perizia informatica forense. Il problema non è dunque normativo, ma di domanda peritale e di profilo del consulente.

Sul piano del quesito, il magistrato dovrà superare il modello “leggere il log e verificarne l’integrità”. Le domande utili a un agente AI somigliano a quelle di un interrogatorio testimoniale, rivolte però all’infrastruttura, non al modello: chi ha configurato l’autorità dell’agente al tempo dei fatti? Quali dati erano nel suo contesto? I prompt erano statici o dinamici? Esiste un protocollo di replay deterministico? Quali approvazioni umane sono intervenute? Quali guardrail erano attivi?

Un quadro simile è già delineato anche dalla prima trattazione internazionale del tema (Riper, Agentic AI as Evidence, Secretariat-JD Supra, aprile 2026), in cui il “chi”, il “cosa”, il “dove” e il “quando” non risiedono più in una narrativa umana ma sono distribuiti tra file di configurazione, prompt, log e output.

A supporto del quesito peritale è utile una check-list di allerta derivabile dalla relazione di de Pinto, articolata in cinque indicatori: non-determinismo (stesso input, output differenti in assenza di aggiornamenti documentati); overconfidence (score di confidenza prossimi al 100% su dati ambigui o degradati, sintomo di miscalibration); correlazioni spurie (decisioni fondate su feature non causalmente legate alla conclusione, da verificare con tecniche XAI quali SHAP, LIME, Grad-CAM); assenza di logging adeguato (rilevante anche ex art. 12 AI Act per i sistemi ad alto rischio); impossibilità di triangolazione con fonti indipendenti. Quando più di un indicatore si attiva, il quesito peritale deve potersi spingere alle radici metodologiche dell’output, non fermarsi alla sua plausibilità di superficie.

Sul piano del profilo, la perizia su sistemi agentic richiede competenze ibride: informatica forense classica (ISO/IEC 27037 ss., catena di custodia, hashing), telemetria distribuita (OpenTelemetry, tracing), identità e crittografia (NHI, workload attestation, firme Ed25519, attestazioni verificabili), familiarità con modelli linguistici e framework multi-agente. Un profilo oggi raro fra i CTU iscritti: ordini professionali e scuole forensi dovranno aggiornare in tempi rapidi criteri di iscrizione e percorsi formativi.

Resta sullo sfondo l’art. 189 c.p.p. (prove non disciplinate dalla legge), che condiziona l’ammissione delle tecnologie nuove all’idoneità ad assicurare l’accertamento dei fatti e al rispetto della libertà morale della persona. Per l’evidenza agentic, l’idoneità si gioca proprio sui quattro pilastri: senza schema condiviso, ricevute concatenate, identità per-agente e validazione Daubert-grade, la prova rischia di tradursi in udienza in semplice asserzione.

L’AI Act art. 12 come terreno comune europeo

Un secondo livello normativo non potrà essere ignorato. Il Regolamento (UE) 2024/1689 (AI Act), all’art. 12, impone ai sistemi AI ad alto rischio di «consentire a livello tecnico la registrazione automatica degli eventi (“log”) per la durata del ciclo di vita del sistema», con un livello di tracciabilità “adeguato alla finalità prevista”. Per i sistemi ad alto rischio, il quadro applicativo dell’AI Act rende progressivamente centrale l’obbligo di logging previsto dall’art. 12, destinato a diventare un parametro tecnico-giuridico di conformità, fra l’altro nei perimetri della giustizia, delle infrastrutture critiche, dell’occupazione e dei servizi essenziali.

Per chi distribuisce o utilizza agenti AI in ambiti regolati, l’art. 12 trasforma il forensics by design da scelta architetturale in obbligo normativo. La traduzione operativa è in via di codifica nello standard prEN ISO/IEC 24970 (AI system logging), destinato a saldare requisito europeo e prassi tecnica. Per il perito italiano è un argomento di leva forte: l’assenza di log automatici, tracciabilità per-evento e integrità verificabile in un sistema ad alto rischio non è più solo carenza tecnica, ma indizio di non-conformità regolatoria, valutabile ex artt. 192 e 530 c.p.p. nel ragionamento probatorio.

FRE 707 e prospettiva comparata: cosa imparare, cosa evitare

Negli Stati Uniti, l’Advisory Committee on Evidence Rules ha posto in consultazione pubblica, chiusa il 16 febbraio 2026, la proposta di Federal Rule of Evidence 707, che assoggetta la machine-generated evidence offerta senza testimone esperto al medesimo gatekeeping di affidabilità previsto dalla Rule 702 per la prova peritale. Il Bolch Judicial Institute di Duke Law indica un iter di adozione FRE 707 con voto in primavera 2026 ed entrata in vigore prevista a dicembre 2027. Il dibattito ha già prodotto critiche sostanziali: l’AAJ ha chiesto di restringere la formula “machine-generated” alle sole evidenze prodotte da machine learning o AI, per non travolgere geolocalizzazione, videosorveglianza e cartelle cliniche elettroniche.

Per il giurista italiano la FRE 707 è uno specchio utile su tre piani. Primo, rende espresso in un ordinamento di common law ciò che il nostro art. 220 c.p.p. già consente in via interpretativa, ossia la sottoponibilità della prova machine-generated a un controllo peritale di affidabilità. Secondo, conferma che il problema non è circoscritto al deepfake (oggetto separato del progettato emendamento alla Rule 901(c)), ma riguarda l’intera classe degli output algoritmici offerti come prova. Terzo, indica al legislatore italiano una possibile traiettoria di codificazione esplicita, peraltro non urgente: l’impianto vigente (artt. 189, 220, 260, 359-360 c.p.p., legge 48/2008, criteri Cozzini, art. 12 AI Act) appare già capiente, a condizione di essere animato da una prassi peritale all’altezza.

La chain of delegation come nuovo baricentro probatorio

Le convergenze descritte tendono a un punto comune: in un processo riferito all’operato di un agente autonomo, il fulcro non sarà il singolo log dell’azione finale, ma la catena che lega quell’azione a un principio umano. Un protocollo recente, l’Human Delegation Provenance di Helixar (IETF Internet-Draft draft-helixar-hdp-agentic-delegation-00, marzo 2026), prova a rendere verificabile in modo crittografico questa catena: un token HDP vincola un evento di autorizzazione umana a una sessione, registra ciascuna delega come hop firmato in una struttura append-only, e consente la verifica offline con la sola chiave pubblica Ed25519 dell’emittente.

Per il perito, la quaestio non è più solo “quel comando è stato eseguito davvero?” ma “quel comando, in quel punto della catena, era stato legittimamente delegato dall’umano X all’agente Y, con quale scope, in quale finestra temporale?”. Il dato di partenza non è più il bit, ma la prova di delega. Si saldano qui due triangolazioni complementari: quella orizzontale, fra fonti indipendenti, da tempo presidio del metodo forense classico; e quella verticale, lungo la catena di delega, che la natura agentic del sistema impone come ulteriore livello di verifica.

Per la difesa, il rilievo è altrettanto chiaro: senza catena di delega ricostruibile, l’imputabilità rischia di sciogliersi nel non-determinismo del modello, con conseguenze immediate sull’art. 27 della Costituzione e sulla regola del ragionevole dubbio. È la stessa questione che, sul versante dei rischi sistemici, la governance dell’AI agentica discussa da questa testata pone già da tempo.

Indicazioni operative

Quattro direzioni di lavoro chiudono il quadro.

Per la magistratura, il quesito peritale ai sensi dell’art. 220 c.p.p. dovrebbe includere, accanto alla classica acquisizione forensic-grade, la verifica dell’esistenza e dell’integrità delle ricevute concatenate, della tracciabilità conforme alle convenzioni gen_ai.
, della NHI per singolo agente e della disponibilità di un protocollo di replay. In sede di ammissione ex art. 189 c.p.p., la richiesta di documentazione Daubert-grade va resa esplicita, e l’inquadramento ex art. 359 o 360 c.p.p. va deciso valutando la mutevolezza materiale dello stato del sistema, non solo la sua copiabilità formale.

Per periti e CTU, è il momento di integrare nei capitolati le competenze su OpenTelemetry GenAI, NHI governance e crittografia delle ricevute. La catena di custodia, in ambiente agentic, è la catena di delega; i sei anelli di auditabilità ne sono il presidio quotidiano.

Per i progettisti di sistemi agentic destinati a operare in ambiti regolati (sanità, finanza, PA, giustizia), il forensics by design non è un costo opzionale: oltre a costituire requisito di conformità all’art. 12 dell’AI Act, è la condizione perché ogni futuro contenzioso si giochi su prove utilizzabili.

Per il legislatore, la lezione della FRE 707 suggerisce di non legiferare a botta calda. Gli strumenti del codice di rito penale italiano, integrati dai criteri di matrice Daubert e dagli obblighi dell’AI Act, sono capienti; un intervento mirato sarebbe utile sulle modalità di certificazione delle copie di dati agent-generated nell’art. 260 comma 2 c.p.p. e sull’introduzione di un quadro nazionale per la perizia su evidenza agentic, eventualmente in raccordo con il Tavolo permanente sulla giustizia digitale.

Resta una consapevolezza: la prima udienza italiana con un agente autonomo come fonte di prova si avvicina. La domanda non è se accadrà, ma se l’infrastruttura forense sarà pronta a reggere il contraddittorio. Se continueremo a trattare l’evidenza agentic come un semplice problema di logging, la risposta è già scritta: non reggerà.

Condividi sui Social Network:

https://www.ictsecuritymagazine.com/notizie/forensics-by-design-art-220-c-p-p-agente-ai-in-un-tribunale-italiano/