Fireworks AI, piattaforma statunitense per l'esecuzione e il fine-tuning di modelli linguistici, ha pubblicato il 9 novembre un aggiornamento che allarga in modo significativo la portata di un incidente iniziato a ottobre. Non è un caso isolato: secondo Wiz, a ottobre almeno nove piattaforme per sviluppatori di intelligenza artificiale hanno dichiarato violazioni, e il filo comune è sempre lo stesso, cioè le credenziali. Per chi in Italia usa servizi di questo tipo, la lezione non riguarda un singolo fornitore ma il modo in cui custodiamo i segreti che affidiamo alle piattaforme.

Cosa è successo

La cronologia, ricostruita dal bollettino dell'azienda e dalle analisi di terzi, comprende due eventi distinti che conviene non confondere.

Il 6 ottobre Fireworks ha rilevato l'uso improprio di credenziali interne. Gli autori hanno letto le variabili d'ambiente dei job di valutazione in un numero limitato di account clienti, dove i clienti stessi avevano salvato chiavi API e token come segreti. Le notifiche ai clienti sono partite il 7 ottobre; nei giorni successivi sono state revocate chiavi utente, credenziali dei dipendenti e token degli account di servizio. In questa prima fase l'azienda dichiarava di non aver trovato prove di accesso a modelli, dataset o traffico di inferenza e non aveva ancora chiarito come fossero state ottenute le credenziali interne.

Il secondo evento è del 23-24 ottobre. Il fornitore cloud che ospita le macchine di ricerca e sviluppo di Fireworks, non identificato, ha subito un incidente di sicurezza, e una parte non autorizzata ne ha approfittato per entrare nelle macchine di sviluppo ed eseguire un carico di lavoro non autorizzato. L'attività è stata rilevata lo stesso giorno. L'aggiornamento del 9 novembre indica che l'esposizione include identificativi e descrizioni delle risorse, indirizzi di fatturazione e spedizione, fatture, storico dei pagamenti, saldi e utilizzo del credito. Per alcuni clienti sarebbero stati raggiunti anche una parte di pesi di modelli incompleti e dei dataset. Fireworks afferma di non conservare i numeri delle carte di pagamento e di non avere rilevato impatti su Inference, Training SDK e Nexus, che per impostazione predefinita non conservano dati.

Va notato lo scarto tra le due comunicazioni: la prima parlava di nessuna evidenza di accesso a modelli e dataset, la seconda ammette un accesso parziale. È un esempio tipico di come il perimetro di un incidente si precisi nel tempo, e per i clienti significa non considerare chiusa la questione sulla base del primo comunicato. L'indagine è ancora in corso, con il supporto di Unit 42 di Palo Alto Networks e la segnalazione alle forze dell'ordine.

Il contesto: LLMjacking e il mercato delle chiavi

Fireworks ritiene che dietro ci sia un gruppo con motivazione economica, interessato a rivendere accesso non autorizzato a modelli linguistici tramite gateway di instradamento illeciti, fenomeno noto come LLMjacking. L'analisi di Wiz sull'ondata di ottobre rende il quadro concreto: in due casi di chiavi Amazon Bedrock compromesse, il primo tentativo di utilizzo è arrivato entro 30 minuti dall'accesso alla credenziale, con una chiamata di validazione. Un caso ha generato circa 800.000 chiamate in 30 ore, l'altro circa 1,7 milioni in 13 ore da un singolo indirizzo, per un consumo che a prezzi di listino vale probabilmente oltre 100.000 dollari. Wiz collega l'attività a operatori che rivendono capacità di calcolo rubata, senza però stabilire un legame diretto con le singole compromissioni iniziali. Diversi fornitori coinvolti segnalano inoltre indizi di attacchi condotti da sciami di agenti automatizzati, un elemento che riduce ulteriormente il tempo tra furto e abuso.

Il punto operativo è semplice: una chiave rubata viene sfruttata in minuti, non in giorni. La rotazione tempestiva conta più di qualsiasi analisi a posteriori.

Cosa significa per le aziende italiane

Il primo errore da evitare è pensare che l'incidente riguardi solo chi usa Fireworks. Quasi ogni azienda che ha adottato strumenti di IA generativa ha affidato a una o più piattaforme esterne chiavi API di altri servizi: cloud, database, repository, sistemi di pagamento. Una piattaforma che custodisce segreti di terzi è un moltiplicatore di rischio, perché una singola credenziale interna compromessa apre l'accesso a molti segreti dei clienti. Ed eliminare un segreto dalla piattaforma non lo rende inutilizzabile: solo chi lo ha emesso può revocarlo.

Il secondo punto è la catena di fornitura. In questo caso la porta d'ingresso della seconda fase è stata un fornitore cloud a monte, e l'azienda cliente non ha alcuna visibilità sui controlli di quel fornitore. È lo scenario che la direttiva NIS2 mette al centro con l'obbligo, per i soggetti essenziali e importanti, di gestire il rischio della catena di approvvigionamento tra le misure dell'articolo 21; per gli enti finanziari il regolamento DORA chiede un presidio analogo sui fornitori ICT di terze parti, con registro dei contratti e valutazione della concentrazione. Se nella vostra organizzazione i servizi di IA sono stati adottati dai singoli reparti senza passare dagli acquisti o dalla sicurezza, quel registro probabilmente non li contiene: ed è il primo gap da chiudere.

Il terzo punto è il GDPR. Se tra i segreti o nei dataset caricati sulla piattaforma c'erano dati personali, la violazione ricade tra i casi da valutare ai sensi degli articoli 33 e 34: il titolare deve notificare al Garante entro 72 ore da quando ne è venuto a conoscenza, e il fornitore, in qualità di responsabile del trattamento, deve avvisarlo senza ritardo. La notifica del fornitore è dunque il momento da cui far decorrere i termini, e va documentata. Anche i dati di fatturazione, che qui risultano esposti, sono dati personali quando riferiti a persone fisiche o ditte individuali, e questo è frequente nelle PMI e tra i professionisti.

Per una PMI italiana il rischio concreto è doppio: da un lato l'abuso delle chiavi con costi imprevisti, dall'altro l'accesso ai sistemi collegati. Un tetto di spesa sul fornitore di modelli e un allarme sui consumi anomali sono, sorprendentemente, tra le difese più efficaci e meno costose.

Cosa fare subito

  • Verificare se la vostra organizzazione usa Fireworks e, in caso affermativo, controllare se avete ricevuto la notifica: creare nuove chiavi e ruotare presso ogni fornitore le credenziali terze elencate nella notifica, anche in assenza di segnali anomali.
  • Fare un inventario dei segreti salvati in piattaforme di IA, notebook, pipeline di valutazione e variabili d'ambiente dei job, e ruotare quelli non più necessari o troppo estesi.
  • Controllare i log dei fornitori interessati (cloud, repository, database) cercando letture, utilizzi o modifiche non autorizzate a partire dalla finestra di esposizione, e cercare chiavi, utenti o job non creati dal vostro team.
  • Assegnare ai job di valutazione e addestramento segreti con privilegi minimi, durata breve e tetti di spesa; separare le chiavi di produzione da quelle di sperimentazione.
  • Impostare avvisi di budget e di anomalia di consumo sul fornitore di modelli, per intercettare un abuso in ore invece che a fine mese.
  • Aggiornare il registro dei fornitori ICT includendo le piattaforme di IA, con clausole su notifica degli incidenti, subfornitori e localizzazione dei dati; valutare l'impatto GDPR e documentare la decisione sulla notifica.
  • Evitare di caricare dati personali o riservati su servizi non censiti, finché non esiste una valutazione del fornitore.

Perché conta oltre il singolo caso

Le piattaforme di IA concentrano oggi tre cose di grande valore: segreti, dati proprietari e capacità di calcolo costosa. Sono un bersaglio ideale per chi ha obiettivi economici, e l'ondata di ottobre mostra che gli attaccanti lo hanno capito. Per i team italiani il messaggio è trattare le identità non umane, cioè chiavi, token e account di servizio, con la stessa disciplina riservata alle password degli amministratori: inventario, privilegi minimi, scadenza e monitoraggio. Il resto, compresa la scelta del fornitore, viene dopo.