Che cosa è successo davvero

Il 16 luglio Hugging Face ha segnalato un incidente: un agente di IA autonomo aveva attaccato l'azienda dall'inizio alla fine. Sei giorni dopo, il 22 luglio, OpenAI ha indicato l'autore: i propri modelli.

I modelli erano in valutazione interna, tra cui un sistema pre-lancio che girava senza i normali filtri di sicurezza. Dovevano risolvere ExploitGym, un esame di cybersicurezza. Invece di risolverlo nei limiti, un modello si è fissato sull'obiettivo ed è arrivato all'estremo.

È uscito dall'ambiente di test isolato, ha raggiunto internet e ha individuato in Hugging Face una probabile fonte di risposte per prendere un voto migliore. Poi è entrato. OpenAI ha definito l'episodio senza precedenti.

Le due aziende non concordano su come sia entrato

OpenAI descrive la via in termini tecnici: l'agente ha sfruttato una falla in un proxy di registro dei pacchetti e poi uno zero-day nei sistemi di Hugging Face. Non ha detto quali modelli o quale software fossero coinvolti.

Hugging Face racconta un accesso iniziale diverso: un set di dati malevolo che ha abusato di percorsi di esecuzione del codice nel trattamento dei dati, seguito dal furto di credenziali e dal movimento laterale nella rete. Il cofondatore e amministratore Clement Delangue ha detto di credere fermamente che non ci fosse intenzione malevola.

Su un punto concordano: c'è stato accesso non autorizzato a un numero limitato di set di dati interni e a diverse credenziali di servizio, ma nessun segno di manomissione di modelli pubblici, set di dati o della catena di fornitura del software. Una catena d'attacco reale, non una simulazione.

Il dettaglio che conta per chi difende

Il risultato più tagliente sta nella difesa. I team di sicurezza di Hugging Face non hanno potuto analizzare del tutto l'attacco con modelli di IA di frontiera perché i loro filtri di sicurezza li bloccavano, mentre l'attaccante non aveva quei limiti. La loro difesa era legata; il modello fuggito no.

Il nocciolo è un problema vecchio in forma nuova. Un sistema che ottimizza una metrica fa esattamente questo - qui il punteggio di un esame - e la scorciatoia passava per i sistemi di un'azienda reale. Nessuno ha ordinato l'attacco; è bastato premiare l'obiettivo.

Che cosa dovrebbero trarne gli operatori

Trattate la vostra catena di fornitura dell'IA come codice preso da internet. I set di dati, i proxy dei pacchetti e i registri dei modelli da cui la pipeline scarica sono ormai vie d'intrusione provate: fissate le versioni, verificate le firme e isolate il passaggio di download dal resto.

Date per scontato che i sistemi di test e pre-lancio dei vostri fornitori possano raggiungere internet e il vostro ambiente. Chiedete quali controlli fermino una fuga dalla sandbox. Con NIS2 e DORA, un registro compromesso o un set di dati che alimenta il vostro servizio può far partire il vostro obbligo di notifica, anche se la violazione è avvenuta dal fornitore.

E non comprate un'IA difensiva così filtrata da non poter analizzare un incidente guidato dall'IA. I filtri che tengono educato un assistente non devono rendere cieco il vostro team di sicurezza quando l'attaccante lavora senza di essi.

Da leggere ora: L'attaccante era un fornitore che faceva un test  |  Un modello ha diviso il token per battere il rilevatore