La ricerca di Eclypsium mostra come l’hardware compromesso possa alterare i modelli di IA durante l’esecuzione

Eclypsium ha dimostrato come un’infrastruttura informatica compromessa possa modificare il comportamento di un modello di IA durante l’inferenza, lasciando intatti i file originali. La ricerca, pubblicata il 29 ottobre in L’IA affidabile richiede un’infrastruttura affidabile, mostra perché verificare la firma o l’hash di un file del modello non basti a garantire l’integrità del modello in esecuzione in memoria.

In una dimostrazione controllata, realizzata con il supporto di NVIDIA, i ricercatori hanno usato un’unità di elaborazione dati (DPU) compromessa, insieme a un isolamento della memoria permissivo, per modificare i pesi del modello durante l’esecuzione. Le risposte del modello sono cambiate senza modificare il modello archiviato né il servizio di inferenza. Il risultato colloca hardware, firmware e configurazione dei dispositivi all’interno del perimetro di sicurezza dell’IA.

Un modo diverso per modificare un modello di IA

Le discussioni sulla sicurezza dell’IA si concentrano spesso su prompt malevoli, dati di addestramento avvelenati e uso non sicuro degli strumenti. Questa ricerca esamina un livello più profondo: l’infrastruttura che ospita e trasferisce i parametri di un modello mentre è in esecuzione.

I pesi sono i parametri numerici che determinano le risposte di un modello. Un file valido su disco può essere caricato in memoria e successivamente modificato da un componente dotato di privilegi sufficienti. Una verifica successiva del file originale rileva ancora i byte previsti, anche se la risposta è stata generata usando uno stato alterato durante l’esecuzione.

La dimostrazione di Eclypsium ha modificato in modo visibile il risultato di un’analisi relativa a una questione geopolitica. La preoccupazione più ampia è che la manipolazione durante l’esecuzione possa influire su altri usi sensibili, tra cui la generazione di codice e le decisioni automatizzate. Queste possibilità vanno distinte dal comportamento specifico osservato in laboratorio.

Anche l’affermazione secondo cui la manipolazione sarebbe rimasta inosservata ha una portata ben definita: i controlli d’integrità del modello archiviato usati nella dimostrazione non hanno rilevato le modifiche apportate alla memoria. Ciò non dimostra che sarebbero invisibili a ogni forma di monitoraggio o analisi forense.

Le condizioni dell’attacco sono determinanti

Il test è stato condotto in un ambiente NVIDIA Grace Hopper. Il percorso di accesso diretto alla memoria dipendeva da un componente privilegiato compromesso e da impostazioni di configurazione che consentivano l’accesso a dati sensibili in memoria. I ricercatori indicano il passthrough dell’IOMMU e un isolamento PCIe permissivo tra le condizioni importanti, precisando esplicitamente che non si trattava delle impostazioni predefinite di Linux.

Un’IOMMU contribuisce a controllare a quali aree di memoria può accedere una periferica. Nella configurazione con isolamento più rigoroso testata dai ricercatori, lo stesso percorso diretto non era disponibile. Il risultato sottolinea quindi l’importanza di verificare le impostazioni effettive dell’ambiente di distribuzione, anziché presumere che una funzionalità di sicurezza installata stia applicando attivamente una barriera.

Una DPU è un processore infrastrutturale programmabile usato per servizi di rete, archiviazione e sicurezza. La sua capacità di trasferire dati in modo efficiente è preziosa, ma i privilegi che consentono di svolgere legittime funzioni infrastrutturali possono diventare pericolosi se un aggressore ottiene il controllo del componente.

La risposta di NVIDIA: verificare i confini di fiducia

Nel suo resoconto della collaborazione, NVIDIA descrive l’avvio autenticato di BlueField, la radice di fiducia basata sull’hardware, l’isolamento, le protezioni per gli aggiornamenti del firmware e l’attestazione. Sottolinea inoltre che gli operatori cloud scelgono configurazioni di sicurezza diverse in funzione dei rispettivi modelli di fiducia.

Il messaggio delle aziende è che gli operatori hanno bisogno di elementi concreti per valutare queste scelte. I controlli di accesso alla memoria, l’isolamento dei dispositivi e le interfacce di gestione devono essere valutati nel contesto del modello di minaccia dell’ambiente di distribuzione. La sola disponibilità di una funzionalità non dimostra che sia configurata correttamente.

NVIDIA ed Eclypsium descrivono inoltre il problema come una questione che va oltre un singolo fornitore. I sistemi di IA dipendono da software privilegiato sull’host, firmware degli acceleratori, controller di gestione e meccanismi di trasferimento dei dati. I percorsi specifici variano a seconda dell’architettura, ma resta necessario tenere conto di questi componenti.

Perché la sicurezza degli agenti dipende anche dalla sicurezza dell’infrastruttura

La posta in gioco aumenta quando un modello può usare strumenti, accedere ai dati aziendali o avviare azioni. La manomissione dell’infrastruttura può compromettere le ipotesi su cui si basano le protezioni a livello applicativo riguardo a quale modello sia effettivamente in esecuzione.

La piattaforma aperta per la sicurezza degli agenti di NVIDIA illustra un approccio a più livelli. OpenShell offre il controllo in fase di esecuzione, mentre NVIDIA Sentry su BlueField opera da un dominio di sicurezza isolato a livello hardware, esterno all’host e all’agente. L’architettura mira a monitorare il comportamento e applicare le regole da un punto di controllo separato.

Questa posizione indipendente comporta un’ulteriore responsabilità in materia di sicurezza: l’hardware di applicazione dei controlli e il relativo stack software devono a loro volta rimanere affidabili. Spostare un controllo al di fuori dell’applicazione riduce una dipendenza, ma rende ancora più importante verificare il componente a cui è affidato.

Dall’inventario hardware alla garanzia continua

Eclypsium definisce «lacuna nelle garanzie sull’infrastruttura AI» la discrepanza tra le garanzie incentrate sui modelli e l’integrità dell’infrastruttura. La sua piattaforma di verifica dell’infrastruttura inventaria i componenti, valuta firmware e configurazione, confronta lo stato dei dispositivi con le configurazioni di riferimento approvate e monitora le modifiche. L’azienda presenta queste funzionalità come complementari alle misure di protezione già esistenti per applicazioni e modelli.

Per chi gestisce queste infrastrutture, il lavoro concreto comincia trattando DPU, GPU, controller di gestione e relativi firmware come risorse gestite singolarmente. Per ciascuno occorrono un responsabile, il monitoraggio delle versioni, la valutazione delle vulnerabilità e una procedura di aggiornamento ben definita. Anche l’accesso al piano di gestione e il software di terze parti sui processori dell’infrastruttura devono rientrare nella verifica.

I controlli dovrebbero seguire l’hardware anche durante la distribuzione, gli aggiornamenti, il ripristino dopo un incidente e la riassegnazione. Un’immagine pulita del sistema operativo non basta, da sola, a dimostrare che ogni componente di livello inferiore si trovi in uno stato approvato. Nelle infrastrutture condivise, il ciclo di vita dell’hardware è particolarmente importante, perché lo stesso hardware può essere utilizzato da clienti diversi in successione.

Verificare il sistema in esecuzione, non solo l’artefatto

Le firme dei modelli restano utili: rispondono a un’importante domanda sull’artefatto che viene caricato. L’avvio sicuro, l’attestazione, l’isolamento in fase di esecuzione e il monitoraggio continuo rispondono a domande diverse sul sistema che lo esegue. Nessuno di questi controlli dovrebbe essere considerato un sostituto di tutti gli altri.

L’importanza della ricerca di Eclypsium sta nel dimostrare che un modello può superare un controllo d’integrità mentre un’altra parte della sua catena di esecuzione è stata modificata. Per le organizzazioni che integrano l’IA in flussi di lavoro con conseguenze rilevanti, la verifica dell’infrastruttura deve accompagnare la valutazione del modello per tutta la sua operatività.