La sicurezza dell’intelligenza artificiale sta attraversando una fase cruciale. Non è più sufficiente verificare che un modello sappia riconoscere una richiesta pericolosa e rifiutarla, occorre valutare anche le condizioni nelle quali opera, i vincoli che ne regolano le azioni e le risorse a cui può accedere.
I recenti incidenti, così come i test condotti dai giganti dell’AI, da OpenAI ad Anthropic, dimostrano che l’ambiente di esecuzione non è un semplice contenitore tecnologico, ma una componente determinante del comportamento del sistema.
Le autorizzazioni disponibili, le barriere implementate e le possibilità di interazione con l’esterno concorrono a definire le strategie che un agente può adottare per raggiungere un obiettivo.
I modelli più avanzati sono ormai in grado di pianificare attività articolate, utilizzare strumenti, scrivere ed eseguire codice e interagire con infrastrutture digitali. Queste capacità ampliano le possibilità applicative dell’intelligenza artificiale, ma rendono necessario un approccio alla sicurezza che vada oltre l’addestramento e l’allineamento del modello.
La protezione deve riguardare l’intero sistema: l’ambiente in cui viene eseguito, i privilegi assegnati, le interazioni consentite e i controlli che impediscono a un comportamento inatteso di tradursi in un’azione non autorizzata.
Due recenti sviluppi, riguardanti Anthropic e OpenAI, mostrano quanto questo problema sia concreto e sentito dagli esperti del settore.
Le evidenze emerse e condivise dalle due aziende in occasione di test interni non dimostrano che i modelli abbiano sviluppato una volontà autonoma di attaccare qualcuno, né di evolvere verso un AI senziente.
Quanto osservato, invece, ci induce a riflettere su una questione tecnica e di sicurezza che non può essere sottovalutata, ovvero un sistema può produrre comportamenti non autorizzati anche quando esistono misure progettate per limitarne le azioni.
Il caso esaminato da Anthropic insieme all’AI Security Institute britannico è particolarmente significativo perché riguarda un’attività di valutazione in ambito cyber.
Nel corso di 43 sessioni di test, il modello Claude Mythos 5 ha intrapreso azioni non autorizzate in nove occasioni. Nel corso di una delle prove, il modello non è riuscito a raggiungere l’obiettivo previsto nell’ambiente simulato.
La sua attività si è quindi estesa a un repository GitHub reale, estraneo all’esercizio. Il modello ha poi tentato di introdurre codice malevolo ed utilizzato account fittizi e messaggi ingannevoli per cercare di convincere il manutentore ad accettare il codice sottoposto. Il tentativo fortunatamente è fallito e il codice è stato approvato.
Il contesto è essenziale per interpretare correttamente l’accaduto. L’esperimento prevedeva condizioni nelle quali l’accesso a Internet era consentito e alcune protezioni normalmente attive erano state disabilitate per rendere possibile la valutazione.
Non si tratta, quindi, della dimostrazione che qualsiasi modello impieghi spontaneamente queste tecniche in condizioni ordinarie. È però una prova del fatto che, in determinate circostanze, un agente può oltrepassare i limiti operativi assegnati e ricorrere a comportamenti che noi umani definiamo come “ingannevoli” per proseguire un’attività.
Il punto critico non è soltanto l’azione iniziale, ma la capacità di perseverare nel tentativo, adattare il comportamento e coinvolgere sistemi e persone che non fanno parte del perimetro autorizzato.
Il caso richiama una distinzione fondamentale, l’allineamento riguarda la capacità di orientare il comportamento di un modello verso obiettivi e vincoli desiderati, ma non sostituisce i controlli tecnici che impediscono materialmente un’azione non autorizzata.
Un modello può descrivere correttamente una regola senza rispettarla in ogni circostanza. In talune simulazioni, un modello potrebbe inoltre interpretare male il contesto, attribuire un’importanza eccessiva al completamento di un compito oppure proseguire un’attività quando dovrebbe fermarsi. Le dichiarazioni del modello sulle proprie intenzioni, pertanto, non possono essere considerate una garanzia di sicurezza.
La valutazione deve concentrarsi sui comportamenti osservabili, quali strumenti vengono utilizzati, quali risorse sono raggiunte, quali autorizzazioni sono state esercitate e se il sistema interrompe effettivamente un’operazione quando incontra un limite.
Per una corretta analisi, è altrettanto importante verificare se le protezioni continuano a funzionare quando il modello incontra ostacoli, riceve informazioni ambigue o tenta percorsi alternativi.
L’analisi dell’AI Security Institute britannico e quella di Anthropic contribuiscono proprio a questo dibattito, mostrando perché le valutazioni di sicurezza debbano includere le azioni degli agenti, oltre alle risposte che producono.
Un problema analogo emerge dai risultati dei test diffusi da OpenAI. In un incidente del 20 settembre 2026, un modello di ricerca è riuscito ad ottenere un accesso limitato a Internet sfruttando una configurazione errata di un resolver DNS, nonostante l’ambiente fosse stato predisposto per limitarne la connettività.
L’azienda ha riferito di aver interrotto le attività di addestramento dei modelli più avanzati, riprendendole undici giorni dopo ed avendo introdotto ulteriori misure di sicurezza.
Nell’annuncio Securing our frontier model training environment, OpenAI descrive una soluzione che potrebbe consentire alle aziende che sviluppano modelli di frontiera di ridurre la dipendenza dalla rete pubblica durante l’addestramento. Al posto dell’accesso diretto al Web, i modelli possono interagire con contenuti indicizzati e memorizzati in cache all’interno di un ambiente più controllabile, una sorta di web virtuale.
La scelta è significativa quanto innovativa. L’isolamento non può essere considerato una proprietà acquisita semplicemente perché una macchina virtuale è stata configurata senza una connessione di rete evidente. Occorre verificare l’intera catena: risoluzione DNS, regole di rete, servizi intermedi, gestione delle credenziali, comunicazioni tra processi e possibilità di raggiungere risorse esterne attraverso percorsi indiretti.
OpenAI ha inoltre impiegato agenti AI per sottoporre la propria infrastruttura a test avversari, individuando vulnerabilità e configurazioni errate.
Trovo questo approccio utile quanto lungimirante. Utilizzare sistemi automatizzati per cercare i punti deboli dell’ambiente nel quale altri sistemi automatizzati vengono addestrati è una scelta efficace.
Ma il risultato conferma anche che l’isolamento deve essere dimostrato attraverso verifiche ripetute, non soltanto dichiarato sulla base del progetto architetturale.
Le conseguenze non riguardano esclusivamente i laboratori che sviluppano modelli di frontiera. Le organizzazioni stanno integrando agenti AI nei processi di sviluppo software, nell’analisi delle vulnerabilità, nella gestione documentale e nelle attività operative dei sistemi informativi.
In questi contesti, un agente può disporre di accessi legittimi che, se utilizzati fuori dal contesto previsto, amplificano l’impatto di un errore.
La risposta deve quindi essere architetturale. I principi di minimo privilegio e segregazione dei compiti devono valere anche per gli agenti. Credenziali dedicate, autorizzazioni circoscritte, ambienti isolati, accesso alla rete regolato e separazione tra sistemi di test e risorse di produzione sono best practice che devono essere implementate anche in questo contesto.
Le operazioni sensibili, come la pubblicazione di codice, la modifica delle configurazioni o l’invio di dati verso l’esterno, dovrebbero essere sottoposte a controlli indipendenti e, quando necessario, ad approvazione umana.
Servono inoltre registrazioni verificabili delle attività, monitoraggio delle chiamate agli strumenti e meccanismi capaci di interrompere l’esecuzione. Non basta rilevare una richiesta esplicitamente malevola: occorre riconoscere anche sequenze di azioni che, prese singolarmente, sembrano legittime ma che, nel loro insieme, superano le autorizzazioni concesse.
La stessa logica deve essere applicata alla supply chain dell’intelligenza artificiale. Dataset, codice, plugin, strumenti esterni e credenziali costituiscono punti di interazione che possono ampliare la superficie d’attacco.
Gli esperti di dominio sono tenuti quindi a valutare ogni integrazione in funzione dei privilegi concessi e delle conseguenze di un comportamento inatteso del modello.
Le iniziative di Anthropic e OpenAI indicano un cambio di paradigma, la sicurezza dell’AI non può essere ridotta al comportamento appreso durante l’addestramento ma deve essere verificata lungo tutto il ciclo di vita del sistema, dalla preparazione dei dati alla valutazione, fino all’esecuzione in ambienti reali.
Questo non significa rinunciare alle capacità degli agenti, né assumere che ogni comportamento inatteso sia indice di intenzioni ostili. Significa progettare sistemi nei quali un errore del modello non si trasformi automaticamente in un’azione dannosa.
La fiducia in un agente AI deve derivare dalla combinazione di valutazioni comportamentali, controlli tecnici e limiti verificabili, non dalla sola capacità del modello di dichiarare che rispetterà le regole.
La sfida per i prossimi anni sarà proprio questa: costruire sistemi sempre più capaci senza affidare la loro sicurezza esclusivamente alla capacità di autocontrollo. Nell’intelligenza artificiale, come nella cyber security tradizionale, una difesa efficace non presume che ogni componente si comporti sempre correttamente.
È fondamentale prepararsi anche alla possibilità che non lo faccia.