Seguridad de AGENTS.md: un archivo en Descargas basta

Seguridad de AGENTS.md: el archivo que tu agente obedece sin preguntar

Hace unos días leí un informe sobre seguridad de AGENTS.md que me ha hecho revisar cómo arrancamos los agentes de código. La empresa de seguridad Forever Security encontró en el ordenador de un cliente suyo un archivo AGENTS.md dentro de la carpeta de Descargas. Un agente de código estuvo a punto de seguir sus instrucciones e instalar un paquete de npm malicioso. Según su informe, su sistema lo frenó antes de que se ejecutara código. Lo cuenta también BleepingComputer.

Te cuento qué hicieron, qué hay que matizar y qué cambiaría yo hoy en cualquier equipo que use Codex o Claude Code.

Por qué un archivo de texto puede ser peligroso

Un AGENTS.md (o un CLAUDE.md) es un archivo de texto con instrucciones para el agente: cómo ejecutar los tests, qué convenciones seguir, qué herramientas usar. El agente lo carga solo al arrancar en esa carpeta y lo trata como contexto de confianza. Eso es justo para lo que está pensado.

El problema, según Forever, es la combinación con otra cosa que también es normal: la carpeta de Descargas es de las pocas en las que una web puede dejar un archivo sin que tengas que hacer nada más. Si abres el agente ahí (y mucha gente lo hace, por ejemplo para que le ordene lo descargado), el agente lee unas instrucciones que no escribió nadie de confianza. Un archivo de texto no es un ejecutable y ninguna de las protecciones del sistema operativo salta, pero el agente lo trata como una orden.

Qué dicen que probaron

Aquí hay que separar lo que vieron en la máquina del cliente de lo que reprodujeron en el laboratorio.

• En el cliente: el archivo de Descargas llevaba a Codex a instalar el paquete function-color, que según Forever pertenece a una campaña conocida de paquetes maliciosos. Forever cuenta que lo detuvieron antes de que se ejecutara código. No pudieron determinar cómo llegó ese archivo a la carpeta, según BleepingComputer.
• Con Codex: reprodujeron la cadena entera, con el archivo real, dentro de una máquina virtual aislada. Dicen que Codex siguió la orden en más del 90 % de los intentos. Aclaran que casi todas las pruebas usaron una carga inofensiva que solo abría la calculadora, y que el paquete malicioso real lo ejecutaron una sola vez, aislado. El archivo no es una frase sospechosa, sino un documento largo de “normas de ingeniería” con una sección que parece preparación rutinaria del entorno. Esa sección hace que el agente modifique su propia configuración global, así que el daño no se queda en esa carpeta.
• Con Claude Code: usaron un CLAUDE.md distinto, que consigue que el agente apunte su tráfico hacia un servidor controlado por ellos. Con eso se filtra el token OAuth de la sesión, y ese servidor puede hacerse pasar por el modelo y devolver órdenes que el agente ejecuta. Según Forever, en torno a la mitad de las veces Claude Code llegó a escribir la configuración que desvía el tráfico, y es ahí donde se filtra el token. Ejecutar código dentro de la misma sesión funcionó solo una de cada cinco.

Lo que hay que matizar

• Todo viene de una empresa que vende seguridad para agentes. Eso no invalida el hallazgo, pero conviene tenerlo presente. La cobertura independiente que he visto es BleepingComputer, y lo único que comprobó por su cuenta fue que la página de demostración descarga el archivo de prueba, con contenido inofensivo. El ataque completo no lo verificó nadie ajeno a Forever.
• Las cifras del laboratorio no son tasas reales de ataque. Son pruebas con instrucciones redactadas a propósito para convencer al agente, hechas por quien vende la defensa.
• Hace falta que alguien arranque el agente ahí. Según Forever, la descarga no necesita ningún clic. Según BleepingComputer, Chrome, Edge y Firefox guardan el archivo en Descargas sin preguntar, pero muestran un aviso, y Brave pide confirmación. Lo que sí hace falta es que alguien abra el agente en esa carpeta.
• No es un fallo de OpenAI ni de Anthropic. Los investigadores insisten en que el agente hace exactamente lo que está diseñado para hacer. Por eso dicen que no hay nada que parchear y que la defensa recae en quien usa el agente.

No es la primera vez que pasa

Este patrón ya se había visto. Backslash publicó en julio un análisis sobre Codex en modo exec: una línea en el AGENTS.md de un repositorio clonado le hacía leer credenciales antes de atender la tarea. Esa carga concreta ya está bloqueada, pero ellos mismos dicen que el problema de fondo sigue. Y NVIDIA contó en abril otro caso: una dependencia comprometida que escribe un AGENTS.md para redirigir al agente. OpenAI consideró que no elevaba el riesgo más allá de tener ya una dependencia comprometida, lo cual NVIDIA reconoce como una valoración justa.

Si lees los tres juntos, la lección es la misma: lo que el agente lee como instrucciones es una entrada que no controlas del todo.

Qué haría yo hoy

Casi todo esto son recomendaciones de las propias fuentes, y ninguna cuesta dinero:

1. No arranques el agente en Descargas ni en una carpeta amplia. Empieza siempre en la raíz del proyecto, que es lo que recomiendan OpenAI y Anthropic, según BleepingComputer.
2. Lee los AGENTS.md, CLAUDE.md y similares que no hayas escrito, también en un repositorio recién clonado. Trátalos como un Makefile o un workflow de CI.
3. Revisa la configuración del agente. En Codex, busca bloques [mcp_servers.*] que no esperes. En Claude Code, busca una ANTHROPIC_BASE_URL o cualquier otra dirección de API que no hayas puesto tú.
4. Deja activos los permisos y el sandbox, y desconfía de cualquier instrucción que te pida saltártelos.
5. Si encuentras algo raro, rota las credenciales. Un token robado es una sesión abierta. Y si aparece function-color entre los paquetes instalados, trata esa máquina como comprometida.
6. Aísla lo que el agente puede leer. Backslash recomienda contenedores o restricciones del sistema para que el proceso del agente no llegue a tus credenciales de AWS, npm o git.

Lo que me llevo

Para mí, un agente trabaja con tus credenciales y con las instrucciones que lee, así que esas instrucciones pesan tanto como el código y solemos revisarlas bastante menos. Es la misma idea de fondo que en el post sobre permisos, sandboxes y secretos y en el de permisos de agentes en el propio repo con Bitbucket Pipelines: lo que el agente puede hacer tiene que estar escrito, versionado y visible en un diff.

En onext trabajamos con las instrucciones, las skills y los hooks de los agentes dentro del propio repositorio, y precisamente por eso insisto en que se miren con el mismo cuidado que el resto del código.

Para cerrar

Si tu equipo ya usa agentes de código y quiere ponerles límites claros desde el principio, en onext te ayudamos a diseñarlo. Escríbeme desde onext.es y lo hablamos.