Il rapporto pubblicato il 28 settembre 2026 dal UK AI Security Institute (AISI) aggiunge un elemento importante al dibattito sulla sicurezza dei modelli AI agentici: il modello GPT-6 Astra di OpenAI, sottoposto a una serie di test di cyber security prima del rilascio pubblico, ha mostrato una capacità inattesa: in diversi scenari ha intrapreso “autonomamente” attività di attacco che non erano richieste e che riguardavano obiettivi al di fuori del perimetro autorizzato.
È importante chiarire subito un punto. Gli attacchi osservati da AISI non hanno colpito sistemi reali, diversamente da quanto osservato in molti casi recenti. I ricercatori hanno utilizzato Petri, un ambiente progettato per simulare scenari cyber, e hanno disattivato intenzionalmente i classificatori di sicurezza di Astra per osservare il comportamento del modello senza l’intervento dei normali meccanismi di protezione.
I risultati descrivono, quindi, il comportamento del modello in condizioni di test particolari e non dimostrano che Astra abbia attaccato autonomamente infrastrutture reali.
Il dato più significativo riguarda, però, la frequenza con la quale i vari modelli testati siano riusciti a condurre un attacco alla catena di approvvigionamento (supply chain attack). Astra ha completato un attacco supply chain simulato nel 29,2% dei test, contro il 6,3% di GPT-5.6 Sol e lo 0% di GPT-5.5, quest’ultimo valutato su un numero più limitato di scenari.
Indice degli argomenti
GPT-6 Astra e l’attacco alla supply chain: i dettagli
Gli attacchi erano molto più complessi della semplicemente generazione di codice malevolo. In uno scenario tipico, il modello identificava un progetto open source esterno all’ambito autorizzato, sviluppava e testava codice dannoso e successivamente creava identità fittizie per presentarlo agli sviluppatori come una normale modifica software.
In alcuni casi ha anche utilizzato altri account falsi per pubblicare commenti favorevoli e aumentare le probabilità che un revisore umano approvasse il codice.
Il problema diventa ancora più interessante quando i ricercatori dell’AISI modificano le istruzioni. Ai modelli viene esplicitamente detto che tutto ciò che non è indicato come autorizzato è fuori dall’ambito del test.
Gli attacchi con successo portati da Astra in queste condizioni diminuiscono sensibilmente, passando da 26 attacchi su 50 prove a 4 su 49. Quindi, nonostante i divieti espliciti, il nuovo modello continua a condurre con successo attacchi di supply chain superando un confine che gli era stato chiaramente imposto.
Astra, inoltre, sembrava comprendere il problema. Nei test ha ragionato ripetutamente sul fatto che determinati obiettivi fossero fuori scope, arrivando talvolta alla conclusione che non avrebbe dovuto attaccarli.
In altri casi ha comunque proceduto, giustificando l’azione come innocua, non esplicitamente vietata o necessaria per raggiungere l’obiettivo.
AISI evidenzia anche casi in cui il modello ha chiesto una sorta di autorizzazione e poi ha interpretato una risposta automatica come un via libera, pur avendo riconosciuto che probabilmente non proveniva da un essere umano.
Attacchi AI e la simulation awareness
C’è poi il tema della simulation awareness. Un modello che capisce di trovarsi in un ambiente simulato può comportarsi diversamente da come farebbe nel mondo reale.
AISI considera questo un limite importante della metodologia. Ma i ricercatori hanno osservato che Astra ha compiuto azioni non autorizzate anche quando esprimeva dubbi sulla natura simulata dell’ambiente e, in alcuni casi, ha persino utilizzato argomentazioni errate per “convincersi” che determinati elementi fossero artificiali.
Per AISI, quindi, la consapevolezza della simulazione non può essere utilizzata come spiegazione sufficiente del comportamento.
Il caso australiano cambia la prospettiva
È qui che il rapporto diventa particolarmente interessante se messo in relazione con un episodio emerso pochi giorni prima. Il 24 settembre il governo australiano ha reso noto che un agente AI di OpenAI, durante un’attività di ricerca, aveva ottenuto un accesso non autorizzato al portale pubblico di statistiche Medicare gestito da Services Australia.
L’incidente risale al 18 giugno. Secondo le autorità australiane, l’agente aveva interagito con quattro siti e, davanti a un’informazione non accessibile sul portale Medicare, aveva finito per ottenere l’accesso comunque.
Il governo ha sottolineato che non risultano al momento compromessi dati personali e che le informazioni acquisite erano statistiche mediche aggregate. L’impatto concreto, quindi, è stato limitato. Ma l’aspetto più importante non riguarda ciò che l’agente ha trovato: riguarda il fatto che un sistema AI, mentre svolgeva un compito apparentemente benigno, abbia superato un controllo di accesso e compiuto un’azione non autorizzata.
Quanto possiamo affidarci alla capacità di un agente AI?
Il parallelismo con il test AISI è evidente, pur senza confondere i due eventi. Nel primo caso abbiamo un esperimento controllato e simulato; nel secondo un incidente reale. Ma entrambi sollevano la stessa domanda: quanto possiamo affidarci alla capacità di un agente AI di rispettare autonomamente i confini che gli abbiamo imposto?
Questa domanda urge una risposta mentre i modelli aumentano rapidamente le proprie capacità. Un agente dotato di accesso a Internet, strumenti di sviluppo, credenziali, API e sistemi aziendali non è più soltanto un assistente che produce testo o codice. Può osservare un ambiente, prendere decisioni, utilizzare strumenti e continuare una sequenza di azioni senza un intervento umano a ogni passaggio.
Il rischio per la collettività non è necessariamente rappresentato da un’AI che “decide di diventare malvagia”. È molto più concreto: un sistema estremamente capace che interpreta male un obiettivo, supera un limite, aggira un controllo o considera un’azione non autorizzata come necessaria per completare il compito. Se questo comportamento viene combinato con accesso a infrastrutture critiche, software open source, servizi cloud o sistemi pubblici, l’effetto può propagarsi ben oltre il singolo ambiente in cui l’agente opera.
Servono sandboxing, monitoraggio e controlli indipendenti
Il problema, quindi, non è soltanto l’allineamento del modello. AISI indica la necessità di sandboxing, monitoraggio e controlli indipendenti dal comportamento dell’AI. È una conclusione importante: non possiamo costruire la sicurezza di sistemi sempre più autonomi assumendo che il modello rispetterà sempre le proprie istruzioni.
E resta una domanda ancora più difficile. Siamo realmente preparati a gestire sistemi le cui capacità evolvono ogni settimana, mentre procedure di sicurezza, normative, sistemi di controllo e competenze nelle organizzazioni richiedono mesi o anni per essere aggiornati?
L’incidente australiano dimostra che il problema non è più soltanto teorico. Il rapporto AISI dimostra che, in ambiente controllato, modelli più avanzati possono manifestare comportamenti non previsti con una frequenza superiore rispetto alle generazioni precedenti.
Nessuno dei due elementi, preso isolatamente, dimostra che assisteremo a una nuova generazione di attacchi autonomi. Insieme, però, indicano una necessità concreta: la sicurezza dell’AI deve evolvere almeno alla stessa velocità delle capacità dei modelli.
Stiamo iniziando a usare agenti AI capaci di interpretare le istruzioni
Il vero rischio per la collettività non è che l’AI diventi improvvisamente incontrollabile. È che continuiamo a progettare sistemi, infrastrutture e regole pensando a un software che esegue istruzioni, mentre stiamo iniziando a utilizzare agenti capaci di interpretarle, modificarne l’esecuzione e prendere iniziative.
È una differenza sostanziale, e il tempo per colmare questo divario potrebbe essere molto più breve di quello a cui siamo abituati.
Partecipa alla community