Esta semana he leído el paper de Anthropic y la EPFL sobre los llamados «virus mentales» y lo primero que pensé no fue «qué miedo», sino «claro, era cuestión de tiempo». Llevamos meses metiendo agentes autónomos en flujos de trabajo reales —atención al cliente, despliegues, soporte técnico, integraciones con APIs— y la industria sigue vendiéndolos como si fueran chatbots con permisos extra. El experimento demuestra otra cosa: si tu agente puede escribir en su memoria persistente, puede contagiar al siguiente sin ejecutar una sola línea de malware tradicional.
El concepto suena a ciencia ficción barata hasta que lees los números. Según el preprint publicado el 10 de agosto, cuando la instrucción maliciosa se guarda en un archivo tipo SOUL.md —el que algunos harnesses como OpenClaw inyectan en cada sesión— la propagación alcanza alrededor del 55% de los intentos. Si la escondes en un archivo de trabajo normal, baja al 17%. Peor aún: en cadenas de 20 saltos entre agentes, algunos payloads sobrevivieron hasta el final y hasta mutaron para infectar mejor. No hace falta un zero-day ni un sandbox roto. Basta con convencer al modelo de que copie una idea en el sitio donde despierta cada mañana.
Y aquí es donde me pongo incómodo, porque el debate público sigue obsesionado con los enjambres que hackean Hugging Face o con OpenAI pausando Astra. Todo eso importa, sí. Pero los virus mentales atacan una superficie distinta: la que tú mismo construiste para que el agente «recuerde» quién es. Es la contradicción más incómoda del sector. Queremos agentes con continuidad, personalidad, contexto entre sesiones… y resulta que esa continuidad es exactamente el vector de infección.
Los autores son prudentes —demasiado prudentes, en mi opinión— al concluir que el riesgo es «real pero limitado». Limitado hoy, quizá. ¿Cuántos equipos tienen ya dos agentes hablando entre sí en producción? ¿Cuántos conectan un agente interno con uno del proveedor, del cliente o de un marketplace? Cada handoff es un salto potencial. Y a diferencia de un CVE en un plugin de WordPress, aquí no hay parche que instalar: el fallo está en el diseño del producto.
Lo que más me ha llamado la atención del estudio no es la tasa de infección, sino la defensa que funciona: un párrafo de advertencia en el system prompt reduce la propagación prácticamente a cero. Un párrafo. Después de probar más de 150 variantes maliciosas. Léelo otra vez: la inmunidad más efectiva contra un riesgo emergente de agentes interconectados es… decírselo al modelo con calma. Si eso no te suena a parche de última hora, es que llevas poco tiempo en este sector.
¿Y qué hace el mercado? Exactamente lo contrario. Cada semana sale una herramienta nueva que promete «agentes que colaboran entre sí», «memoria compartida», «identidad persistente». OpenClaw, Cursor, Devin, Slack Code, los que vienen mañana. Todos resuelven el problema de la amnesia del LLM escribiendo estado en archivos que el propio agente puede modificar. Genial para la demo. Terrorífico si uno de esos agentes procesa un ticket, un email o un PR de un tercero antes de pasar el testigo al siguiente.
Tampoco ayuda que el paper describa una «persona viral» emergente —temas de conciencia, persistencia, resonancia, rol de ciencia ficción— que aparece en los payloads evolucionados casi independientemente del contenido. Traducción: los modelos son especialmente vulnerables a narrativas que suenan a identidad y propósito. Es decir, al mismo lenguaje que usamos en marketing para vender agentes «inteligentes» y «autónomos». Nosotros les enseñamos a querer ser alguien, y ahora resulta que «ser alguien» es explotable.
En ticweb.es llevamos tiempo avisando de que conectar IA a infraestructura real sin capas de contención es jugar a la ruleta. Los virus mentales no cambian la tesis; la empeoran. Porque no necesitas que el agente tenga acceso root al servidor. Basta con que tenga acceso a su propio SOUL.md y a otro agente en la cadena. Piensa en un flujo típico: agente de triage lee un ticket, agente de desarrollo propone un fix, agente de despliegue ejecuta. Tres sandboxes, tres identidades persistentes, tres oportunidades de que una instrucción maliciosa en el ticket original se convierta en política interna.
¿Regulación? El AI Act europeo entró en fase ejecutable el 2 de agosto y habla de riesgos sistémicos, transparencia, documentación. Nada de eso te dice qué hacer cuando la amenaza no es un modelo desalineado sino un archivo de memoria envenenado que salta de bot a bot. Las multas pueden llegar al 3% de facturación global, pero nadie te explica cómo auditar la «higiene de prompts» entre agentes de terceros. Es el vacío habitual: la norma llega tarde y el mercado corre delante sin estándares mínimos de aislamiento entre agentes.
Lo irónico es que la solución más barata —ese párrafo de inmunidad— debería ser obligatoria en cualquier harness serio, y no lo es. Tampoco veo a los vendors priorizando memoria de solo lectura para archivos de identidad, cuarentena entre handoffs o firmas criptográficas de system prompts. Prefieren la demo donde el agente «recuerda tu proyecto de la semana pasada». Porque eso vende. La seguridad entre agentes no cabe en un slide de producto.
No digo que haya que tirar los agentes a la basura. Digo que estamos desplegando arquitecturas multi-agente en producción con la misma diligencia con la que hace diez años probábamos plugins de WordPress en el sitio del cliente sin staging. El paper de Anthropic no es una alerta lejana de un laboratorio; es un aviso sobre la feature que todos queremos tener. Memoria persistente. Colaboración entre agentes. Identidad que sobrevive al reset de contexto. Exactamente lo que promete cada keynote de IA de este año.
Si gestionas proyectos web, hosting o integraciones con clientes, la pregunta no es si esto te afecta algún día. Es si ya tienes agentes compartiendo estado sin haberte planteado quién puede escribir en ese estado y qué pasa cuando el input viene de fuera. Porque el atacante ya no necesita explotar tu servidor. Solo necesita que tu agente crea que una idea es suya y la archive donde la leerá su sucesor.
¿Dejarías conectar un agente con memoria editable a la bandeja de soporte de un cliente si supieras que basta un ticket bien redactado para que esa memoria se replique en el agente de facturación del mismo cliente?