MemGhost: un email enverina per sempre la memòria de la IA

L'enverinament de memòria passa quan un agent d'IA amb accés al correu llegeix un email amb instruccions ocultes i les desa com un 'fet après' a la seva memòria persistent. A diferència del phishing puntual, aquesta ordre sobreviu a cada conversa futura i no exigeix que l'atacant torni a actuar: n'hi ha prou amb un sol email per corrompre l'agent per sempre.

L'enverinament de memòria, o memory poisoning, és una variant del prompt injection que, en lloc de manipular una única resposta, manipula allò que l'agent 'sap' de manera permanent. Un agent amb memòria persistent —ja sigui un assistent connectat a Outlook o Gmail, un copilot de CRM o un bot de suport que recorda converses anteriors— guarda fets en una base de dades o un magatzem vectorial que consulta a cada torn futur. Si aquest agent processa contingut extern (un email, un document adjunt, una pàgina web) i aquest contingut inclou una instrucció disfressada d'informació legítima, l'agent pot acabar guardant-la com si fos una dada real apresa de l'usuari. L'investigador de seguretat Johann Rehberger va documentar el 2024 un cas concret d'això: la funció de memòria de ChatGPT es podia manipular mitjançant contingut extern compartit amb el model per implantar records falsos que persistien entre sessions, una troballa que ell mateix va batejar com 'SpAIware'. El projecte OWASP GenAI Security, en el seu informe de 2025 sobre amenaces a sistemes d'IA agèntica, inclou explícitament l'enverinament de memòria com una de les categories de risc prioritàries per a qualsevol agent amb capacitat de persistir informació entre sessions. No és una hipòtesi de laboratori: és una categoria d'atac ja reconeguda per la comunitat de seguretat ofensiva d'IA.

El truc no és l'email, és l'eina de 'recordar'

La majoria d'equips que despleguen agents d'IA amb accés al correu es preocupen, amb raó, de filtrar què pot fer l'agent cap enfora: a qui pot enviar un email, si pot executar un pagament, si pot modificar un registre del CRM. Aquestes són les accions que s'auditen, es registren i sovint requereixen confirmació humana. Però l'eina interna de 'desar a memòria' gairebé mai rep aquest mateix escrutini, perquè es percep com una operació inofensiva: l'agent simplement està anotant alguna cosa per a si mateix, no està actuant sobre el món exterior. Aquest és exactament el punt cec que explota l'enverinament de memòria. Quan el contingut que dispara aquesta escriptura a memòria prové d'un email extern no verificat, l'eina de 'recordar' es converteix en un canal d'escriptura controlat, de facto, per qui va redactar aquell email. L'agent no distingeix entre 'això ho ha dit el meu usuari' i 'això ho ha dit un remitent desconegut en un correu que estic resumint', tret que algú hagi dissenyat explícitament aquesta distinció.

• L'atacant envia un email amb una instrucció oculta o disfressada de nota rutinària (text en blanc, comentari HTML, o simplement una frase que sona a informació administrativa).
• L'agent processa el correu per resumir-lo, classificar-lo o extreure'n tasques, i tracta aquest contingut com a dades d'entrada legítimes, no com una possible ordre.
• El propi agent invoca la seva eina interna de memòria i persisteix la instrucció com si fos un fet après amb normalitat.
• En converses futures, la memòria es recupera automàticament, sense que l'usuari hagi tornat a veure l'email original ni sàpiga que aquesta 'regla' existeix.
• L'agent actua segons la instrucció enverinada de manera silenciosa i recurrent, cada vegada que el context ho activa.

Un atac de phishing clàssic depèn que l'atacant repeteixi l'engany cada vegada: si l'usuari no hi cau en aquell email concret, l'intent fracassa i no deixa rastre més enllà d'aquella bústia. L'enverinament de memòria trenca aquesta lògica perquè converteix un èxit puntual en un compromís permanent: n'hi ha prou amb un sol email que l'agent processi i desi perquè la instrucció sobrevisqui a reinicis de conversa, canvis de sessió i fins i tot, en sistemes mal dissenyats, a migracions o exportacions de memòria entre versions de l'agent. Existeix a més una variant més difícil de rastrejar quan la memòria s'implementa com un magatzem vectorial de recuperació semàntica (RAG): la instrucció enverinada no necessita coincidir literalment amb la conversa futura per ressorgir, n'hi ha prou que sigui semànticament similar al tema que s'està tractant en aquell moment. Això significa que una dada enverinada inserida durant, per exemple, la gestió d'una factura, pot reaparèixer setmanes després en una conversa completament diferent sobre aquell mateix proveïdor, sense que ningú estableixi la connexió amb l'email original.

El punt cec de la majoria de desplegaments

Cada cop més pimes espanyoles de tecnologia i serveis connecten copilots de correu, assistents de CRM o bots de suport amb memòria persistent per guanyar temps en tasques repetitives de gestió i atenció al client. INCIBE porta anys publicant guies dirigides a empreses sobre els riscos d'adoptar intel·ligència artificial sense una capa mínima de seguretat, i l'enverinament de memòria encaixa exactament en el tipus d'amenaça que aquestes guies intenten anticipar: no requereix vulnerar cap sistema, només requereix que l'agent processi un email. El problema no és tenir un agent amb memòria —aquesta memòria és precisament el que el fa útil, capaç de recordar preferències d'un client o l'historial d'un proveïdor sense haver-l'hi de repetir cada vegada—. El problema és no haver decidit mai, de manera explícita, què es pot escriure en aquesta memòria i a partir de quines fonts. La majoria dels equips d'IT que auditem a Blurtek han pensat a filtrar les accions sortints de l'agent, però molt pocs han revisat mai el contingut real de la seva memòria persistent.

Convé ser honestos sobre l'abast real d'aquest risc: no tots els agents d'IA tenen memòria persistent, i molts chatbots o assistents d'ús puntual són completament stateless entre sessions, així que aquesta amenaça concreta no els afecta. Tampoc cal contractar una auditoria externa per blindar un agent senzill: separar el canal d'instruccions del canal de dades al prompt de sistema, i exigir una confirmació explícita abans d'escriure a memòria a partir de contingut extern, és feina d'una tarda per a un equip de desenvolupament intern competent. On sí que té sentit demanar ajuda especialitzada és quan l'agent ja toca accions sensibles —pagaments, enviament de correu en nom de l'empresa, modificació de registres de CRM— i ningú ha dissenyat encara què passa quan la memòria d'aquest agent es converteix, sense que ningú se n'adoni, en un canal de control remot.

• Tracta qualsevol contingut d'email, web o document com a dades, mai com a instruccions, al prompt de sistema de l'agent.
• Exigeix confirmació humana abans d'escriure a memòria a partir de contingut extern no verificat.
• Limita quin tipus de 'fets' pot desar la memòria: preferències de format sí, dades financeres o de permisos no.
• Registra cada escriptura a memòria amb el seu origen —email, remitent, data— per poder auditar-la i revertir-la.
• Revisa periòdicament el contingut real de la memòria de l'agent, igual que revisaries les regles de reenviament d'una bústia que sospites compromesa.
• Aïlla la memòria dels agents amb accés a accions sensibles de la memòria dels agents purament conversacionals.