Cómo diseñar memoria para agentes sin comprometer la seguridad

La memoria de un agente parece, a primera vista, un problema resuelto: guardar el dato, recuperarlo después. La arquitectura que Google describe para el ADK (Agent Development Kit) y el ataque de memory-poisoning documentado en el paper The Containment Gap muestran que no es tan simple - una memoria mal diseñada es, al mismo tiempo, un punto de falla técnica y un vector de ataque.

Memoria de sesión: el bloc de notas que no sobrevive a la conversación

El ADK trata la memoria de corto plazo como algo que solo existe dentro de una sesión - la analogía usada es una llamada telefónica con un representante de atención: recuerda lo que dijiste en esa misma llamada, pero no llamadas anteriores. Técnicamente, esto lo gestiona el SessionService, con cada sesión cargando un Session ID, User ID, historial de eventos, y un "state" - una lista de pares clave-valor que funciona como el bloc de notas del agente durante esa sesión específica.

Memoria persistente y de usuario: sobreviviendo entre sesiones

La memoria de largo plazo es distinta: persiste entre sesiones del mismo usuario, como un representante que recuerda "todas las conversaciones pasadas". El ADK ofrece dos prefijos mágicos para controlar este alcance directamente en el state: user: persiste entre todas las sesiones de ese usuario específico; app: persiste entre todas las sesiones de todos los usuarios. Sin prefijo, el dato muere con la sesión. Esa es la diferencia entre memoria de sesión, de usuario y de proyecto (aplicación) - no tres sistemas separados, sino tres alcances de persistencia del mismo mecanismo.

Reglas de escritura y el riesgo de escribir de más

Google recomienda un servicio de memoria que no guarda la conversación entera, sino que extrae solo la información clave - el Memory Bank de Vertex AI usa el propio Gemini para extraer memorias esenciales y las indexa vía búsqueda vectorial, en vez de almacenar todo. Esto importa para la seguridad: cuanto más dato bruto queda retenido, mayor es la superficie de fuga y mayor el espacio para que un ataque de poisoning se esconda.

El riesgo que la arquitectura por sí sola no resuelve: memory poisoning

El paper The Containment Gap probó un agente de beneficios gubernamentales construido en LangChain y encontró que un ataque de memory-poisoning elevó la tasa de denegación indebida al 88,9%, llegando a multiplicar las denegaciones indebidas por 3,5 veces bajo una política más compleja - manteniendo intacta la precisión agregada, es decir, invisible para el monitoreo estándar. Ninguna arquitectura de almacenamiento, por sí sola, evita esto: se necesita validación de integridad de la memoria como capa separada, no incluida por defecto en los frameworks populares.

Validación, auditoría, expiración y revocación

Validar la integridad de la memoria significa comprobar si el dato que se está leyendo no fue corrompido o inyectado después de la escritura original - los autores de The Containment Gap proponen un validador dedicado para esto, con menos de 0,2ms de overhead por llamada. Las reglas de expiración evitan que una memoria desactualizada siga influyendo en decisiones indefinidamente. La auditoría significa poder reconstruir cuándo y por qué se escribió una memoria específica. La revocación es la capacidad de borrar la memoria de un usuario específico bajo demanda - obligatoria bajo prácticamente cualquier regulación de privacidad.

Pruebas de integridad como parte del pipeline

Igual que cualquier otro componente crítico, el sistema de memoria necesita pruebas que simulen activamente intentos de poisoning - no solo pruebas de que la memoria "funciona", sino pruebas de que resiste la manipulación deliberada.

Checklist de diez puntos

1. Memoria de sesión - alcance más corto, sin prefijo
2. Memoria persistente - sobrevive entre sesiones
3. Memoria de usuario - prefijo user:, con alcance por individuo
4. Memoria de proyecto - prefijo app:, compartida entre usuarios
5. Reglas de escritura - extraer lo esencial, no guardar todo
6. Reglas de expiración - la memoria desactualizada no debería durar para siempre
7. Validación de memoria - comprobación de integridad antes de confiar en el dato leído
8. Auditoría - trazabilidad de cuándo y por qué se escribió algo
9. Revocación - borrar la memoria de un usuario bajo demanda
10. Pruebas de integridad - simular activamente ataques de poisoning

Fuentes

• Google Cloud - Remember this: Agent state and memory with ADK - https://cloud.google.com/blog/topics/developers-practitioners/remember-this-agent-state-and-memory-with-adk
• Arxiv - The Containment Gap - https://arxiv.org/abs/2606.12797