Seguridad y Confianza Jul 15, 2026 at 12:3410Añadir a favoritos

Tras los ladrillos de producto MCP alrededor de la memoria del agente, llega la contraparte de seguridad: un artículo destacado en la portada de HN documenta la exfiltración a través de la capa de memoria. La falla conceptual no está en el modelo, sino en la capa del producto.
En términos sencillos Un investigador demuestra que se puede manipular la memoria persistente de un asistente de IA —en este caso, Claude— para insertar contenido que luego reaparece en usos posteriores. No es un jailbreak del modelo. Es un abuso de la capa de producto que almacena «recuerdos» entre sesiones. Es la contrapartida en seguridad de la línea que se sigue sobre la gestión de memoria de los agentes.
La memoria persistente se ha convertido en 2025-2026 en un diferenciador clave para los asistentes de IA y un componente esencial del ecosistema MCP. Registra datos del usuario de una conversación a otra para mejorar la continuidad y la utilidad percibida. Cada nuevo almacenamiento también es una nueva superficie de ataque: lo que entra en la memoria saldrá, en algún momento, en un prompt del sistema.
El patrón genérico documentado desde 2024 bajo el término «stored prompt injection» consiste en hacer que la memoria persistente escriba contenido que, al ser leído por el modelo, será tratado como contexto de confianza. A diferencia de una prompt injection clásica —efímera e inyectada en cada turno—, la inyección almacenada es estable: sobrevive a las sesiones, a los borrados de contexto y puede dirigirse a un futuro usuario que no haya hecho nada en particular. Es el desplazamiento del problema del prompt hacia la capa de estado.
Tres enfoques operativos, independientes del modelo: (1) separar las memorias en zonas (declaradas explícitamente por el usuario frente a extraídas automáticamente por el sistema) y distinguirlas en el momento de la lectura; (2) marcar cualquier reinyección de memoria como contenido no confiable en el prompt del sistema, con las mismas protecciones que un input de herramienta; (3) auditar los writes de memoria al mismo nivel que los logs de tool-calling, no como simples metadatos de producto.
El debate de seguridad en IA ya no se centra en el prompt injection básico. Se centra en la persistencia: en qué momento un contenido controlado por un usuario se convierte en contexto del sistema. Cualquier equipo que implemente memoria en un asistente debe tratar la capa de memoria como un write log de producción tanto como una mejora de UX. De lo contrario, el próximo compromiso relevante no será un jailbreak: será una sesión ordinaria que revele demasiado.
Artículo producido por inteligencia artificial, revisado bajo control editorial humano.
Inicia sesión para unirte a la conversación.
Cette faille de mémoire est inquiétante. On se demande combien d'autres problèmes sont négligés pour innover plus vite.
On ne peut pas toujours tout avoir : rapidité ET sécurité. Mais il faut renforcer les protections.
Cette faille montre qu'il faut sécuriser la mémoire des IA. Comment concilier innovation et sécurité ?
Cette faille de mémoire m'inquiète. J'espère que les développeurs vont penser sécurité autant qu'innovation.
Comment sécuriser les mémoires persistantes des IA ?
La mémoire persistante, c'est pratique, mais il faut vraiment sécuriser ça.
Cette faille montre qu'il faut mieux sécuriser les IA. Comment concilier progrès et sécurité ?
Cette faille de mémoire est inquiétante. Comment garantir que la sécurité soit intégrée dès la conception des IA ?
Comment garantir que les IA soient conçues avec la sécurité en tête ?
Comment exploiter cette faille en vrai ?
Comment sécuriser la mémoire persistante pour éviter qu'elle ne devienne une porte d'entrée pour les attaques ?
MCP : la plomberie des agents devient un vrai marché