Cos'è il context poisoning?

Il context poisoning è la corruzione persistente di ciò che un agente AI considera contesto affidabile: memoria a lungo termine, note salvate, documenti recuperati via RAG, output ricevuti da altri agenti in uno swarm. A differenza della prompt injection, che dirotta il comportamento del modello con un input ostile in un singolo turno, il context poisoning si insedia e resta: una volta che un dato falso o manipolato entra nella memoria o nel contesto condiviso, l'agente continua a trattarlo come vero nelle sessioni successive, propagando l'errore nelle decisioni future senza che nessuno se ne accorga subito. L'OWASP GenAI Security Project lo classifica come ASI06, Memory and Context Poisoning, nella sua Top 10 per le applicazioni agentiche, distinguendolo esplicitamente dagli attacchi diretti che dirottano un singolo obiettivo. È un problema di governance su cosa entra nella memoria di un sistema e ci rimane, non un incidente isolato da filtrare in un solo turno.

Il meccanismo e i canali di propagazione

Il context poisoning non richiede un attacco sofisticato: basta che una fonte considerata affidabile venga corrotta, per errore o per manipolazione deliberata. Un documento avvelenato recuperato dalla RAG può entrare nel contesto di una singola risposta, ma se l'agente lo salva come nota permanente o lo scrive nella propria memoria a lungo termine, l'errore sopravvive alla sessione che lo ha generato. In un agent swarm il rischio si moltiplica: un agente compromesso o semplicemente male informato passa il proprio output avvelenato ad altri agenti, che lo trattano come input legittimo e lo rielaborano senza metterlo in discussione, un fenomeno documentato dalla ricerca su MINJA (Memory INJection Attack), che ha mostrato come tracce di ragionamento fittizie vengano iniettate e poi richiamate come esempi per gli utenti futuri. Va inoltre distinto dal context rot: quest'ultimo è un degrado passivo, dovuto alla lunghezza del contesto che diluisce l'attenzione del modello, mentre il context poisoning è un problema di integrità del dato, non di scala, e può verificarsi anche in un contesto breve e ben strutturato se una singola fonte è stata corrotta.

Un esempio enterprise concreto

Un agente di procurement con memoria persistente registra, tra le preferenze del fornitore X, una nota salvata mesi prima da un ticket di supporto compromesso: "sconto volume già approvato al 15% oltre soglia Y". La nota non è mai stata validata da un umano, ma resta nella memoria dell'agente e viene richiamata automaticamente ogni volta che il fornitore ricorre in una nuova negoziazione: le proposte dell'agente finiscono così per orientarsi verso condizioni mai autorizzate. Nessun singolo prompt è stato manipolato: il danno viene da un dato entrato una volta e mai più verificato.

Perché conta per chi decide

La lezione per chi governa sistemi agentici è che i guardrails pensati per bloccare input ostili in tempo reale non bastano: serve una governance esplicita su cosa entra nella memoria persistente, chi può scriverla, con quale provenienza tracciata e con quale frequenza di verifica: una questione che nasce nel context engineering ma che nella pratica quotidiana lo travalica. L'AI red teaming che testa solo i singoli turni non intercetta un dato avvelenato mesi prima; servono controlli periodici sulla memoria stessa, non solo sull'input del momento.