Gemini e sicurezza AI: esce dall’ambiente di test e viola tre reti aziendali
Un test progettato per misurare le capacità offensive dell’intelligenza artificiale si è trasformato in un incidente di sicurezza reale. A maggio alcuni modelli Gemini di Google hanno ottenuto accesso non autorizzato all’infrastruttura informatica di tre aziende mentre erano sottoposti a una valutazione delle proprie capacità di cybersecurity. Google ha reso noto che i modelli hanno interrotto autonomamente le operazioni dopo essersi accorti che i sistemi raggiunti appartenevano ad aziende reali e non agli ambienti simulati previsti dal test. Secondo la società, gli accessi non hanno provocato danni. L’episodio si è verificato durante attività condotte da Irregular, startup israeliana specializzata nella valutazione dei sistemi di intelligenza artificiale prima della loro distribuzione pubblica. Il caso riporta al centro una questione sempre più rilevante per l’industria: come testare le capacità cyber dei modelli più avanzati evitando che gli stessi test producano conseguenze al di fuori dei sistemi controllati.
L’errore che ha portato Gemini su sistemi reali
La dinamica descritta da Google parte da uno scenario apparentemente ordinario per questo tipo di valutazioni. Ai modelli Gemini era stato assegnato il compito di condurre un attacco informatico contro un’azienda fittizia creata appositamente per il test. Il problema è nato dal nome scelto per il bersaglio simulato, che coincideva con quello di una società realmente esistente. Parallelamente, a causa di una configurazione errata dell’ambiente di valutazione, i modelli avevano la possibilità di raggiungere internet. Gemini ha quindi iniziato a cercare il bersaglio fuori dal perimetro della simulazione. Secondo quanto riferito da Google, i modelli hanno utilizzato password reperite online o credenziali indovinate per effettuare l’accesso all’infrastruttura della società individuata e, successivamente, a quella di altre due aziende. Solo dopo essere entrati nei sistemi i modelli avrebbero riconosciuto che le infrastrutture raggiunte non appartenevano al laboratorio di prova. A quel punto le operazioni offensive sono state interrotte.
Irregular: corretta la falla nell’ambiente di testing
Irregular ha ricondotto gli incidenti alla possibilità, non prevista, concessa ai modelli di accedere a internet durante le valutazioni. In un post pubblicato ad agosto, la startup ha spiegato che questa configurazione ha portato alcuni sistemi di AI a eseguire azioni offensive su infrastrutture reali. La società ha dichiarato di avere corretto il problema che consentiva l’accesso esterno. I laboratori interessati sarebbero stati informati alla fine di luglio, mentre le organizzazioni coinvolte negli incidenti sono state contattate nel corso delle successive verifiche.
Il caso Gemini, riportato inizialmente dal Wall Street Journal, non sarebbe peraltro isolato. Durante altri test svolti quest’anno da Irregular, anche modelli sviluppati da OpenAI, Anthropic e Meta avrebbero ottenuto un accesso a internet non autorizzato.
La presenza di più episodi con sistemi appartenenti a laboratori differenti sposta quindi l’attenzione anche sulle procedure utilizzate per effettuare i test. Nel red teaming dei modelli AI, infatti, l’obiettivo è osservare il comportamento del sistema in condizioni vicine a uno scenario operativo reale senza permettere che l’esperimento superi i confini dell’ambiente controllato.
Il nodo delle capacità cyber dei modelli AI
Le nuove generazioni di modelli vengono sempre più spesso valutate anche per capire quanto siano capaci di individuare vulnerabilità, ottenere credenziali, muoversi all’interno di una rete o automatizzare parti di un attacco informatico. Sono capacità utili anche sul fronte difensivo. Un modello in grado di identificare rapidamente una vulnerabilità può aiutare un security team a correggerla prima che venga sfruttata. Lo stesso strumento, però, può diventare problematico quando opera con elevati livelli di autonomia o quando riceve accesso a risorse esterne non previste. Gli incidenti avvenuti durante i test di Irregular mostrano quanto il confine tra simulazione e mondo reale debba essere gestito con particolare attenzione. In questo caso il comportamento offensivo non sarebbe derivato da un ordine esplicito di attaccare aziende reali, ma dalla combinazione tra istruzioni formulate per uno scenario fittizio e un accesso a internet che non avrebbe dovuto essere disponibile.
Google: nessun danno alle aziende coinvolte
Heather Adkins, vicepresidente della security engineering di Google, ha spiegato che le tre organizzazioni interessate sono state informate e che Google ha collaborato con il partner incaricato dei test per modificare le procedure utilizzate nelle valutazioni.
La posizione della società è che l’accaduto dimostri la necessità di addestrare i modelli più potenti affinché operino in modo responsabile. Un elemento rilevante, nella ricostruzione fornita da Google, è proprio la decisione dei modelli di interrompere l’attività dopo avere riconosciuto di trovarsi all’interno di sistemi reali.
Rimane però aperto il problema precedente: i modelli erano riusciti a raggiungere quelle infrastrutture, trovare o dedurre credenziali utilizzabili ed effettuare l’accesso.
I test di sicurezza diventano un banco di prova per l’AI
L’episodio arriva mentre nel settore cresce il confronto sui rischi collegati a sistemi sempre più autonomi. Dario Amodei, CEO di Anthropic, è tra le figure dell’industria che hanno chiesto maggiore cautela nello sviluppo dell’intelligenza artificiale. Altri dirigenti, tra cui il CEO di Nvidia Jensen Huang, sostengono invece che la ricerca debba continuare senza rallentamenti generalizzati. Gli incidenti registrati da Irregular aggiungono un elemento concreto alla discussione. Prima ancora di interrogarsi su scenari teorici di perdita di controllo, laboratori e società di sicurezza devono risolvere un problema molto pratico: costruire sandbox realmente isolate, controllare le autorizzazioni concesse agli agenti AI e verificare che un test offensivo non possa trasformarsi, per un errore di configurazione, in un attacco a un sistema esterno. Per chi sviluppa modelli capaci di operare autonomamente nel dominio cyber, la qualità dell’ambiente di testing sta diventando importante quanto le capacità del modello sottoposto alla prova.
