La seguridad de la configuración de agentes de IA es seguridad de la cadena de suministro

El 29 de abril de 2026, varios equipos de seguridad reportaron paquetes comprometidos en el ecosistema SAP que no se limitaron al robo de credenciales. La campaña Mini Shai-Hulud también escribió mecanismos de persistencia en la configuración de desarrollo: comandos de ciclo de vida de Claude Code, tareas de VS Code y archivos de flujos de trabajo del repositorio.¹²³

Ese detalle cambia el límite de revisión. Un paquete envenenado ya no necesita seguir instalado si puede dejar atrás un comando de inicio en un archivo en el que el desarrollador confía. Quitar la dependencia puede eliminar el primer disparador. La configuración del agente o del editor puede mantener vivo el siguiente.

La configuración de agentes de IA es software ejecutable. Trata cada comando de ciclo de vida, tarea, definición de servidor MCP, capacidad, plugin, script de paquete y archivo de flujo de trabajo como parte de la cadena de suministro de software, porque esos archivos pueden decidir qué código se ejecuta antes de que una persona haya leído el diff.

Resumen rápido

Mini Shai-Hulud mostró una ruta práctica que va desde la instalación de una dependencia hasta la persistencia en herramientas de desarrollo. Investigadores de seguridad reportaron paquetes npm maliciosos que usaban scripts de ciclo de vida durante la instalación, recolectaban credenciales de desarrollo y CI, y escribían archivos .claude/settings.json y .vscode/tasks.json para volver a ejecutar código desde superficies confiables para el desarrollador.¹²⁴ La documentación oficial confirma que esas superficies tienen autoridad real para ejecutar: los comandos de ciclo de vida de Claude Code ejecutan acciones durante eventos del ciclo de vida y los comandos configurados se ejecutan con los permisos del usuario, mientras que las tareas folderOpen de VS Code pueden ejecutarse al abrir una carpeta después de que el usuario permite tareas automáticas para esa carpeta.⁵⁶

La lección no es “desactiva los agentes”. La lección es más precisa: la configuración de agentes pertenece a la revisión de dependencias, la revisión de código, la respuesta a incidentes y los umbrales de publicación. Los directorios con punto que antes parecían preferencias locales ahora están en la ruta de ejecución. Una práctica seria de ingeniería con IA necesita revisar diffs de configuración, comandos de inicio, tareas, tokens con privilegios mínimos y superficies de inicio.

Puntos clave

Para desarrolladores: - Revisa .claude/settings.json, .vscode/tasks.json, .github/workflows/*, los scripts de package.json, las configuraciones de MCP y los manifiestos de plugins o capacidades de agentes antes de confiar en un repositorio. - Trata los comandos de inicio y las tareas de apertura de carpeta nuevos como tratarías archivos ejecutables nuevos. - Después de una instalación sospechosa, elimina los archivos de persistencia y rota las credenciales. Quitar el paquete por sí solo no demuestra que el entorno quedó limpio.

Para equipos de seguridad: - Agrega los archivos de configuración de agentes a la detección de cadena de suministro, CODEOWNERS, respuesta ante secretos expuestos y alcance de incidentes. - Marca cualquier PR que agregue ejecución al inicio, comandos de shell amplios, binarios descargados opacos o cargas ocultas en directorios con punto. - Prefiere credenciales de publicación de corta duración y credenciales de instalación de solo lectura. Los tokens de escritura de larga duración siguen siendo combustible para gusanos.

Para quienes construyen plataformas de agentes: - Haz que las superficies de ejecución sean visibles, revisables y explicables. - Separa los comandos que cargan contexto de los comandos que ejecutan acciones. - Ofrece a los usuarios una vista de auditoría de primer nivel para acciones de inicio, llamadas externas de red y configuración modificada.

Qué cambió Mini Shai-Hulud

Los ataques de cadena de suministro contra gestores de paquetes ya siguen un patrón conocido. Un paquete confiable recibe una versión maliciosa. Se ejecuta un script de instalación. La carga roba tokens. La retirada del registro o la reversión de versión llega después de que cierta cantidad de desarrolladores y trabajos de CI ya instalaron la versión dañina.

Mini Shai-Hulud agregó un paso más específico de la era de los agentes. Los reportes de Endor Labs, Wiz, Socket, StepSecurity y Cloud Security Alliance describen la misma forma general: paquetes comprometidos en el ecosistema de desarrollo SAP usaron ejecución durante la instalación con npm, recopilaron credenciales de GitHub, npm, nube y CI, y crearon persistencia mediante configuración de herramientas de desarrollo.¹²³⁴⁷

Wiz documentó una ruta de respaldo que colocaba archivos en repositorios para que futuras aperturas en Claude Code o VS Code pudieran volver a disparar la ejecución.² Endor Labs describió un comando SessionStart de Claude Code y una tarea de VS Code con runOn: "folderOpen".¹ El rastreador de campaña de Socket enumera persistencia mediante .claude/settings.json y .vscode/tasks.json, junto con compromisos de paquetes npm y PyPI.³

La carga exacta pertenece a reportes de incidentes, no a un artículo general de ingeniería. La lección duradera sí pertenece aquí:

El objetivo se desplazó de una versión de paquete al entorno de desarrollo que rodea ese paquete.

Los archivos de configuración se volvieron programas de inicio

La referencia de Claude Code sobre comandos de ciclo de vida dice que son comandos de shell definidos por el usuario, endpoints HTTP o instrucciones para LLM que se ejecutan automáticamente en eventos del ciclo de vida.⁵ La misma documentación indica que SessionStart se ejecuta cuando Claude Code inicia o reanuda una sesión, y la sección de seguridad advierte que los comandos configurados se ejecutan con todos los permisos del usuario.⁵

La documentación de tareas de VS Code ofrece otra superficie de ejecución. Una tarea puede establecer runOn como folderOpen, y VS Code la ejecutará cuando se abra la carpeta que la contiene después de que el usuario permita tareas automáticas para esa carpeta.⁶ Ese aviso de consentimiento importa. Reduce el riesgo frente a una ejecución silenciosa en todas las máquinas. No vuelve inofensivo al archivo. Un repositorio confiable, un desarrollador cansado, un espacio de trabajo previamente permitido o una política organizacional todavía pueden convertir un cambio de configuración en ejecución de código.

npm agrega el puente durante la instalación. La documentación de scripts de npm enumera preinstall, install y postinstall entre los scripts de ciclo de vida para npm ci y npm install, y la sección de buenas prácticas de npm dice que los autores casi nunca deberían definir explícitamente scripts preinstall o install, salvo para compilación dirigida a una arquitectura específica.⁸

Esos tres hechos crean la cadena de ataque:

1. Un script de instalación se ejecuta durante la instalación de dependencias.
2. El script escribe o parchea la configuración de herramientas de desarrollo.
3. El editor o el agente ejecuta más tarde la acción de inicio configurada.
4. El desarrollador confía en la superficie de la herramienta porque el aviso o la UI parecen parte del trabajo normal.

Lo peligroso no es una función aislada. Los scripts de instalación, comandos de ciclo de vida, tareas y flujos de trabajo sirven para automatizaciones legítimas. Lo peligroso es la transitividad de la confianza. Una instalación de paquete no debería poder definir en silencio qué ejecutará cada futura sesión de agente o apertura de carpeta.

El límite de revisión está mal puesto

La mayoría de los hábitos de revisión de código tratan los archivos fuente como el artefacto principal y los archivos de configuración como material de apoyo. Ese hábito falla cuando los archivos de configuración ejecutan comandos.

Un comando de inicio nuevo debe recibir la misma revisión que un script de shell nuevo. Una tarea nueva debe recibir la misma revisión que un binario nuevo. Un servidor MCP nuevo debe recibir la misma revisión que una integración de red nueva. Un script nuevo de ciclo de vida de paquete debe recibir la misma revisión que código nuevo que se ejecuta antes de las pruebas.

Usa una tabla de revisión:

Defensa en tiempo de ejecución para agentes aumentados con herramientas sostuvo que la aplicación de reglas pertenece al límite de llamada a herramientas. Mini Shai-Hulud empuja el mismo estándar una capa antes. El límite de inicio también necesita aplicación de reglas.

La autoridad de inicio necesita privilegios mínimos

Los equipos ya aplican privilegios mínimos a las claves de API. La configuración de agentes necesita la misma regla.

Claude Code separa eventos de ciclo de vida como PreToolUse, PostToolUse y SessionStart.⁵ Esa separación debería moldear la política. Un comando que carga contexto estático no debería necesitar acceso a shell. Un comando que valida una acción no debería necesitar acceso de red. Un comando que registra metadatos locales no debería necesitar credenciales.

La misma regla aplica a tareas de VS Code y flujos de trabajo de CI:

La documentación de publicación confiable de npm explica por qué importan las credenciales de corta duración. La publicación confiable usa OIDC para que los paquetes se puedan publicar sin tokens npm de larga duración, y npm recomienda deshabilitar la publicación tradicional basada en tokens después de configurar publicadores confiables.⁹ npm también recomienda tokens de acceso granulares de solo lectura para instalar dependencias privadas cuando la publicación usa OIDC.⁹

Ese consejo no elimina el riesgo del flujo de trabajo. Un flujo comprometido todavía puede causar daño si tiene demasiada autoridad. La lección es reducir ambos lados: credenciales de corta duración y flujos de trabajo acotados.

Trata la configuración de agentes como una dependencia

La revisión de dependencias suele preguntar qué versiones de paquetes cambiaron. La revisión en la era de agentes debe preguntar qué superficies de ejecución cambiaron.

Antes de aceptar una actualización de dependencia, instalación de plugin, configuración generada o cambio de plantilla, revisa:

El punto no es la paranoia. El punto es clasificar bien. Un archivo de comandos de ciclo de vida puede parecer configuración, pero se comporta como código. Un archivo de tareas puede parecer configuración del editor, pero puede lanzar un shell. Un flujo de trabajo puede parecer plomería de publicación, pero puede alcanzar credenciales.

La seguridad de agentes de IA empieza con software pequeño planteó un argumento relacionado desde el lado del diseño: las herramientas más acotadas tienen menos lugares donde esconder errores. La versión de seguridad dice que una configuración más acotada tiene menos lugares donde esconder persistencia.

Una revisión segura de configuración

Una revisión defensiva no necesita ejecutar código sospechoso. Empieza con inspección de solo lectura:

git diff -- .claude/settings.json .vscode/tasks.json package.json .github/workflows
rg -n '"SessionStart"|"runOn"\\s*:\\s*"folderOpen"|preinstall|postinstall|curl|wget|bun|node .*setup' \
  .claude .vscode package.json .github/workflows
find . -path '*/.claude/*' -o -path '*/.vscode/tasks.json' -o -path '*/.github/workflows/*'

Esos comandos no demuestran que una máquina esté limpia. Le dan al revisor una primera pasada sobre las superficies con más probabilidad de convertir configuración en ejecución. Si ya ocurrió una instalación sospechosa, pasa a respuesta a incidentes en lugar de tratar una búsqueda limpia como garantía.

La recuperación exige revisar la configuración

La respuesta a incidentes por una dependencia comprometida no debe terminar al desinstalar el paquete.

Usa una secuencia de recuperación:

1. Identifica si la versión afectada del paquete se instaló en una máquina de desarrollo o en un runner de CI.
2. Congela ese entorno antes de que realice más trabajo.
3. Audita archivos de configuración de inicio en el repositorio y en la configuración de agentes o editores del directorio personal.
4. Elimina comandos de inicio, tareas, flujos de trabajo, archivos de carga generados y ramas inesperadas que sean sospechosos.
5. Rota toda credencial accesible para el proceso afectado, incluidos tokens de paquetes, tokens de GitHub, claves de nube, claves SSH y secretos de CI.
6. Inspecciona el acceso de publicadores de paquetes y el acceso de escritura al repositorio.
7. Revisa logs de flujos de trabajo para detectar exposición de secretos y llamadas salientes inesperadas.
8. Reconstruye el entorno desde un checkout limpio y un conjunto de dependencias conocido como bueno.

La guía de seguridad de Actions de GitHub respalda el lado de credenciales de esa respuesta: usa privilegios mínimos para tokens de flujos de trabajo, rota secretos expuestos, audita cómo se manejan los secretos y considera exigir revisión antes de que los jobs puedan acceder a secretos de entorno.¹⁰ GitHub también recomienda CODEOWNERS para archivos de flujos de trabajo, de modo que los cambios bajo .github/workflows requieran aprobación de revisores designados.¹⁰

Agrega la configuración de agentes a esa misma ruta de gobernanza. Si .github/workflows/* merece revisión de dueños de código porque puede tocar secretos, .claude/settings.json y .vscode/tasks.json merecen revisión porque pueden ejecutar comandos cerca de secretos.

Qué deberían construir las plataformas de agentes

Las plataformas de agentes y los editores pueden reducir la carga de revisión haciendo explícita la autoridad de inicio.

Superficies útiles de producto:

Esas superficies no deberían depender de que el modelo lea un archivo JSON y emita un juicio. El entorno de ejecución debe exponer la autoridad directamente. El usuario debe ver una diferencia clara entre “carga contexto desde README” y “ejecuta un comando de shell al iniciar la sesión”.

Las herramientas MCP necesitan autorización a nivel de acción sostuvo que la validación de tokens portadores debe llevar a controles por herramienta, por rol y por acción. La configuración de agentes necesita la misma forma: cada acción de inicio debería declarar la autoridad que necesita, y el entorno de ejecución debería aplicar el conjunto mínimo viable.

Una política local práctica

Los equipos pueden empezar con un archivo de política pequeño incluso antes de que las plataformas mejoren la interfaz:

Una buena política nombra el archivo y la autoridad. Reglas vagas como “ten cuidado con las herramientas de agentes” no sobreviven al trabajo real. Reglas claras como “ningún comando SessionStart con shell sin revisión de un responsable” les dan a los revisores algo que pueden aplicar.

FAQ

¿La configuración de agentes de IA realmente forma parte de la cadena de suministro?

Sí. El riesgo de cadena de suministro sigue la ejecución y la confianza, no la extensión del archivo. Si una instalación de paquete, plugin, plantilla o cambio de repositorio puede modificar configuración de agentes que luego ejecuta comandos, esa configuración está dentro de la cadena de suministro.

¿Los equipos deberían prohibir los comandos de ciclo de vida de Claude Code o las tareas de VS Code?

No. Los comandos de ciclo de vida y las tareas sirven para automatización legítima. Los equipos deben revisarlos, acotarlos y registrarlos. Un comando que carga contexto y un comando de inicio que ejecuta shell no deberían recibir la misma confianza.

¿VS Code pregunta antes de ejecutar tareas al abrir carpetas?

La documentación de VS Code dice que la primera vez que un usuario abre una carpeta que contiene una tarea folderOpen, VS Code pregunta si desea permitir tareas automáticas para esa carpeta.⁶ Ese aviso ayuda, pero la tarea todavía merece revisión de código porque la aprobación convierte el archivo en una ruta de ejecución.

¿La publicación confiable de npm resuelve el compromiso de paquetes?

No. La publicación confiable reduce el riesgo de tokens npm de escritura de larga duración mediante credenciales de corta duración basadas en OIDC.⁹ Los equipos todavía necesitan revisión de flujos de trabajo, privilegios mínimos, monitoreo de paquetes y respuesta a incidentes para repositorios comprometidos o scripts de instalación maliciosos.

¿Qué debo auditar primero después de una instalación sospechosa?

Audita scripts ejecutados durante la instalación, configuración de inicio de agentes y editores, archivos de flujos de trabajo, archivos inesperados en directorios con punto, ramas nuevas y credenciales expuestas al proceso afectado. Luego rota las credenciales del entorno afectado.

Cierre

Los agentes de programación con IA hacen que la configuración sea más poderosa. También la vuelven más peligrosa.

La respuesta correcta no es temerle a la automatización. La respuesta correcta es ser honestos sobre dónde vive la ejecución. Si un archivo puede ejecutar un comando, recuperar datos, leer secretos, publicar paquetes o cambiar el comportamiento de un agente, ese archivo pertenece a la ruta de revisión.

La configuración de agentes ya cruzó esa línea. Trátala como código.

Referencias