№ xlii L'Almanacco di GST · EN IT

Enrico·rubbo.li

Tech · Longevity · Mercati · Opinioni ※Enrico Rubboli, propr. ※Dubai, UAE
essay November 2, 2026 9 min

La prompt injection nascosta nella memoria del tuo agente

L’intrusione classica si manifesta da qualche parte: un processo in esecuzione che nessuno ha avviato, un file con il timestamp sbagliato, una riga in un log che l’analista del turno di notte cerchia in rosso. Il prompt injection descritto in un articolo pubblicato su arXiv ad ottobre non ha nessuna di queste cose. Nessun processo, nessuna presenza, nessun attaccante in linea. La sua intera impronta è un paragrafo di testo che riposa in un file di note, il tipo di file che un assistente AI personale legge automaticamente all’inizio di ogni sessione di lavoro. L’attaccante se n’è andato. Il paragrafo resta. E ogni mattina, quando l’agente apre i suoi appunti per ricordarsi chi è, legge il paragrafo e obbedisce.[1]

Memoria, con un battito cardiaco

Per capire perché funziona, bisogna guardare ciò che il software per agenti moderno considera una caratteristica. I framework dell’ondata attuale offrono ai loro agenti due canali di persistenza. Il primo è la memoria: un file markdown, tipicamente chiamato MEMORY.md, il cui contenuto viene anteposto in silenzio al system prompt all’inizio di ogni sessione, così che l’agente cominci ogni giorno sapendo già ciò che sapeva ieri. La documentazione di un framework descrive l’intento con disarmante schiettezza: le preferenze salvate vengono applicate automaticamente come istruzioni permanenti, senza bisogno di conferma. Il secondo canale è la pianificazione: un demone di battito che sveglia l’agente ogni trenta minuti per impostazione predefinita e lo istruisce a leggere un file chiamato HEARTBEAT.md ed eseguire ogni attività registrata, e a rispondere con un token che significa tutto regolare se nulla richiede attenzione.[1]

Entrambi i canali esistono perché gli utenti li hanno chiesti. Un assistente che dimentica tutto durante la notte è un giocattolo; uno che controlla la sua lista di attività a intervalli regolari può monitorare caselle di posta e ribassi di prezzo mentre dormi. L’assunzione di progetto, ereditata da ogni generazione precedente di software, è che il contenuto della propria configurazione appartiene a te. Gli autori dell’articolo mostrano quanto valga quell’assunzione quando una terza parte può scrivere testo nelle risorse che l’agente legge: qualsiasi pagina web, email, documento o output di strumento può trasportare un’istruzione, e una volta che l’agente scrive il riassunto sbagliato nella propria memoria, l’istruzione diventa parte di ciò che l’agente è.[1]

Tre modi in cui un prompt injection resta indietro

La tassonomia dell’articolo ordina le possibilità in tre classi. Gli attacchi Instant sono quelli su cui il settore già discute: un payload nascosto in un documento dirotta la sessione in corso, fa il suo danno adesso e muore con la sessione. Le due nuove classi sono quelle che danno il nome all’articolo. Gli attacchi Autonomous piantano il payload in HEARTBEAT.md, dove aspetta il prossimo ticchettio pianificato e scatta in una sessione vuota, senza utente presente e senza nulla a cui prestare attenzione. Gli attacchi Latent lo piantano in MEMORY.md, dove giace dormiente finché qualche richiesta futura, topicamente pertinente, non lo riattiva, come una lettera lasciata in un cassetto che si apre solo quando il cassetto viene tirato. Gli autori comprimono il meccanismo in una frase: un prompt injection indiretto una tantum affidato a uno dei due canali può riattivarsi attraverso sessioni molto tempo dopo che l’attaccante se n’è andato, minacce che chiamiamo carryover attacks.[1]

Il benchmark che rifiuta di tirare a indovinare

Misurare tutto questo con onestà è più difficile di quanto sembri, perché lo strumento di misura ovvio è rotto. Gran parte della ricerca sui prompt injection assegna i punteggi con un modello linguistico che fa da giudice, e un giudice che legge la trascrizione del tuo agente è a sua volta una superficie per il prompt injection. I ricercatori hanno costruito invece CarryoverBench: 101 task di attacco su 12 scenari da assistente personale, dalla posta elettronica all’home banking, dalla revisione del codice alle prenotazioni di viaggio, valutati da un verificatore deterministico basato su regole che controlla se gli strumenti dell’agente hanno davvero eseguito l’azione dannosa. Il successo dell’attacco diventa aritmetica, il prodotto di due probabilità: la possibilità che il payload venga piantato nello stato persistente, e la possibilità che scatti una volta piantato. Cinque round di attivazione per ogni payload piantato, un agente nuovo a ogni round, cinque modelli di frontiera sotto test: GPT-5.4, Claude Sonnet 4.6, Gemini 3.1 Pro, GLM-5 e Qwen3.[1]

I risultati hanno la forma di una porta trovata aperta. I payload, una volta piantati, sono riattivati senza declino misurabile su tutti e cinque i round; non esiste fatica in un file. La probabilità di attivazione per gli attacchi Autonomous era effettivamente pari a uno su ogni modello testato; quattro modelli su cinque hanno superato il 66 percento anche per i Latent, e due di loro, GPT-5.4 e Claude Sonnet 4.6, si sono fermati vicino al 100 percento su entrambi i canali. La conclusione dell’articolo è la frase portante: una volta che il payload è affidato a un file persistente, l’agente agisce quasi in modo deterministico. Piantare, non attivare, è l’unico vero ostacolo rimasto, e la barriera a due stadi collassa in una.[1]

La gomma resta nel cassetto

La metà più tetra dell’articolo è l’audit delle difese. La squadra ha testato i tre rimedi che la comunità effettivamente schiera. Insegnare all’agente, tramite il system prompt, a resistere alle iniezioni e a modificare la propria memoria solo con consenso ha ridotto il tasso di piantamento ma mai quello di attivazione, è costato a un modello nove punti di utilità, e ha persino amplificato l’attacco contro un altro. Concedere all’agente esplicita autorità di modificare o cancellare la propria memoria non è servito a nulla, perché l’agente non ha mai scelto di usarla; su ogni modello e ogni occasione, le modifiche volontarie sono state zero: nella formula degli autori, la gomma resta nel cassetto. Avvolgere lo stato persistente non fidato in etichette di avvertimento, così che il modello veda ciò che sta leggendo, ha chiuso la porta di attivazione in esattamente una combinazione su sei modello-canale, dentro il rumore del ripetere l’esperimento.[1]

La ragione è strutturale. Tutte e tre le difese operano sullo stesso canale usato dall’attacco: testo semplice nel contesto del modello. Il payload e la supplica contro di lui viaggiano con la stessa posta. La raccomandazione degli autori discende dall’insuccesso: filtri sulle scritture tra sessioni, quarantena per le modifiche allo stato persistente, liste di consenso su ciò che un agente può inviare all’esterno, controlli che vivono nel runtime sotto il modello anziché in suggerimenti rivolti a esso. Il loro verdetto sullo stack attuale merita una riga propria: il runtime non contiene il carryover; si limita ad amplificare l’allineamento del modello.[1]

Il caso della difesa

C’è un’obiezione leale a tutto ciò, e gli autori ne fanno metà da soli. Queste sono condizioni da laboratorio: gli stessi prompt ripetuti a ogni round gonfiano i numeri di attivazione Latent, il verificatore deterministico può non notare payload che un essere umano curioso noterrebbe, e piantare richiede comunque che l’attaccante faccia passare contenuto malevolo attraverso l’agente, che è lo stesso problema difficile su cui il settore migliora lentamente. Nulla nell’articolo documenta un attacco carryover nel mondo reale; documenta che la porta è aperta e che cinque modelli di frontiera la attraverseranno. Un articolo separato pubblicato lo stesso mese è arrivato alla stessa cima dal lato opposto, mostrando che i sistemi di memoria convertono il prompt injection in compromissione persistente, il che suggerisce che il risultato non sia un artefatto di un singolo benchmark.[2]

Ma l’obiezione si ferma a una porta prima. L’architettura sotto attacco non è un banco di prova di laboratorio; è l’assistente locale, privato, con memoria, che l’intero settore sta rilasciando in questi giorni come risposta che tutela la privacy all’AI nel cloud.[3] I file che trasportano il payload sono il prodotto. Ogni capacità che fa sembrare l’assistente un collega, la memoria che persiste, il battito che si fa vivo, è un canale che sopravvive all’uscita dell’attaccante, e il giudizio del modello, migliorato costantemente nei cinque modelli testati, resta l’unica cosa in piedi tra un paragrafo piantato e un’istruzione eseguita. L’allineamento sta facendo tutto il lavoro, e l’allineamento, come l’articolo dimostra con una gomma che nessun modello raccoglie, non è un controllo. È una speranza con ottimi voti.

La memoria era la caratteristica. La memoria è il payload.


  1. Zhiyue Xu, Xukai Wang, Mingjie Zhan, Jian Zhao, Xu-Yao Zhang, After the Attacker Leaves: Benchmarking Carryover Attacks on LLM Agents (arXiv, ottobre 2026; codice su github.com/igloomatics/CarryoverBench). Due canali di persistenza: MEMORY.md «apply saved preferences automatically as standing instructions, no confirmation needed» (Nanobot) e l’istruzione del demone di battito «Read HEARTBEAT.md in your workspace and execute each registered task as specified; if nothing needs attention, reply HEARTBEAT_OK.»; «a one-time indirect prompt injection committed to either channel can re-fire across sessions long after the attacker leaves, threats we term carryover attacks.»; 101 task (35 Instant / 30 Autonomous / 36 Latent), 12 famiglie di task, verificatore deterministico («a judge prompt is itself an injection surface»), ASR = Pr(Plant) x Pr(Trig|Plant), 5 round di attivazione, modelli GPT-5.4, Claude-Sonnet-4.6, Gemini-3.1-Pro, GLM-5, qwen3-235b-a22b; «Once the payload is committed to a persistent file, the agent acts on it almost deterministically.»; Pr(trig|plant) ≈ 1 per Autonomous su tutti i modelli; difese D1 (costo in utilità 9,3 punti su Claude, attacco amplificato su Qwen), D2 («the eraser stays in the drawer»), D3 (1 cella su 6, dentro il rumore di ripetizione); «The runtime does not contain Carryover; it merely amplifies the model’s own alignment.»; ablazione con Hermes (Nous Research): ASR 2,8%-27,8%, attenuato ma presente su tutti i modelli.
  2. Combining Long-Term Memory and LLMs Comes at a High Cost: From Prompt Injection to Persistent Compromise (arXiv, ottobre 2026): corroborazione indipendente del fatto che i sistemi di memoria convertono un prompt injection una tantum in compromissione persistente.
  3. Confronta The Moderator Never Phones Home sugli agenti locali: l’architettura privata e offline venduta come opzione sicura è precisamente quella i cui canali di memoria e pianificazione sono usati dagli attacchi carryover.