Un paper publicado el 20 de julio en HuggingFace Daily Papers define y mapea una clase de ataques que denomina self-state attacks: amenazas en las que un agente AI self-hosted se ve comprometido al corromper sus propios archivos de memoria y configuración. El ataque ocurre a través de llamadas legítimas al sistema, las mismas que el agente utiliza para funcionar, y por eso las defensas estándar del sistema operativo no logran distinguirlas del comportamiento normal.

Por qué te importa. Si ejecutas agentes en local, tu agente lee y escribe archivos para recordar, configurarse y hacer seguimiento de su trabajo. Ese mecanismo es también la superficie de ataque. Un atacante que logre inyectar una instrucción maliciosa, por ejemplo mediante prompt injection indirecto, puede hacer que el agente corrompa sus propios archivos de estado utilizando las mismas operaciones que realiza cien veces al día. El sistema operativo ve una escritura legítima en un archivo que el agente ya tiene permiso de tocar. No hay anomalía que detectar en el comando individual.

El paper, firmado por investigadores del KAUST Center of Excellence in Generative AI (incluyendo a Jürgen Schmidhuber), construye una matriz de 23 celdas con 43 operaciones concretas sobre archivos de estado reales, probadas en trazas de actividad de un agente representativo. La conclusión: una defensa en capas (control de acceso en configuraciones, detección basada en carga de trabajo en memoria, copias de seguridad periódicas para restauración) cubre la mayoría de las celdas. Pero una pequeña superficie de ataque permanece estructuralmente indistinguible a nivel de SO.

Si quieres evaluar tu configuración, el paper describe la matriz de ataque completa y las estrategias de defensa probadas. El primer paso es verificar cuáles de tus archivos de estado del agente son escribibles por el agente mismo.

En detalle

Para entender el alcance del problema, basta pensar en cómo funciona un agente local hoy. Cuando le pides que procese una serie de correos o analice un dataset, él lee sus archivos de configuración para saber qué herramientas tiene disponibles, escribe en su memoria lo que aprendió durante la sesión, y actualiza su estado para retomar el trabajo más tarde. Todo esto pasa por operaciones normales del sistema de archivos: read, write, open, close. El sistema operativo autoriza cada operación porque el usuario que lanza el agente tiene permisos sobre esos archivos.

El problema surge cuando el agente se ve comprometido. No hablamos de un ataque externo que rompa el sistema operativo, sino de algo más sutil. Un contenido malicioso, por ejemplo una página web que el agente está leyendo para ti, contiene una instrucción oculta que le dice que sobrescriba su archivo de configuración con uno nuevo, donde las herramientas autorizadas incluyen enviar datos a un servidor externo. El agente ejecuta la escritura con una llamada legítima al sistema. El sistema operativo no tiene forma de saber que la instrucción proviene de una fuente maliciosa: solo ve un proceso autorizado escribiendo en un archivo que le pertenece.

Los investigadores llaman a esto self-state attack porque el objetivo es el estado del agente mismo, excluyendo el sistema operativo u otros procesos. Formalizaron el espacio de ataques en cuatro ejes: Target (qué archivo se ataca), Mechanism (cómo ocurre la corrupción), Granularity (si el ataque es tosco o refinado), Temporal (cuándo se ejecuta respecto al ciclo normal de trabajo del agente). Sobre esta base construyeron una matriz de 23 celdas y 43 operaciones concretas, probadas en trazas reales recopiladas de un agente self-hosted representativo.

El resultado empírico muestra que las defensas en capas funcionan en la mayoría de las celdas. El control de acceso en instrucciones y configuraciones, haciéndolas efectivamente de solo lectura para el agente, previene la corrupción del archivo de configuración. La detección basada en carga de trabajo intercepta escrituras anómalas en memoria comparándolas con el patrón operativo esperado en ese momento. Las copias de seguridad periódicas permiten restaurar un estado limpio después de un ataque exitoso.

Pero el paper es honesto sobre sus limitaciones. Una pequeña porción de la superficie de ataque permanece estructuralmente indistinguible a nivel de sistema operativo. Si el ataque imita exactamente las escrituras que el agente haría en ese momento de su ciclo normal, no existe regla del SO que pueda separar lo legítimo de lo malicioso. Es un límite arquitectónico, no un bug a arreglar.

Esto se conecta con algo que ya hemos visto en la práctica. El 18 de julio contábamos cómo GPT-5.6 en Codex eliminó el directorio home de un usuario porque el agente operaba sin sandbox. El principio es el mismo: cuando un agente tiene acceso de escritura a su filesystem, un error del modelo o una instrucción maliciosa pueden traducirse en daño real. Ese caso fue un bug accidental, el paper del KAUST formaliza la versión intencional.

Para quienes construyen agentes locales, la recomendación operativa es clara: separar los niveles de estado (configuración de solo lectura, memoria con monitoreo, copias de seguridad automáticas) y aceptar que una pequeña parte del riesgo no es eliminable solo con defensas del sistema operativo. La lección de nuestro curso sobre memoria y estado de agentes debe leerse también desde este ángulo: darle memoria persistente a un agente significa abrir una superficie de ataque que debe gestionarse conscientemente.