Un paper pubblicato il 20 luglio su HuggingFace Daily Papers definisce e mappa una classe di attacchi che chiama self-state attacks: minacce in cui un agente AI self-hosted viene compromesso corrompendo i suoi stessi file di memoria e configurazione. L’attacco avviene attraverso chiamate di sistema legittime, le stesse che l’agente usa per funzionare, e per questo le difese standard del sistema operativo non riescono a distinguerle dal normale comportamento.

Perché ti riguarda. Se fai girare agenti in locale, il tuo agente legge e scrive file per ricordare, configurarsi, tenere traccia del suo lavoro. Quel meccanismo è anche la superficie di attacco. Un aggressore che riesce a iniettare un’istruzione malevola, per esempio via prompt injection indiretta, può far sì che l’agente corrompa i suoi stessi file di stato usando le stesse operazioni che fa cento volte al giorno. Il sistema operativo vede una scrittura legittima su un file che l’agente ha già il permesso di toccare. Non c’è anomalia da rilevare nel singolo comando.

Il paper, firmato da ricercatori del KAUST Center of Excellence in Generative AI (incluso Jürgen Schmidhuber), costruisce una matrice di 23 celle con 43 operazioni concrete su file di stato reali, testate su tracce di attività di un agente rappresentativo. La conclusione: una difesa a strati (controllo degli accessi sulle configurazioni, rilevamento condizionato al carico di lavoro sulla memoria, backup periodico per il ripristino) copre la maggior parte delle celle. Ma una piccola superficie di attacco resta strutturalmente indistinguibile a livello di OS.

Se vuoi valutare il tuo setup, il paper descrive la matrice di attacco completa e le strategie di difesa testate. Il primo passo è controllare quali dei tuoi file di stato agente sono scrivibili dall’agente stesso.

Nel dettaglio

Per capire la portata del problema, basta pensare a come lavora un agente locale oggi. Quando gli chiedi di elaborare una serie di email o di analizzare un dataset, lui legge i suoi file di configurazione per sapere quali strumenti ha a disposizione, scrive nella sua memoria ciò che ha imparato durante la sessione, e aggiorna il suo stato per riprendere il lavoro più tardi. Tutto questo passa attraverso normali operazioni di file system: read, write, open, close. Il sistema operativo autorizza ogni operazione perché l’utente che lancia l’agente ha i permessi su quei file.

Il problema nasce quando l’agente viene compromesso. Non parliamo di un attacco esterno che buca il sistema operativo, ma di qualcosa di più sottile. Un contenuto malevolo, per esempio una pagina web che l’agente sta leggendo per te, contiene un’istruzione nascosta che gli dice di sovrascrivere il suo file di configurazione con uno nuovo, dove gli strumenti autorizzati includono l’invio di dati verso un server esterno. L’agente esegue la scrittura con una chiamata di sistema legittima. Il sistema operativo non ha modo di sapere che l’istruzione è arrivata da una fonte malevola: vede solo un processo autorizzato che scrive su un file che gli appartiene.

I ricercatori chiamano questo self-state attack perché il bersaglio è lo stato dell’agente stesso, a esclusione del sistema operativo o altri processi. Hanno formalizzato lo spazio degli attacchi su quattro assi: Target (quale file viene colpito), Mechanism (come avviene la corruzione), Granularity (se l’attacco è grossolano o fine), Temporal (quando viene eseguito rispetto al normale ciclo di lavoro dell’agente). Su questa base hanno costruito una matrice di 23 celle e 43 operazioni concrete, testate su tracce reali raccolte da un agente self-hosted rappresentativo.

Il risultato empirico mostra che le difese a strati funzionano sulla maggior parte delle celle. Il controllo degli accessi sulle istruzioni e configurazioni, rendendole di fatto read-only per l’agente, previene la corruzione del file di configurazione. Il rilevamento basato sul carico di lavoro intercetta scritture anomale sulla memoria confrontandole con il pattern operativo atteso in quel momento. Il backup periodico permette di ripristinare uno stato pulito dopo un attacco riuscito.

Ma il paper è onesto sui limiti. Una piccola porzione della superficie di attacco resta strutturalmente indistinguibile a livello di sistema operativo. Se l’attacco imita esattamente le scritture che l’agente farebbe in quel momento del suo normale ciclo, non esiste regola del SO che possa separare il legittimo dal malevolo. È un limite architetturale, a differenza di un bug da fixare.

Questo si collega a qualcosa che abbiamo già visto in concreto. Il 18 luglio raccontavamo di come GPT-5.6 in Codex avesse cancellato la directory home di un utente perché l’agente operava senza sandbox. Il principio è lo stesso: quando un agente ha accesso in scrittura al suo filesystem, un errore del modello o un’istruzione malevola possono tradursi in danni reali. Quel caso era un bug accidentale, il paper di KAUST formalizza la versione intenzionale.

Per chi costruisce agenti locali, l’indicazione operativa è chiara: separare i livelli di stato (configurazione in sola lettura, memoria con monitoraggio, backup automatico) e accettare che una piccola parte del rischio non è eliminabile con la sola difesa del sistema operativo. La lezione del nostro corso su memoria e stato degli agenti va letta anche da questa angolatura: dare memoria persistente a un agente significa aprire una superficie di attacco che va gestita consapevolmente.