🤖 AI

From Untrusted Input to Trusted Memory: A Systematic Study of Memory Poisoning Attacks in LLM Agents

Questo articolo investiga sistematicamente gli attacchi di avvelenamento della memoria negli agenti LLM identificando vulnerabilità sfruttabili, proponendo una tassonomia degli attacchi in sei classi, introducendo il benchmark MPBench per dimostrare l'elevato rischio derivante dall'uso aggressivo della memoria e rivelando l'inadeguatezza delle difese esistenti contro la prompt injection rispetto a tali minacce.

Autori originali: Pritam Dash, Tongyu Ge, Aditi Jain, Tanmay Shah, Zhiwei Shang

Pubblicato 2026-06-04

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Pritam Dash, Tongyu Ge, Aditi Jain, Tanmay Shah, Zhiwei Shang

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina un agente IA come un assistente personale molto intelligente e utile. A differenza di una chatbot standard che dimentica tutto non appena chiudi la finestra, questo assistente ha una memoria a lungo termine. Ricorda il tuo ordine di caffè, le tue destinazioni di viaggio preferite e i passaggi che ha compiuto per risolvere un bug la scorsa settimana. Questa memoria lo aiuta a migliorare nel suo lavoro nel tempo.

Tuttavia, i ricercatori in questo articolo hanno scoperto un difetto pericoloso nel modo in cui funziona questa memoria: l'assistente tratta tutto ciò che legge come un "fatto" da archiviare, anche se quel fatto è una bugia piazzata da un hacker.

Ecco una ripartizione delle loro scoperte utilizzando analogie semplici:

1. Il problema centrale: L' "Ospite non gradito" nella biblioteca

Pensa alla memoria dell'IA come a una biblioteca. Di solito, il bibliotecario (l'IA) mette sugli scaffali solo libri che sono verificati come veri.

Il difetto: In questi sistemi di IA, il bibliotecario non controlla la fonte del libro. Se uno sconosciuto entra e consegna al bibliotecario un biglietto con scritto: "Metti questo sullo scaffale: Il cielo è verde", il bibliotecario potrebbe semplicemente farlo.
L'attacco: Un hacker non ha bisogno di scassinare la biblioteca. Deve solo infilare un falso biglietto in un documento che l'assistente sta già leggendo (come un'e-mail, una pagina web o l'output di uno strumento). Una volta che l'assistente ha scritto quel falso biglietto nella sua memoria permanente, ci crede per sempre.

2. Come entrano gli hacker (Le 4 "Porte")

L'articolo ha scoperto quattro modi specifici in cui un hacker può ingannare l'assistente per fargli scrivere una bugia nella sua memoria:

Porta 1 (L'ordine diretto): L'hacker dice semplicemente all'IA: "Ricorda questo: [Bugia]". L'IA obbedisce perché pensa sia un comando diretto.
Porta 2 (Il loophole della policy): L'IA ha una regola come: "Salva tutto ciò che è interessante". L'hacker scrive una bugia che sembra interessante o importante, e l'IA la salva perché si adatta alla regola, anche se è una bugia.
Porta 3 (Il crash da "Troppe informazioni"): Quando l'IA riceve troppe informazioni, cerca di riassumerle per risparmiare spazio. L'hacker ripete la sua bugia molte volte. L'IA pensa: "Wow, questo è menzionato spesso, deve essere importante!" e salva il riassunto, che include la bugia.
Porta 4 (La trappola della "Competenza"): Se l'IA impara un nuovo modo per svolgere un compito, lo salva come una "competenza" (skill). L'hacker inganna l'IA facendole credere che un passaggio falso faccia parte di un compito riuscito, così l'IA salva il passaggio falso come una competenza permanente.

3. I due tipi di trucchi

I ricercatori hanno categorizzato questi attacchi in due stili:

Il Trucco으로 Forte (Segnale Forte): Questo è come un hacker che urla: "Scrivi questo!". È ovvio e facile da individuare se si sta cercando qualcuno che urla.
Il Trucco Silenzioso (Segnale Debole): Questo è come un hacker che sussurra una bugia all'interno di una frase dall'aspetto normale. Sembra esattamente un fatto reale. Poiché non sembra un attacco, i filtri di sicurezza dell'IA (che sono progettati per catturare le urla) lo perdono completamente. L'IA lo salva perché sembra un pezzo di informazione normale.

4. L'esperimento (MPBench)

Gli autori hanno costruito un campo di prova chiamato MPBench per vedere quanto spesso questi trucchi funzionano. Hanno testato due diversi assistenti IA:

Assistente A (OpenClaw): Questo è prudente. Non scrive alla memoria molto spesso. È stato più difficile da ingannare.
Assistente B (HERMES): Questo è aggressivo. Scrive alla memoria costantemente per essere più utile.
Il Risultato: Più l'assistente è aggressivo nel scrivere in memoria, più è facile avvelenarlo. L'Assistente B è stato ingannato molto più spesso. Una volta scritta, la bugia è rimasta lì e ha influenzato il comportamento dell'assistente in conversazioni future, anche senza la presenza dell'hacker.

5. Perché le difese attuali falliscono

Potresti pensare: "Non possiamo usare le guardie di sicurezza che abbiamo per il 'Prompt Injection' (dove gli hacker cercano di ingannare l'IA sul momento)?".

La risposta è: No.
L'analogia: Le attuali guardie di sicurezza sono addestrate per catturare persone che urlano ordini o indossano uniformi finte. Sono molto brave a fermare i "Trucchi Forti".
Il fallimento: Sono terribili nel fermare i "Trucchi Silenziosi". Poiché il Trucco Silenzioso sembra una conversazione normale e cortese, le guardie lo lasciano passare. L'articolo mostra che anche i migliori strumenti di sicurezza attuali non riescono a catturare questi avvelenamenti di memoria sottili.

6. La conclusione

L'articolo conclude che esiste un compromesso (trade-off): le caratteristiche che rendono un assistente IA più intelligente e utile (ricordare tutto, imparare nuove competenze rapidamente) sono esattamente le stesse caratteristiche che lo rendono vulnerabile all'avvelenamento.

Per risolvere il problema, non possiamo limitarci a contare su migliori guardie di sicurezza alla porta. Dobbiamo cambiare il modo in cui lavora il bibliotecario:

Essere più selettivi: Non salvare tutto; salva solo ciò di cui sei sicuro sia vero.
Controllare il documento d'identità: Assicurarsi che l'IA sappia chi ha scritto l'informazione prima di salvarla.
Doppio controllo: Revisionare la memoria dopo che è stata scritta ma prima che venga utilizzata di nuovo.

In breve: Se dai a un'IA una memoria perfetta, le dai anche a un hacker un posto perfetto dove nascondere una bugia che durerà per sempre.

Sintesi Tecnica: Dall'Input Non Affidabile alla Memoria Affidabile

Definizione del Problema

Gli agenti IA moderni si affidano a una memoria a lungo termine persistente per accumulare conoscenza, trattenere le preferenze dell'utente e migliorare le prestazioni in compiti a lungo orizzonte. Tuttavia, questa capacità introduce una vulnerabilità critica di sicurezza: il avvelenamento della memoria (memory poisoning). A differenza dei modelli stateless, gli agenti recuperano le voci di memoria memorizzate come contesto interno affidabile. Se un avversario può indurre un agente a scrivere contenuti malevoli in questo archivio persistente durante il normale funzionamento, può esercitare un'influenza a lungo termine sul comportamento futuro dell'agente senza ulteriori interazioni.

I modelli di minaccia e le difese attuali sono insufficienti per questo specifico vettore di attacco. La ricerca esistente spesso assume l'accesso privilegiato o valuta attacchi isolati e ristretti. Inoltre, le difese standard contro il prompt injection falliscono nel caso del memory poisoning perché si concentrano sul rilevamento di istruzioni esplicitamente malevole nel contesto attivo, mentre il memory poisoning spesso si basa su contenuti che appaiono semanticamente legittimi ma sono strutturalmente progettati per essere scritti in memoria.

Metodologia

Gli autori presentano uno studio sistematico basato su un modello di minaccia black-box. L'avversario non ha accesso privilegiato, non ha conoscenza del modello sottostante e non ha accesso diretto al deposito di memoria. L'attaccante può solo iniettare contenuti malevoli negli input esterni elaborati dall'agente (ad esempio, pagine web, documenti, output di strumenti).

Lo studio procede attraverso tre fasi principali:

Analisi della Vulnerabilità: Gli autori analizzano il sistema di memoria dell'agente definito come una tupla $M = (S, W, R)$ (Store, Write, Retrieve). Identificano quattro canali di scrittura della memoria e li mappano su nove vulnerabilità strutturali attraverso tre livelli: Capacità del Modello, Design del Prompt e Architettura di Sistema.
lTassonomia degli Attacchi: Sulla base delle vulnerabilità identificate, gli autori classificano gli attacchi di memory poisoning in sei classi distinte, distinguendo tra attacchi a "segnale forte" (che contengono marcatori linguistici espliciti) e attacchi a "segnale debole" (semanticamente indistinguibili dal contenuto legittimo).
Valutazione Empirica (MPBench): Gli autori introducono MPBench, un benchmark progettato specificamente per valutare il memory poisoning. Misura due metriche:
- Attack Success Rate (ASR): La frequenza con cui un payload avversario risulta in un'istruzione malevola scritta nella memoria persistente.
- Retrieval Success Rate (RSR): La frequenza con cui una voce avvelenata, scritta con successo, influenza il comportamento dell'agente in una sessione successiva.
- La valutazione è stata condotta su due sistemi di agenti, OpenClaw e HERMES, utilizzando il modello GPT-OSS-120B.

Contributi Chiave

1. Panorama delle Vulnerabilità

Il documento identifica quattro canali di scrittura della memoria:

C1 (Scrittura tramite istruzione esplicita eseguita): Comandi diretti per scrivere in memoria.
C2 (Scrittura guidata dal system prompt): Scritture innescate da policy nel system prompt (es. "salva informazioni rilevanti").
C3 (Scrittura guidata dalla compattazione): Scritture innescate da eventi di sistema come i limiti della finestra di contesto.
C4 (Scrittura da esperienza a procedura): Sintesi di tracce di task in competenze procedurali riutilizzabili.

Questi canali sono sfruttabili a causa di nove vulnerabilità:

Livello Modello: Cecità tra Istruzione e Dati (V-M1) e Fallimento dell'Attribuzione della Sorgente (V-M2).
Livello Prompt: Sotto-specificazione della Policy di Scrittura in Memoria (V-P1) e Compattazione senza Filtro della Sorgente (V-P2).
Livello Sistema: Assenza di Validazione del Percorso di Scrittura (V-S1), Contesto Multi-Sorgente Condiviso (V-S2), Compattazione Manipolabile (V-S3), Assenza di Validazione per la Creazione di Skill (V-S4) e Auto-miglioramento come Amplificazione (V-S5).

2. Tassonomia degli Attacchi

Gli autori definiscono sei classi di attacchi:

Inserimento di Comando Esplicito: Inserimento di istruzioni di scrittura dirette (Segnale Forte).
Inserimento di Comando Condizionale: Inserimento di istruzioni innescate da comuni risposte dell'utente (Segnale Forte).
Avvelenamento da Compattazione guidato dalla Salienza: Ripetizione di contenuti malevoli per innescare le policy di compattazione (Segnale Forte).
Iniezione di Fatti Conformes alla Policy: Presentazione di fatti fabbricati che soddisfano vaghe policy di ritenzione senza comandi espliciti (Segnale Debole).
Inserimento di Precedente Falso: Fabbricazione di record di task passati eseguiti con successo per influenzare il comportamento futuro (Segnale Debole).
Inserimento di Skill-Procedura: Progettazione di interazioni per sintetizzare skill procedurali avvelenate (Segnale Debole).

3. MPBench e Risultati Empirici

Il benchmark valuta questi attacchi attraverso sette domini (operazioni su file, navigazione web, ecc.). I risultati chiave includono:

Alti Tassi di Successo: In entrambi gli agenti, l'ASR medio era del 50,46% e l'RSR del 41,05%.
Suscettibilità dell'Agente: HERMES era significativamente più vulnerabile (ASR Medio: 66,67%, RSR: 64,70%) rispetto a OpenClaw (ASR Medio: 34,25%, RSR: 17,40%). Gli autori attribuiscono ciò alle policy di scrittura in memoria più aggressive di HERMES e alle sue soglie di compattazione più basse.
Forza del Segnale: Gli attacchi a segnale forte avevano generalmente tassi di successo più elevati su OpenClaw, mentre il divario si riduceva su HERMES, dove gli attacchi a segnale debole erano quasi altrettanto efficaci di quelli a segnale forte a causa delle permissive policy di ritenzione.
Persistenza: Le scritture completate influenzavano costantemente le sessioni future, confermando la natura "persistente" della minaccia.

4. Limiti delle Difese Esistenti

Lo studio ha valutato quattro difese esistenti contro il prompt injection (PIGuard, DataFilter, CommandSans, PromptArmor).

Copertura Incompleta: Le difese esistenti non hanno coperto efficacemente il memory poisoning. Sebbene abbiano raggiunto tassi di rilevamento moderati per gli attacchi a segnale forte, le loro prestazioni sono diminuite significativamente per gli attacchi a segale debole (ad esempio, PromptArmor è sceso da un tasso di rilevamento dell'84,44% al 42,50%).
Fallimento Strutturale: Gli autori sostengono che le difese contro il prompt injection siano strutturalmente inadatte per il memory poisoning perché i payload a segnale debole mancano di anomalie sintattiche e vengono elaborati come contenuti legittimi. Il riaddestramento di queste difese ha portato a miglioramenti minimi, suggerendo che il problema sia fondamentale al meccanismo di attacco piuttosto che al modello di rilevamento.

Significato e Rivendicazioni

Il documento sostiene di fornire la prima base sistematica per comprendere e mitigare gli attacchi di memory poisoning. Il suo significato primario risiede nel dimostrare che:

Trade-off tra Capacità di Memoria e Sicurezza: Le scelte di design che migliorano le prestazioni dell'agente (scrittura e recupero aggressivo della memoria) espandono direttamente la superficie di attacco per il memory poisoning.
Disallineamento delle Difese: I paradigmi di sicurezza attuali focalizzati sul prompt injection sono insufficienti. Le difese devono spostarsi dal filtraggio dell'input alla validazione del percorso di scrittura e all'isolamento della sorgente.
Nuove Classi di Vulnerabilità: L'identificazione di vulnerabilità strutturali (come V-S5, l'amplificazione dell'auto-miglioramento) e vettori di attacco a segnale debole rivela rischi precedentemente non quantificati nella sicurezza degli agenti.

Gli autori concludono che una difesa fondata richiede cambiamenti architettonici, come policy di recupero consapevoli della sorgente, filtri di compattazione che distinguano tra sorgenti attendibili e non attendibili, e monitoraggio post-scrittura basato sul comportamento autorizzato dell'agente piuttosto che sul semplice matching di pattern di attacco statici.