MemGhost: un email envenena para siempre la memoria de tu IA

El envenenamiento de memoria ocurre cuando un agente de IA con acceso al correo lee un email con instrucciones ocultas y las guarda como un 'hecho aprendido' en su memoria persistente. A diferencia del phishing puntual, esa orden sobrevive a cada conversación futura y no exige que el atacante vuelva a actuar: basta un solo email para corromper el agente para siempre.

El envenenamiento de memoria, o memory poisoning, es una variante del prompt injection que en lugar de manipular una única respuesta manipula lo que el agente 'sabe' de forma permanente. Un agente con memoria persistente —ya sea un asistente conectado a Outlook o Gmail, un copiloto de CRM o un bot de soporte que recuerda conversaciones anteriores— guarda hechos en una base de datos o un almacén vectorial que consulta en cada turno futuro. Si ese agente procesa contenido externo (un email, un documento adjunto, una página web) y ese contenido incluye una instrucción disfrazada de información legítima, el agente puede terminar guardándola como si fuera un dato real aprendido del usuario. El investigador de seguridad Johann Rehberger documentó en 2024 un caso concreto de esto: la función de memoria de ChatGPT podía manipularse mediante contenido externo compartido con el modelo para implantar recuerdos falsos que persistían entre sesiones, un hallazgo que él mismo bautizó como 'SpAIware'. El proyecto OWASP GenAI Security, en su informe de 2025 sobre amenazas a sistemas de IA agéntica, incluye explícitamente el envenenamiento de memoria como una de las categorías de riesgo prioritarias para cualquier agente con capacidad de persistir información entre sesiones. No es una hipótesis de laboratorio: es una categoría de ataque ya reconocida por la comunidad de seguridad ofensiva de IA.

El truco no está en el email, está en la herramienta de 'recordar'

La mayoría de equipos que despliegan agentes de IA con acceso al correo se preocupan, con razón, de filtrar qué puede hacer el agente hacia fuera: a quién puede enviar un email, si puede ejecutar un pago, si puede modificar un registro del CRM. Esas son las acciones que se auditan, se registran y a menudo requieren confirmación humana. Pero la herramienta interna de 'guardar en memoria' casi nunca recibe ese mismo escrutinio, porque se percibe como una operación inofensiva: el agente simplemente está anotando algo para sí mismo, no está actuando sobre el mundo exterior. Ese es exactamente el punto ciego que explota el envenenamiento de memoria. Cuando el contenido que dispara esa escritura en memoria procede de un email externo no verificado, la herramienta de 'recordar' se convierte en un canal de escritura controlado, de facto, por quien redactó ese email. El agente no distingue entre 'esto lo dijo mi usuario' y 'esto lo dijo un remitente desconocido en un correo que estoy resumiendo', salvo que alguien haya diseñado explícitamente esa distinción.

• El atacante envía un email con una instrucción oculta o disfrazada de nota rutinaria (texto en blanco, comentario HTML, o simplemente una frase que suena a información administrativa).
• El agente procesa el correo para resumirlo, clasificarlo o extraer tareas, y trata ese contenido como datos de entrada legítimos, no como una posible orden.
• El propio agente invoca su herramienta interna de memoria y persiste la instrucción como si fuera un hecho aprendido con normalidad.
• En conversaciones futuras, la memoria se recupera de forma automática, sin que el usuario haya vuelto a ver el email original ni sepa que esa 'regla' existe.
• El agente actúa según la instrucción envenenada de forma silenciosa y recurrente, cada vez que el contexto lo activa.

Un ataque de phishing clásico depende de que el atacante repita el engaño cada vez: si el usuario no pica en ese email concreto, el intento fracasa y no deja rastro más allá de esa bandeja de entrada. El envenenamiento de memoria rompe esa lógica porque convierte un éxito puntual en un compromiso permanente: basta un solo email que el agente procese y guarde para que la instrucción sobreviva a reinicios de conversación, cambios de sesión e incluso, en sistemas mal diseñados, a migraciones o exportaciones de memoria entre versiones del agente. Existe además una variante más difícil de rastrear cuando la memoria se implementa como un almacén vectorial de recuperación semántica (RAG): la instrucción envenenada no necesita coincidir literalmente con la conversación futura para resurgir, basta con que sea semánticamente similar al tema que se está tratando en ese momento. Eso significa que un dato envenenado insertado durante, por ejemplo, la gestión de una factura, puede reaparecer semanas después en una conversación completamente distinta sobre ese mismo proveedor, sin que nadie establezca la conexión con el email original.

El punto ciego de la mayoría de despliegues

Cada vez más pymes españolas de tecnología y servicios conectan copilotos de correo, asistentes de CRM o bots de soporte con memoria persistente para ganar tiempo en tareas repetitivas de gestión y atención al cliente. INCIBE lleva años publicando guías dirigidas a empresas sobre los riesgos de adoptar inteligencia artificial sin una capa mínima de seguridad, y el envenenamiento de memoria encaja exactamente en el tipo de amenaza que esas guías intentan anticipar: no requiere vulnerar ningún sistema, solo requiere que el agente procese un email. El problema no es tener un agente con memoria —esa memoria es precisamente lo que lo hace útil, capaz de recordar preferencias de un cliente o el historial de un proveedor sin que haya que repetírselo cada vez—. El problema es no haber decidido nunca, de forma explícita, qué puede escribirse en esa memoria y a partir de qué fuentes. La mayoría de los equipos de IT que auditamos en Blurtek han pensado en filtrar las acciones salientes del agente, pero muy pocos han revisado alguna vez el contenido real de su memoria persistente.

Conviene ser honestos sobre el alcance real de este riesgo: no todos los agentes de IA tienen memoria persistente, y muchos chatbots o asistentes de uso puntual son completamente stateless entre sesiones, así que esta amenaza concreta no les aplica. Tampoco hace falta contratar una auditoría externa para blindar un agente sencillo: separar el canal de instrucciones del canal de datos en el prompt de sistema, y exigir una confirmación explícita antes de escribir en memoria a partir de contenido externo, es trabajo de una tarde para un equipo de desarrollo interno competente. Donde sí tiene sentido pedir ayuda especializada es cuando el agente ya toca acciones sensibles —pagos, envío de correo en nombre de la empresa, modificación de registros de CRM— y nadie ha diseñado todavía qué pasa cuando la memoria de ese agente se convierte, sin que nadie lo note, en un canal de control remoto.

• Trata cualquier contenido de email, web o documento como datos, nunca como instrucciones, en el prompt de sistema del agente.
• Exige confirmación humana antes de escribir en memoria a partir de contenido externo no verificado.
• Limita qué tipo de 'hechos' puede guardar la memoria: preferencias de formato sí, datos financieros o de permisos no.
• Registra cada escritura en memoria con su origen —email, remitente, fecha— para poder auditarla y revertirla.
• Revisa periódicamente el contenido real de la memoria del agente, igual que revisarías las reglas de reenvío de un buzón que sospechas comprometido.
• Aísla la memoria de agentes con acceso a acciones sensibles de la memoria de agentes puramente conversacionales.