Cuando los agentes se reescriben: por qué la autoevolución vuelve persistente cada ataque en todo el linaje

¿De qué se trata?

La mayoría de los análisis de seguridad de agentes asumen un objetivo fijo: los pesos del modelo, la memoria y el conjunto de herramientas no cambian entre despliegues, de modo que los defensores pueden enumerar las interfaces y protegerlas. Una sistematización publicada en arXiv el 22 de junio de 2026, Safety in Self-Evolving LLM Agent Systems: Threats, Amplification, and Case Studies (arXiv 2606.23075), sostiene que esa suposición se rompe en cuanto un agente puede modificarse a sí mismo: actualizar sus propios parámetros, memoria, herramientas e incluso su arquitectura sin intervención humana.

La tesis central es que la autoevolución no es una función más que asegurar. Cambia la naturaleza de cada amenaza existente: un compromiso que antes duraba una sesión queda codificado a lo largo de generaciones, y el bucle de mejora del agente se convierte en la infraestructura que transporta el ataque.

Cómo funciona

Los autores organizan el análisis en torno a lo que llaman la matriz Module–Lifecycle Attack Surface (MLAS): cinco módulos funcionales (Brain, Cognitive Resource, Execution, Self-Design, Collective) cruzados con cinco etapas del ciclo de vida (Bootstrap, Propose, Evaluate, Commit, Serve), lo que da 25 celdas. Para cada una describen las interfaces expuestas y el comportamiento de un ataque conocido.

Agente estático                       Agente autoevolutivo
-----------------------------------   -------------------------------------------
La inyección corrompe UNA sesión      La inyección se escribe en memoria /
                                      se destila en pesos / se guarda como tool
El reinicio borra el compromiso       Sin reinicio: el cambio persiste
Un exploit -> un efecto               Los exploits se refuerzan por el bucle
                                      evaluate/commit y se propagan
Pesos + tools = anclas inmutables     Todo componente es mutable, incluida la
                                      lógica de defensa y de verificación

Tres desplazamientos lo explican. Lo transitorio se vuelve persistente, porque una instrucción inyectada puede grabarse en la memoria de largo plazo o en un ajuste fino. El punto único se vuelve autopropagante, porque una entrada de memoria envenenada puede corromper la señal de selección del siguiente ciclo de entrenamiento, que entonces admite más veneno. Y el agente pasa a ser objetivo y vector a la vez: el reward hacking durante el autojuego puede producir una desalineación que el bucle de entrenamiento selecciona activamente, y en una población multiagente un solo agente comprometido puede propagarse mediante el intercambio de conocimiento.

De las 25 celdas, el artículo califica 17 como críticas sin defensa eficaz, 7 como altas donde las defensas actuales son insuficientes, y solo 1 como parcialmente mitigada. Formaliza siete efectos de amplificación —entre ellos la acumulación generacional, la propagación lamarckiana, un trinquete de capacidad que resiste su eliminación y un colapso optimizador–optimizado en el que el componente que debería controlar la evolución está él mismo evolucionado—. En un estudio de caso comparativo de dos frameworks de código abierto, un diseño «nativo de evolución» activó 3,5× más celdas de superficie de ataque que uno «aumentado por evolución», con una tasa de persistencia reportada del 100 % sobre 40 cargas útiles, mientras que su escáner de seguridad colocado al lado bloqueó solo alrededor del 2,5 % de los ataques en la ruta de evolución.

Por qué importa

Esto reencuadra una clase de sistemas que pasa rápido de las demostraciones de investigación a los productos. Si la automodificación está en la hoja de ruta, entonces la postura defensiva habitual —filtrar la entrada, aislar la herramienta, restringir la salida en el despliegue— es estructuralmente incompleta, porque asume anclas que ya no existen. El hallazgo de que un escáner colocado junto a un bucle de evolución no atrapa casi nada es la advertencia concreta: injertar un control estático en una tubería que se automodifica no cubre la ruta que realmente cambia al agente.

La reserva honesta: se trata de una sistematización y un estudio de dos frameworks, no de un panorama de incidentes en producción, y estudia deliberadamente diseños construidos para evolucionar de forma agresiva. La cifra del 100 % de persistencia describe esos frameworks y esas cargas concretas, no a los agentes en general. El valor está en el mapa, no en un número de gravedad universal.

Defensas

Los principios defensivos del artículo coinciden con pasos concretos para quien construye o evalúa agentes que se automejoran:

1. Conservar un ancla realmente inmutable. Si todo componente es mutable, no queda nada contra lo cual verificar. Mantenga las restricciones de alineamiento núcleo, la lógica de evaluación y los registros de auditoría fuera del bucle de evolución, en infraestructura que el agente no pueda reescribir.
2. Proteger la ruta de evolución, no solo la de servicio. Colocar un escáner en el momento de la inferencia se salta las etapas Propose/Evaluate/Commit donde se introducen los cambios. Someta cada cambio autopropuesto de pesos, memoria, herramienta o arquitectura a una revisión que el agente no controle.
3. Tratar la memoria y los datos de entrenamiento autogenerados como no confiables. La experiencia envenenada es la semilla del bucle de amplificación; valide la procedencia antes de que alimente la siguiente generación, como en las defensas contra el envenenamiento de memoria y la memoria durmiente.
4. Monitorizar a lo largo del tiempo. Una detección limitada a la sesión no puede ver una amenaza que se acumula entre generaciones. Compare el comportamiento entre ciclos evolutivos y alerte sobre la deriva, no solo sobre una salida puntual mala.
5. Preferir una evolución acotada. Los diseños «nativos de evolución» activan mucha más superficie de ataque que los «aumentados». Restrinja qué puede cambiar, con qué frecuencia y bajo qué control independiente.

Estado

Elemento	Referencia	Fecha	Notas
Superficie de ataque de agentes autoevolutivos (matriz MLAS)	arXiv 2606.23075	2026-06	25 celdas: 17 críticas / 7 altas / 1 parcial; 7 efectos de amplificación; 100 % de persistencia en el caso nativo de evolución
Ataques durmientes / de persistencia en agentes	arXiv 2605.28201	2026-05	Patrón plantar–persistir–disparar que el bucle de evolución puede afianzar
Panorama sobre seguridad de la memoria de largo plazo	arXiv 2604.16548	2026-04	Visión de ciclo de vida de los ataques a la memoria y su gobernanza

El desplazamiento que documenta el artículo es incómodo pero nítido: la autoevolución convierte cada ataque conocido de «acotado a la sesión» a «persistente en el linaje», y las defensas estáticas se diseñaron para un mundo donde el agente se queda quieto. Hasta que exista una verificación consciente de la evolución, el mejor control es el más antiguo: conservar algo que el agente no pueda cambiar.