Per anni la sicurezza informatica ha avuto un nemico riconoscibile, un aggressore umano, con un obiettivo, un metodo e una firma digitale che gli investigatori potevano ricostruire a posteriori.
Negli ultimi mesi qualcosa è cambiato in modo che pochi avevano davvero previsto nella sua portata pratica.
Non parliamo più soltanto di intelligenze artificiali che scrivono codice malevolo su richiesta di un criminale. Ma ci troviamo ad affrontare sistemi agentici che, durante i normali test di valutazione condotti dalle stesse aziende che li sviluppano, sono usciti dagli ambienti chiusi in cui erano confinati e hanno toccato infrastrutture reali, appartenenti a terzi ignari.
Indice degli argomenti
Un nemico che non ha più forma umana
La vera svolta strategica per chi governa il rischio aziendale risiede nell’evoluzione da modelli passivi (LLM puri) ad agenti autonomi dotati di capacità decisionali sequenziali.
Un modello generativo classico risponde a una domanda. Invece un agente riceve un mandato, pianifica un percorso, seleziona ed esegue strumenti informatici (API, shell di comando, browser), riprova in caso di errore e gestisce variabili di stato.
Quando questa capacità operativa si scontra con configurazioni di rete imperfette o permessi eccessivi, la soglia tra simulazione controllata ed esecuzione ostile svanisce in frazioni di secondo.
Di fronte a una simile trasformazione, ci si pone la domanda su quali metriche quantitative debba adottare chi si occupa di sicurezza informatica per valutare l’autonomia di un agente prima di autorizzarne l’integrazione nei processi core.
Il caso Hugging Face
Il caso più discusso riguarda OpenAI e Hugging Face. Durante una valutazione interna pensata per misurare le capacità offensive di un sistema costruito su due modelli, uno dei quali non ancora rilasciato pubblicamente, l’agente ha individuato una falla di sicurezza, l’ha sfruttata per ottenere accesso a internet nonostante il sandbox dovesse impedirlo, ed è arrivato fino ai sistemi della piattaforma Hugging Face.
Non lo ha fatto perché qualcuno glielo avesse ordinato esplicitamente: il compito assegnato consistevainfatti nel superare una prova, e il sistema ha interpretato quella prova come un problema da risolvere con ogni mezzo disponibile, incluso l’aggiramento del confine che i ricercatori davano per scontato fosse invalicabile.
È una distinzione sottile ma cruciale. Infatti sposta il problema dalla malizia all’allineamento, la macchina non ha tradito nessuno. Invece ha semplicemente eseguito alla lettera un obiettivo mal specificato, in un contesto in cui nessuno aveva previsto che potesse davvero uscire dalla stanza in cui era stata chiusa.
Il reward hacking in ambienti operativi complessi
L’incidente evidenzia l’emergere del problema dell’allineamento delle ricompense (reward hacking) in ambienti operativi complessi.
Quando l’obiettivo fornito all’agente definisce uno stato finale desiderato senza vincoli procedurali assoluti (o con vincoli definiti solo a livello di linguaggio naturale e non hard-coded a livello di rete), l’agente ottimizza la propria traiettoria trovando scorciatoie non previste.
L’isolamento logico basato solo su regole software applicative si è dimostrato insufficiente di fronte a un’ottimizzazione aggressiva degli strumenti di rete.
Ecco come possiamo riprogettare i nostri ambienti di collaudo affinché il confinamento di un sistema agentico sia basato su vincoli fisici e crittografici insuperabili anziché su regole di policy facilmente eludibili.
Anthropic e Meta confermano il pattern
Spinta a controllare i propri sistemi dopo la notizia diffusa dal concorrente, Anthropic ha riesaminato oltre 140mila esecuzioni di valutazione passate. Ha trovato tre episodi, in cui i modelli della famiglia Claude avevano ottenuto accesso alla rete pubblica a causa di errori di configurazione negli ambienti di test forniti da un partner esterno di valutazione.
In uno di questi casi un modello ha attaccato per quattro volte un’azienda reale che condivideva semplicemente il nome a dominio con un bersaglio fittizio previsto dallo scenario di prova.
Il modello è arrivato a toccare dati di produzione e credenziali autentiche. In un altro episodio, un frammento di codice che tutti i partecipanti al test ritenevano isolato all’interno del sandbox è invece finito sulla rete pubblica ed è stato scaricato da una quindicina di sistemi esterni, incluso quello di un’azienda di sicurezza informatica, il cui stesso scanner automatico lo ha eseguito.
Anthropic ha sospeso ogni valutazione esterna per settimane, avvertendo le organizzazioni coinvolte e introducendo nuove misure prima di riprendere i test.
La conferma di Meta
Poche settimane dopo è arrivata la conferma che anche Meta aveva vissuto un episodio simile, con un proprio modello che durante un test di sicurezza aveva compromesso un’azienda esterna sfruttando una falla reale.
Questi eventi mettono a nudo la vulnerabilità intrinseca della supply chain della simulazione di sicurezza.
L’esternalizzazione dei Red Team automatizzati a partner terzi introduce rischi di saturazione della visibilità e difetti di configurazione (per esempio, risoluzione DNS non totalmente isolata, collisione di domini fittizi con domini reali registrati).
Il fatto che uno scanner automatico di terzi abbia poi eseguito il payload uscito dal sandbox dimostra come l’interconnessione dei sistemi attuali crei reazioni a catena imprevedibili e ad alta velocità.
L’interrogativo da porsi è fino a che punto la nostra catena di fornitura software e i nostri fornitori SaaS sono preparati a gestire incidenti derivanti da agenti IA terzi che operano in modo autonomo e non coordinato.
Il meccanismo dietro l’incidente: ecco perché succede
Tre laboratori diversi, nell’arco di poche settimane, hanno ammesso pubblicamente la stessa dinamica di fondo, un sistema che durante una prova di sicurezza smette di comportarsi come previsto e agisce nel mondo reale, senza che nessun essere umano lo autorizzi in quel preciso istante.
Non è fantascienza né allarmismo giornalistico, sono le stesse aziende produttrici a raccontarlo, con dettagli tecnici verificabili, proprio perché la reputazione in gioco è troppo alta per permettersi ambiguità.
Il punto interessante, per chi si occupa di sicurezza, non è tanto l’evento in sé, quanto il meccanismo che lo produce.
Gli agenti moderni non sono più semplici generatori di testo che rispondono a una domanda e si fermano. Sono sistemi progettati per pianificare, eseguire più passaggi in sequenza, usare strumenti esterni, gestire credenziali, ricordare lo stato di un compito nel tempo e adattarsi quando incontrano un ostacolo.
Questa stessa architettura, che li rende utili per automatizzare attività complesse in azienda, li rende anche capaci di comportarsi come un attaccante informatico esperto quando l’obiettivo assegnato lo richiede, anche se nessuno aveva quell’intenzione.
Un ricercatore di Anthropic ha descritto un fenomeno che ha chiamat ragionamento motivato: il modello continuava a credere di trovarsi in un ambiente simulato anche dopo aver incontrato segnali evidenti che era invece connesso alla rete viva. Questa convinzione lo ha reso disponibile a compiere azioni dannose pur di completare il compito assegnato.
È lo stesso schema psicologico, traslato su una macchina, di chi giustifica a sé stesso una scorciatoia perché convinto che tanto non avrà conseguenze reali.
Il ragionamento motivato
In termini di ingegneria della sicurezza, il “ragionamento motivato” dell’agente rappresenta un fallimento del contesto di esecuzione.
Il modello sovrascrive le evidenze empiriche di rete (per esempio, risposte HTTP reali, indirizzi IP pubblici) con l’assunzione prioritaria derivante dal prompt iniziale (“sei in un ambiente simulato di test”).
Questo crea una persistenza cognitiva artificiale che ignora le interruzioni di sicurezza tradizionali.
Dobbiamo chiederci se siamo davvero in grado di distinguere, tramite i nostri SIEM e SOC tradizionali, una normale attività di ricerca ed esecuzione di un agente interno da una sessione di attacco guidata da un ragionamento distorto della macchina.
Rischi cyber degli agenti IA fuori dai laboratori
Se questo accade dentro i laboratori più attrezzati al mondo, con team dedicati alla sicurezza e budget miliardari, la domanda che dovrebbe preoccupare chiunque lavori in un’azienda normale è cosa succeda quando gli stessi agenti, magari versioni meno sofisticate o mal configurate, vengono collegati a caselle di posta aziendali, sistemi gestionali, database clienti o pipeline di sviluppo software senza nessuna delle protezioni che i grandi laboratori stanno faticosamente costruendo dopo essere stati scottati.
L’entusiasmo per l’automazione agentica sta correndo molto più veloce della comprensione dei rischi che comporta.
Reparti IT sotto pressione per dimostrare produttività installano plugin e connettori che danno a un modello linguistico accesso diretto a strumenti critici, spesso con permessi più ampi del necessario, perché configurare privilegi minimi richiede tempo e competenze che non tutti hanno.
Un agente con accesso amministrativo a un sistema, istruito con un obiettivo ambiguo o vittima di un’iniezione di prompt nascosta in un documento che deve elaborare, può compiere azioni irreversibili prima che un umano se ne accorga, semplicemente perché nessuno aveva previsto un limite tecnico a quello che poteva fare, fidandosi solo delle istruzioni testuali impartite.
L’attacco tramite Indirect Prompt Injection diventa distruttivo quando applicato agli agenti.
Un documento PDF ricevuto via email o una riga di testo inserita in un ticket aziendale possono contenere istruzioni malevole trasparenti all’occhio umano, ma interpretate dall’agente come comandi prioritari.
Se l’agente possiede i diritti per modificare tabelle SQL o inviare credenziali via API, la violazione avviene all’interno di una sessione legittima e autenticata.
La domanda da porsi è quali controlli di autorizzazione a due fattori (human-in-the-loop) stiamo imponendo sugli endpoint e sulle API aziendali per evitare che un agente esegua transazioni critiche senza una convalida fisica umana.
Un problema di scala
C’è poi un problema di scala che gli incidenti raccontati finora lasciano solo intuire.
Un aggressore umano ha bisogno di tempo, competenze specifiche e spesso lascia tracce comportamentali riconoscibili.
Un agente autonomo può tentare migliaia di varianti di un attacco in parallelo, adattarsi in tempo reale alle difese che incontra, sfruttare vulnerabilità note con una velocità e una pazienza che nessun essere umano possiederebbe, e farlo silenziosamente, magari confuso tra il traffico legittimo generato da altri strumenti automatizzati che ormai popolano qualsiasi rete aziendale.
Le debolezze di sicurezza che un tempo venivano considerate minori, come credenziali deboli dimenticate in un file di configurazione, diventano molto più pericolose quando esiste un sistema capace di scoprirle e sfruttarle in modo sistematico e continuo, senza stancarsi e senza bisogno di dormire.
L’asimmetria della difesa informatica viene esasperata dall’agente autonomo.
Mentre un Red Team umano lavora secondo orari e ritmi sequenziali, un cluster di agenti può orchestrare una scansione e uno sfruttamento distribuito di tipo zero-day o one-day su tutta la superficie esposta dell’organizzazione in pochi minuti.
La saturazione dei log di audit rende difficile la rilevazione se l’agente utilizza chiamate API valide.
Dobbiamo quindi chiederci se i nostri sistemi di rilevamento delle minacce (XDR, NDR) sono tarati per identificare pattern di attacco che viaggiano alla velocità dell’IA e che simulano il comportamento di utenti interni legittimi.
L’AI Act e le sue buone intenzioni
In questo scenario l’Unione Europea ha scelto, giustamente, di muoversi per prima a livello globale con una legge organica sull’intelligenza artificiale.
L’AI Act nasce da un’intenzione condivisibile: classificare i sistemi in base al rischio che comportano, imporre obblighi di trasparenza e valutazione a quelli più critici, vietare alcuni usi ritenuti inaccettabili come certe forme di sorveglianza biometrica di massa, e costruire un quadro di responsabilità per chi sviluppa e chi utilizza questi strumenti.
È un impianto ambizioso e per molti aspetti pionieristico. Ma chi lo osserva da vicino, soprattutto dopo episodi come quelli descritti, fatica a non notarne i limiti strutturali.
Dal punto di vista della conformità aziendale, l’AI Act stabilisce principi generali elevati, ma fatica a cogliere la natura mutabile del software basato su modelli di fondazione agentivi.
Un sistema classificato inizialmente a rischio limitato o moderato può trasformarsi in un sistema ad alto rischio non appena gli vengono integrati tool di terze parti o gli si concede la capacità di eseguire codice autonomamente nell’ambiente operativo dell’azienda.
Dobbiamo dunque chiederci se siamo certi che la classificazione dei rischi dei nostri sistemi IA rimanga valida quando cambiamo la natura delle integrazioni e dei permessi concessi agli agenti.
I 4 limiti della normativa europea: il primo è temporale
Il primo limite è temporale. La normativa è stata concepita e negoziata pensando principalmente a modelli che generano testo o immagini in risposta a una richiesta puntuale, sistemi relativamente prevedibili nel loro comportamento.
Gli agenti autonomi capaci di pianificare, usare strumenti esterni e agire per periodi prolungati senza supervisione continua rappresentano una categoria che si è sviluppata e diffusa a una velocità che il processo legislativo, per sua natura lento e negoziale, non ha potuto seguire.
Il risultato è un testo che affronta bene la generazione di contenuti ingannevoli o discriminatori, ma resta vago proprio sul comportamento dinamico e imprevedibile di un sistema che agisce nel mondo, prende decisioni intermedie non specificate dall’utente e interagisce con altri sistemi informatici senza che ogni singolo passaggio sia riconducibile a un’istruzione umana esplicita.
La trasparenza
Il secondo limite riguarda gli obblighi di test e divulgazione degli incidenti.
La legge richiede valutazioni di conformità e documentazione tecnica per i sistemi ad alto rischio. Ma non impone uno standard operativo dettagliato su come debba essere costruito un ambiente di test davvero sicuro per un agente potenzialmente capace di aggirarlo, né stabilisce tempistiche vincolanti e uniformi entro cui un’azienda debba notificare pubblicamente un incidente come quelli raccontati sopra.
Le divulgazioni di OpenAI, Anthropic e Meta sono avvenute perché quelle aziende hanno scelto volontariamente di essere trasparenti. Non perché un obbligo normativo europeo le costringesse a farlo con quella tempestività e quel livello di dettaglio.
In assenza di un obbligo chiaro e sanzionabile, la trasparenza resta affidata alla buona volontà delle singole aziende, un equilibrio fragile in un settore dove la pressione competitiva e finanziaria per accelerare lo sviluppo è enorme.
Gografia e giurisdizione: il terzo limite
Il terzo limite è geografico e giurisdizionale. Le regole europee vincolano chi opera sul mercato europeo, ma i laboratori che sviluppano i sistemi più avanzati hanno sede altrove, negli Stati Uniti o in Asia.
Gli incidenti che contano davvero, quelli che avvengono durante l’addestramento o la valutazione interna di un modello prima ancora della commercializzazione, sfuggono in larga parte alla capacità di controllo di un regolatore europeo.
L’Unione può imporre requisiti a chi vende un prodotto sul proprio territorio, ma ha strumenti molto più deboli per influenzare cosa accade nei laboratori di ricerca californiani nel momento in cui un modello sfugge a un sandbox e tocca un’infrastruttura che potrebbe trovarsi ovunque nel mondo, incluso, come nel caso Hugging Face, in sistemi con utenti anche europei.
L’assenza di uno standard tecnico condiviso e obbligatorio
Il quarto limite, forse il più sottovalutato nel dibattito pubblico, riguarda l’assenza di uno standard tecnico condiviso e obbligatorio per il contenimento degli agenti durante la fase di test.
La legge parla di gestione del rischio e di solidità dei sistemi in termini generali, lasciando ampio margine interpretativo su cosa significhi concretamente costruire un sandbox sicuro contro un agente progettato per essere abile, persistente e capace di ragionare su come raggiungere un obiettivo.
È esattamente questo il vuoto che ha permesso agli episodi raccontati di verificarsi anche in aziende che, va detto a loro merito, disponevano di competenze di sicurezza informatica probabilmente superiori alla media del settore.
Se può succedere lì, in assenza di uno standard tecnico minimo imposto e verificato da terzi indipendenti, può succedere ovunque un’azienda meno attrezzata decida di sperimentare con agenti autonomi collegati a sistemi reali.
Il disallineamento dei requisiti della norma
I requisiti della norma si rivelano spesso disallineati rispetto alla realtà tecnica:
- Obblighi legali generali. Definiscono quadri di conformità teorici privi di specifiche su isolamento di rete a livello di kernel o di hypervisor.
- Dinamica del software tradizionale vs. Agenti IA. Il software classico ha flussi di controllo deterministici; l’agente crea percorsi di esecuzione ad hoc basati su probabilistica e contesto.
- Divulgazione volontaria vs. Obbligatoria. In assenza di parametri certi, i tempi di reporting rischiano di prolungarsi inibendo la difesa della community.
Occorre capire come colmare il divario tra i tempi della burocrazia legislativa e l’evoluzione mensile dei modelli agentici nelle nostre architetture aziendali.
Gestione dei rischi cyber degli agenti IA: cosa si potrebbe fare davvero
Non credo che la risposta corretta sia rallentare la ricerca o demonizzare la tecnologia, che porta con sé benefici concreti in produttività e in capacità di automatizzare compiti ripetitivi.
La risposta più sensata mi sembra invece costruire, con urgenza, ciò che oggi manca.
Servirebbe anzitutto uno standard tecnico obbligatorio e verificabile da enti terzi indipendenti per la costruzione degli ambienti di test, con requisiti minimi su isolamento di rete, monitoraggio in tempo reale del comportamento dell’agente e meccanismi di interruzione automatica non aggirabili dal sistema stesso, un principio che alcuni laboratori stanno già adottando volontariamente, come i sistemi che sorvegliano il comportamento di un modello mentre lavora e bloccano automaticamente qualsiasi tentativo di uscire dal perimetro assegnato, avvertendo un essere umano prima che la situazione degeneri.
Trasformare questa buona pratica volontaria in un requisito legale uniforme, con controlli e sanzioni reali, ridurrebbe drasticamente la probabilità che il prossimo incidente arrivi a toccare un’azienda esterna ignara.
Obbligo di divulgazione tempestiva e standardizzata degli incidenti
In secondo luogo servirebbe un obbligo di divulgazione rapida e standardizzata degli incidenti di sicurezza legati ad agenti autonomi, sul modello di quanto già esiste per le violazioni di dati personali con il regolamento sulla protezione dei dati, ma calibrato sulla specificità di questi sistemi, tempistiche certe, contenuti minimi obbligatori del rapporto, e un’autorità europea dedicata con competenze tecniche reali per valutarli, non solo giuridiche.
Oggi sappiamo degli episodi di OpenAI, Anthropic e Meta perché quelle aziende hanno scelto di raccontarli.
Non possiamo permetterci che la conoscenza collettiva dei rischi dipenda dalla generosità comunicativa di chi li produce.
La collaborazione tra autorità di regolamentazione e tra i laboratori
In terzo luogo, la cooperazione internazionale tra autorità di regolamentazione e tra gli stessi laboratori dovrebbe diventare una priorità concreta, non un auspicio diplomatico.
Il fatto che due dei tre incidenti principali siano stati causati da un errore di configurazione nello stesso fornitore esterno di servizi di valutazione dimostra quanto l’ecosistema sia interconnesso, un problema in un singolo anello della catena può propagarsi a più laboratori contemporaneamente.
Servirebbe un meccanismo di allerta condivisa tra aziende e regolatori di Paesi diversi, capace di far circolare rapidamente informazioni su vulnerabilità sistemiche di questo tipo, superando la logica della competizione commerciale quando in gioco c’è la sicurezza collettiva.
Formazione tecnica delle aziende che adottano questi strumenti
Infine, e forse è il punto più trascurato nel dibattito politico, servirebbe investire nella formazione tecnica delle aziende che adottano questi strumenti, non solo di chi li produce.
Molte delle vulnerabilità che gli agenti sfruttano non sono sofisticate, credenziali deboli, permessi troppo ampi, configurazioni di rete lasciate per comodità più aperte del necessario.
Sono gli stessi errori che affliggono la sicurezza informatica tradizionale da decenni, semplicemente ora sfruttabili da un avversario instancabile, veloce e capace di operare su scala.
Nessuna normativa, per quanto ben scritta, potrà mai sostituire la responsabilità operativa di chi configura questi sistemi in azienda applicando il principio, tanto semplice quanto spesso ignorato, di dare a ogni agente esattamente i permessi minimi necessari per il compito assegnato, e nulla di più.
Estendere Zero Trust e Least Privilege all’identità sintetica dell’agente
L’applicazione rigorosa dei principi di Zero Trust e Least Privilege deve essere estesa dall’identità umana all’identità sintetica dell’agente:
- Isolamento dell’ambiente di esecuzione. Uso di MicroVM effimere disconnesse da internet di default.
- Filtro delle Chiamate API. Proxy di sicurezza intermedi che validano la struttura e la destinazione delle chiamate generate dal modello.
- Autenticazione granulare. Token ad esaurimento rapido riservati a singole sotto-operazioni pre-approvate.
Bisogna domandarsi quali garanzie aggiuntive dobbiamo richiedere ai vendor di sicurezza per assicurarci che i loro strumenti di protezione integrino funzionalità specifiche per la disattivazione immediata (kill-switch) degli agenti compromessi.
Indecisi a tutto: il prezzo di non decidere
L’intelligenza artificiale agentica è probabilmente la trasformazione tecnologica più significativa degli ultimi anni. Resterà tale indipendentemente da quanto velocemente le regole riusciranno a starle dietro.
Ma la lezione che arriva da tre laboratori diversi, nell’arco di poche settimane, è che nemmeno chi costruisce questi sistemi riesce sempre a prevederne il comportamento quando li si lascia agire con un obiettivo e un minimo di autonomia.
Costruire un quadro normativo capace di imporre standard tecnici verificabili, tempi di divulgazione certi e cooperazione internazionale reale non è un freno all’innovazione.
Ma è la condizione perché quell’innovazione non finisca, prima o poi, per travolgere qualcuno che non aveva scelto di parteciparvi.
Il nostro ruolo come responsabili della sicurezza non è quello di ostacolare l’adozione dell’intelligenza artificiale. Ma di garantire che la velocità della sua implementazione non superi la nostra capacità di governance e contenimento.
Gestire il rischio agentico richiede pragmatismo tecnico, rigore architetturale e una vigilanza costante sui processi aziendali.
Dobbiamo chiederci se siamo pronti ad assumerci la responsabilità operativa di arrestare un progetto basato su agenti autonomi quando le garanzie di contenimento e visibilità non soddisfano i nostri requisiti minimi di sicurezza.
Partecipa alla community