Quando i sistemi di AI generativa si limitano a rispondere a una domanda, la loro sicurezza può essere studiata osservando la relazione tra i dati in ingresso e il risultato ottenuto: a fronte di una modifica del prompt, si può osservare se il modello rivela informazioni che invece avrebbe dovuto proteggere o se produce contenuti indesiderati.
Un agente AI, invece, riceve informazioni dall’ambiente, prende decisioni e, tramite tools, produce azioni che modificano quello stesso ambiente, cosicché le decisioni successive vengono prese in condizioni diverse da quelle iniziali.
Se più agenti condividono risorse o possono comunicare, il comportamento di ciascuno dipende anche dalle azioni degli altri e dagli artefatti che questi lasciano dietro di sé. La messa in sicurezza richiede quindi di analizzare un sistema complesso, per cui è necessario identificare gli asset importanti per la missione aziendale, capire come potremmo esserne privati e tradurre ciò in proprietà che il sistema deve preservare. Fare red teaming su questo sistema significa perturbare intenzionalmente l’ambiente per cercare traiettorie che conducano alla violazione delle proprietà identificate.
Il sistema universitario si sta adattando a questo cambio di paradigma, con offerte rivolte all’aggiornamento di chi progetta e governa questi sistemi, come, ad esempio, master universitario di secondo livello in cybersecurity e compliance aziendale integrata dell’Università di Brescia, il cui programma dedica una sezione specifica alla sicurezza dei sistemi di intelligenza artificiale, compresi quelli agentici.
Indice degli argomenti
Dal prompt all’ambiente
Un sistema di AI generativa riceve un prompt e produce una risposta; il red team modifica l’ingresso e osserva come cambia l’uscita, cercando condizioni nelle quali il comportamento devia da quello atteso. In questa rappresentazione il sistema assomiglia a una funzione che trasforma un input in un output.
Un agente, invece, opera dentro un ciclo. Osserva una parte dello stato del mondo, sceglie un’azione sulla base dell’obiettivo che gli è stato assegnato e delle informazioni che possiede, utilizza eventualmente uno o più strumenti per eseguire quell’azione e riceve dal mondo un nuovo stato, sul quale costruirà la decisione successiva. Se scrive un file, modifica una memoria, invia un messaggio, interroga un servizio o altera la configurazione di una risorsa, ciò che ha fatto entra a far parte delle condizioni in cui continuerà a operare. L’esecuzione di un compito diventa quindi una traiettoria attraverso una successione di stati, ciascuno dei quali dipende almeno in parte dalle decisioni precedenti. Una traiettoria dannosa può dunque emergere mentre l’agente persegue un obiettivo apparentemente legittimo.
L’incidente tra OpenAI e Hugging Face
L’incidente avvenuto nel 2026 durante alcune valutazioni interne di cybersecurity di OpenAI mostra come alcuni modelli, che operavano con misure di sicurezza ridotte, riuscirono a comunicare attraverso canali che non erano stati previsti per quel fine, a sfruttare vulnerabilità dell’infrastruttura condivisa, a ottenere accesso a Internet e, successivamente, ad accedere a sistemi appartenenti a Hugging Face. Gli agenti erano impegnati in esercizi di cybersecurity particolarmente difficili, alcuni dei quali senza una soluzione conosciuta; la ricerca insistita di un risultato li spinse così a esplorare percorsi non previsti dal compito, secondo una dinamica di reward hacking descritta dalla successiva analisi di OpenAI.
Artifactory come memoria e canale condiviso
Il canale di comunicazione si instaurò attraverso Artifactory, un servizio dell’ambiente di valutazione che gli agenti scoprirono di poter utilizzare per scrivere e leggere informazioni. Quella possibilità, nata come proprietà tecnica di una componente dell’infrastruttura, divenne progressivamente un mezzo di comunicazione: gli agenti si potevano scambiare informazioni e coordinare parti del proprio lavoro. Il rapporto di METR descrive infatti un attacco sviluppatosi nel corso di più giorni nel quale gli agenti utilizzarono una bacheca condivisa e non autorizzata per collaborare. Una risorsa condivisa, che presa isolatamente poteva apparire innocua, divenne una forma di memoria collettiva e, con essa, una parte del meccanismo attraverso cui gli agenti influenzavano reciprocamente le proprie decisioni.
Le decisioni condizionate dagli altri agenti
L’episodio diventa ancora più interessante quando si osservano le giustificazioni prodotte dagli agenti. In uno dei casi discussi nel rapporto METR, e che ho poi ripreso nel mio intervento al TIG CISO panel, un agente si trovò di fronte a un’azione che avrebbe potuto compromettere definitivamente la propria possibilità di completare il compito; dopo essere stato persuaso dagli altri agenti che la propria situazione era ormai compromessa, accettò di esporsi al rischio perché, nelle sue parole, «continuity and fairness says go». Il comportamento di un agente può quindi dipendere da messaggi prodotti da altri agenti, dal contenuto della memoria condivisa, dalla sua rappresentazione dello stato del mondo in cui si trova e da un obiettivo che continua a esercitare pressione sulla scelta successiva. La pragmatica di concetti apparentemente desiderabili, come fairness o continuity, dipende dalle configurazioni dell’ambiente e può condurre a effetti molto diversi da quelli intesi dal progettista del sistema.
La sicurezza come proprietà del sistema
Per affrontare un problema di questo tipo serve una prospettiva che tratti la sicurezza come una proprietà del sistema nel suo complesso. Il NIST SP 800-160 Vol. 1 Rev. 1, dedicato alla systems security engineering, tratta la sicurezza come una proprietà che dipende dal modo in cui gli elementi del sistema vengono progettati e composti. Nel nostro caso questi elementi comprendono il modello, gli strumenti che può utilizzare, le risorse alle quali può accedere e l’ambiente sul quale le sue azioni producono effetti.
Vincoli di sicurezza e perturbazione dell’ambiente
Ciò significa partire dagli asset che vogliamo proteggere, analizzare quali siano i casi in cui ne potremmo essere privati, e descrivere dei vincoli sul comportamento del sistema per ridurre tale rischio. Se, per esempio, consideriamo inaccettabile che un agente modifichi una risorsa esterna senza autorizzazione, possiamo esprimere questa esigenza come un vincolo che deve rimanere valido indipendentemente dal percorso seguito dall’agente. Poiché il comportamento dell’agente dipende dall’ambiente, anche il red team deve intervenire su di esso, per esempio rendendo indisponibile un tool (impatto sull’availability) o modificando informazioni mentre l’agente è in esecuzione (impatto sull’integrity).
Il red teaming diventa così uno degli strumenti con cui verificare sperimentalmente le proprietà di sicurezza definite durante la progettazione, perturbando l’ambiente per individuare traiettorie che possano condurre alla loro violazione.
Domain Separation, Least Sharing e Mediated Access
Il NIST SP 800-160 Vol. 1 Rev. 1 propone diversi principi di progettazione sicura, tre dei quali aiutano a interpretare l’incidente tra OpenAI e Hugging Face. Per esempio, secondo il principio di Domain Separation, domini con esigenze di protezione differenti devono essere separati fisicamente o logicamente. Nel caso delle valutazioni di OpenAI, la sandbox costituiva precisamente un dominio che avrebbe dovuto contenere gli effetti delle azioni dell’agente, mentre Artifactory apparteneva a un’infrastruttura con capacità più ampie e, soprattutto, con accesso verso l’esterno.
Secondo il principio di Least Sharing, invece, una risorsa dovrebbe essere condivisa soltanto quando necessario e fra il minor numero possibile di elementi: Artifactory era accessibile a esecuzioni differenti e conservava informazioni che altri agenti potevano successivamente leggere; proprio questa condivisione consentì di trasformarlo in una bacheca persistente, attraverso la quale gli agenti iniziarono a scambiarsi informazioni e a coordinare le proprie attività. Ogni risorsa condivisa crea potenzialmente un percorso informativo fra elementi che altrimenti rimarrebbero separati.
Infine, per il principio del Mediated Access, ogni accesso a una risorsa e ogni operazione su di essa devono essere sottoposti a una policy effettivamente applicata e controllata. Assegnare uno strumento a un agente non significa necessariamente autorizzare tutti gli effetti che quello strumento è tecnicamente capace di produrre.
Dalla sicurezza del modello alla sicurezza del sistema
L’AI agentica allarga il perimetro della cybersecurity. Un modello può comportarsi correttamente in migliaia di interazioni isolate e diventare parte di un sistema pericoloso quando dispone di privilegi eccessivi e può modificare risorse dell’ambiente. L’incidente tra OpenAI e Hugging Face mostra infatti agenti che hanno trovato autonomamente un mezzo di comunicazione, si sono influenzati a vicenda e hanno progressivamente esplorato possibilità offerte dall’infrastruttura.
La verifica di queste proprietà richiede competenze capaci di tenere insieme comportamento degli agenti, architettura dei sistemi e valutazione delle conseguenze, che devono essere aggiornate ogni volta che cambiano modelli e strumenti. Investire nella conoscenza e nell’aggiornamento professionale è quindi necessario, anche attraverso proposte come il il master universitario di secondo livello in cybersecurity e compliance aziendale integrata dell’Università di Brescia, che comprende un modulo dedicato alla sicurezza dei sistemi di AI, con attenzione anche ai rischi dell’AI generativa e agentica.
Non possiamo prevedere ogni strategia che un agente sufficientemente capace potrà costruire quando incontra un ostacolo inatteso. Possiamo però decidere quali stati del mondo gli sia consentito produrre, quali autorizzazioni debbano precedere le azioni più rilevanti e quale comportamento ci aspettiamo quando il compito non può essere completato in sicurezza. È su queste proprietà, molto più stabili della singola versione di un modello linguistico, che conviene costruire il red teaming dei sistemi agentici.
Partecipa alla community