El problema de explosión de estados en las cadenas de suministro de software con IA

El número de dependencias directas en un proyecto de software moderno rara vez supera las pocas decenas. Pero cuando se tienen en cuenta las dependencias transitivas, las versiones, los entornos de ejecución y los permisos de cada componente, el espacio de estados posibles es exponencial. Añade agentes de IA que modifican, generan o instalan paquetes de forma autónoma y ese espacio crece de una manera que los escáneres de vulnerabilidades clásicos no están preparados para recorrer.

Eso es, en esencia, lo que el equipo de seguridad de Microsoft describe en un artículo publicado en su blog técnico y recogido esta semana en Hacker News. El concepto tiene un nombre preciso tomado de la verificación formal: state explosion, la explosión de estados, un problema conocido en la ingeniería del software que la IA generativa está reactivando con fuerza renovada.

Qué es exactamente la explosión de estados en este contexto

En verificación formal, la explosión de estados describe el fenómeno por el que el número de configuraciones posibles de un sistema crece de forma combinatoria al aumentar sus componentes. En una cadena de suministro de software tradicional, el problema ya existía, pero era en gran medida estático: las dependencias cambian con cada release, no con cada prompt.

Con agentes de IA en el bucle —ya sea un agente de Claude Code resolviendo una tarea de scaffolding, un subagente instalando paquetes vía MCP server, o un pipeline de CI/CD asistido por LLM— las dependencias pueden cambiar en tiempo de ejecución, sin intervención humana directa y sin dejar siempre un rastro claro en el repositorio. Cada decisión que toma el agente sobre qué versión instalar, qué script ejecutar o qué API llamar añade una rama al árbol de estados posibles de esa cadena de suministro.

Por qué los controles actuales se quedan cortos

Las herramientas de análisis de composición de software (SCA) y los escáneres de CVE trabajan sobre un grafo de dependencias conocido y relativamente estático. Comparan versiones contra bases de datos de vulnerabilidades: un modelo sencillo y efectivo cuando el grafo cambia pocas veces al día.

El problema es que un agente de IA puede alterar ese grafo en el transcurso de una única sesión. Si el agente tiene permisos para ejecutar `pip install`, `npm install` o llamadas equivalentes a través de un MCP server, el estado del entorno después de la sesión puede diferir sustancialmente del estado que auditó el equipo de seguridad antes de ella. Y si el agente no registra de forma estructurada cada decisión de instalación, reproducir ese estado exacto para auditarlo después es, en la práctica, muy difícil.

A esto se suma el vector de los prompt injections en herramientas MCP: un servidor MCP malicioso o comprometido puede instruir al agente para que instale un paquete con nombre similar a uno legítimo (typosquatting) o modifique un archivo de configuración fuera del alcance declarado de la tarea.

Para quién es urgente esto

La cuestión es especialmente relevante para equipos que ya están usando Claude Code con MCP servers conectados a repositorios de paquetes o entornos de desarrollo en nube. También afecta a cualquier organización que haya automatizado parte de su pipeline de CI/CD con agentes LLM, independientemente del proveedor.

Los equipos de seguridad que hasta ahora gestionaban la cadena de suministro con controles perimetrales —listas de paquetes aprobados, lock files, revisión manual de PRs— necesitan replantearse qué ocurre cuando el agente puede saltarse esos controles por diseño, porque nadie pensó en incluirlos en el system prompt o en los hooks de Claude Code.

Algunos patrones de mitigación que circulan en la comunidad incluyen el uso de hooks `PreToolUse` para interceptar y registrar cualquier llamada de instalación de paquetes antes de ejecutarla, la aplicación de políticas de permisos estrictas en los MCP servers, y la generación de SBOMs (Software Bill of Materials) al final de cada sesión de agente, no solo en cada release.

Una nota de cierre

La explosión de estados no es un problema nuevo, pero su reaparición en el contexto de los agentes de IA merece atención seria. No porque la IA sea inherentemente insegura, sino porque los procesos de gobernanza de dependencias se diseñaron para un ritmo de cambio muy diferente al que imponen los agentes autónomos. Adaptar esos procesos es trabajo de ingeniería concreto, no de política de empresa.