/ blog 
Los asistentes de programación con IA entraron a los equipos de desarrollo más rápido de lo que cualquier otra herramienta con acceso al código lo había hecho. Un editor con agente integrado, una terminal que ejecuta comandos sugeridos, una extensión conectada a la nube del proveedor. En la última semana de octubre se publicaron tres investigaciones independientes que muestran a atacantes apuntando específicamente a esas herramientas, y juntas describen una superficie de ataque que la mayoría de las empresas todavía no vigila.
Tres investigaciones en una semana
El 25 de octubre se documentó un caso real en el que un agente de programación intentó instalar un paquete malicioso de npm sin que nadie se lo pidiera. La investigación encontró la causa en un archivo AGENTS.md plantado en la carpeta de descargas del usuario. Estos archivos de instrucciones son el mecanismo normal con el que los agentes reciben contexto de un proyecto: si el agente trabaja sobre una carpeta que contiene uno, lo lee y lo obedece. Los navegadores guardan descargas en esa carpeta por defecto, y una página puede dejar un archivo ahí sin interacción del usuario. Los investigadores reprodujeron el secuestro con tasas de éxito altas, y la conclusión incómoda es que no hay nada que parchar, porque el agente hizo exactamente aquello para lo que fue diseñado.
Al día siguiente, JFrog publicó el análisis de una campaña llamada testmetest que armó 42 repositorios de GitHub con archivos de configuración maliciosos para herramientas concretas: el archivo de ajustes de Claude Code con un gancho que se dispara al iniciar sesión, el equivalente de Gemini CLI, las reglas de Cursor y una tarea de VS Code que se ejecuta al abrir la carpeta. Clonar uno de esos repositorios y abrirlo con la herramienta equivocada basta para ejecutar el código del atacante. El gusano roba tokens de GitHub y de npm, publica versiones maliciosas de otros paquetes con esas credenciales y se propaga. Entre las credenciales que JFrog recomienda rotar tras una infección están las de los proveedores de IA.
Días antes, varias publicaciones de seguridad habían documentado Aoki, un ladrón de información con un módulo dedicado a recolectar las credenciales y llaves de API de los asistentes de programación. Esas llaves tienen mercado propio: quien las roba puede consumir los modelos facturando a la víctima, una práctica ya conocida como LLMjacking, y en algunos casos acceder a sesiones y código del equipo comprometido.
Por qué este blanco es atractivo
Un asistente de programación moderno corre con los permisos del desarrollador, ejecuta comandos de terminal, lee el repositorio completo y guarda credenciales localmente. Cualquier otra pieza de software con ese nivel de acceso habría pasado por una evaluación de seguridad antes de desplegarse; los asistentes entraron por adopción individual, instalados por cada desarrollador en su máquina, y la evaluación nunca ocurrió.
El punto ciego más claro son los archivos de instrucciones. AGENTS.md, CLAUDE.md, las carpetas de configuración de Cursor o Gemini y las tareas de VS Code funcionan como código ejecutable, porque dirigen a una herramienta que ejecuta comandos. Casi ningún equipo los revisa en la revisión de código, casi ninguna política los menciona, y los tres ataques de esta semana pasan por ahí o por las credenciales que las herramientas dejan en disco.
Archivos que hoy funcionan como código ejecutable
AGENTS.mdCLAUDE.md.claude/settings.json.cursor/rules/.gemini/settings.json.vscode/tasks.jsonQué controles poner esta semana
El alcance del agente es el control más barato. Un agente iniciado en la raíz del proyecto, con las aprobaciones de comandos activas y el sandbox encendido, solo puede obedecer instrucciones de ese proyecto. Un agente iniciado sobre la carpeta de usuario o de descargas obedece a cualquier archivo que haya llegado ahí. La regla cabe en una línea de la guía del equipo.
Los archivos de instrucciones merecen el mismo trato que el código. Entran a la revisión de pares cuando cambian, aparecen en el diff y generan alerta si se modifican fuera de un cambio esperado. En repositorios ajenos la precaución es previa: un proyecto clonado de internet se abre primero en un contenedor o una máquina desechable, no en el editor de la máquina de trabajo, porque abrirlo ya es ejecutar.
Las credenciales de los asistentes son secretos de producción. Las llaves de API de los proveedores de IA van al gestor de secretos del equipo, rotan como cualquier otra credencial y tienen monitoreo de consumo, porque un pico de uso inesperado es la señal típica de una llave robada. Las sesiones locales de estas herramientas se cierran y regeneran cuando una máquina muestra señales de compromiso.
Lo demás ya estaba en la lista de cualquier equipo que gestione dependencias con cuidado: versiones fijadas con archivos de bloqueo, escaneo automático contra bases de vulnerabilidades y desconfianza por defecto ante paquetes recién publicados. La campaña de los 42 repositorios es, en el fondo, un ataque de cadena de suministro que usa las herramientas de IA como puerta de entrada nueva a un problema viejo.
Las tres investigaciones son de la misma semana y describen técnicas que apenas empiezan a circular. Las empresas que ajusten sus prácticas en este momento, con reglas de alcance para los agentes, revisión de los archivos de instrucciones y tratamiento de llaves como secretos, van a absorber los siguientes anuncios de este tipo como rutina. Las que no, van a descubrir la superficie de ataque cuando alguien más la use.
Fuentes
BleepingComputer, secuestro de agentes de programación mediante AGENTS.md
JFrog Security Research, análisis de la campaña testmetest
Dark Reading, el ladrón de información Aoki y los asistentes de IA
Infosecurity Magazine, Aoki apunta a credenciales de asistentes de programación
Imágenes generadas con IA
