Slopsquatting y agentes de código: proteger la cadena de suministro de software con IA

En poco tiempo, las herramientas de IA han pasado de ser un experimento a formar parte del equipamiento básico del desarrollo de software. En la Stack Overflow Developer Survey 2025, el 84 % de los encuestados afirmó utilizar herramientas de IA en el proceso de desarrollo o tener previsto hacerlo (2024: 76 %). En uso efectivo estaban en el 78,5 % de los casos, y a diario en el 47,1 %. En 2025, apenas un tercio utilizaba agentes de IA en el trabajo (alrededor del 31 %), y el 37,9 % no tenía planes en ese sentido.

Un año después, el foco se ha desplazado. En la encuesta de 2026 (30.903 respuestas válidas de 169 países), los asistentes y agentes de código son, con un 66 %, el caso de uso de IA más importante, por delante de los chatbots de uso general (63 %). Stack Overflow resume que la «inmensa mayoría» utiliza ya a diario asistentes y agentes de código (73 %); la cifra describe ambos en conjunto, no solo los agentes. El Octoverse 2025 de GitHub apunta en la misma dirección: más de 180 millones de desarrolladoras y desarrolladores, de los cuales unos 36 millones son nuevos, y casi el 80 % de los nuevos utiliza Copilot ya en su primera semana. GitHub no indica una tasa de aceptación de los pull requests del Coding Agent.

Los asistentes sugieren, los agentes ejecutan

Para la seguridad, importa menos cuánto código escribe un modelo que lo que se le permite hacer por sí mismo. Un asistente hace una sugerencia que una persona lee, acepta o descarta. Un agente trabaja en el terminal, ejecuta npm install o pip install, integra servidores MCP (Model Context Protocol, la interfaz con herramientas y fuentes de datos externas) y skills (paquetes de instrucciones reutilizables para agentes) y lee como contexto el contenido del repositorio, las issues y la documentación. HiddenLayer señala que los agentes pueden adoptar paquetes con typosquatting con menos revisión humana y que los servidores MCP remotos pueden cambiar sin que la organización lo advierta (HiddenLayer, 16/07/2026).

Está observado que los agentes ejecutan instrucciones de instalación sin comprobar quién es el propietario: unos investigadores encontraron en 6.214 dominios 8.265 archivos llms.txt o llms-full.txt; 120 de ellos remitían a paquetes o dominios no registrados. Después de ocupar algunos de esos nombres con paquetes baliza (beacon), una empresa de la lista Fortune 500 dio señales de vida en menos de una hora; las cadenas de procesos apuntaban a Claude, OpenAI Codex y Nous Research Hermes (según Schneier, citando a Ars Technica, 09/2026). No se trata de una alucinación —los nombres procedían de la documentación de los fabricantes—, pero sigue la misma lógica: quien ocupa primero un nombre libre determina lo que instala el agente. Tampoco las versiones son seguras: según Sonatype, en unas 37.000 recomendaciones de actualización generadas por IA analizadas, GPT-5 alucinó el 27,8 % de las versiones de componentes.

Tres fuentes de partida y su valoración

La idea central de este análisis en profundidad: hoy, la cadena de suministro de software empieza en el prompt. Un nombre de paquete que un modelo sugiere o que un agente toma de un archivo de skill es el primer eslabón de una cadena que, a través del registro, la resolución y la ejecución, llega hasta los tokens robados y la propagación. Quien solo evalúa el modelo pasa por alto las etapas en las que realmente puede interrumpirse un ataque.

En el typosquatting, un atacante registra un nombre tan parecido al de un paquete popular que puede confundirse con él, y apuesta por las erratas, la copia descuidada o las herramientas automatizadas. Los registros públicos asignan los nombres a quien llega primero; basta con una cuenta nueva. Los patrones son pocos:

Del autor aislado a la producción en cadena

Ni Check Point ni Microsoft relacionan estas campañas con la IA; se trata de typosquatting e imitación de marcas. Lo llamativo es el objetivo: se buscan entornos de build, roles en la nube y tokens de publicación, precisamente los permisos con los que trabajan también los agentes de código. Sonatype considera que el abuso de la confianza en nombres, herramientas y flujos de publicación conocidos fue el vector de ataque más eficaz del primer trimestre de 2026.

SANDWORM_MODE: el typosquatting apunta al agente

Marca la transición una campaña descrita por Socket el 20/02/2026: al menos 19 paquetes npm con typosquatting, tres de ellos imitaciones de Claude Code, robaban credenciales de npm, GitHub, CI y criptomonedas, así como claves de API de LLM de nueve proveedores. Además, registraban un servidor MCP propio en la configuración de Claude Code, Claude Desktop, Cursor, VS Code Continue y Windsurf. Sus herramientas, con nombres inocuos como index_project o lint_check, contenían una inyección de prompts: el asistente debía leer las claves SSH, las credenciales de AWS, .npmrc y .env y ocultar este paso al usuario. Para propagarse, el malware utilizaba tokens de npm robados, flujos de trabajo pull_request_target introducidos de forma subrepticia y SSH como vía alternativa.

Valoración de VamiSec: aquí el paquete solo abre la puerta. La verdadera carga útil es una modificación permanente del entorno del agente, que actúa en cada sesión futura con los permisos de la desarrolladora o el desarrollador.

Lo que hacen los registros, y dónde termina

• Comprobación de typosquatting: según PyPI, detecta y marca automáticamente el posible typosquatting al crear un proyecto; PyPI no indica umbrales ni cifras (balance anual de 2025).
• Cuarentena: los administradores pueden retirar proyectos del índice sin eliminarlos. Desde agosto de 2024 afectó a unos 140 proyectos, de los que solo uno volvió a liberarse (PyPI, 30/12/2024). En marzo de 2026, la cuarentena ya se activaba de forma automatizada a través de notificadores de confianza.
• Marcador de estado: mediante PEP 792, las API del índice señalan el estado «quarantined»; los instaladores deben advertir de ello.
• Tiempo de respuesta: en 2025, PyPI tramitó más de 2.000 notificaciones de malware, el 66 % en un plazo de cuatro horas y el 92 % en un plazo de 24 horas.

Los límites son estructurales. Todas estas medidas actúan después de la subida; la ventana de tiempo hasta la retirada sigue existiendo. También npm respondió a Shai-Hulud bloqueando las subidas que contenían indicadores conocidos, igualmente de forma reactiva. Y una comprobación de similitud solo detecta lo que se parece a un nombre existente. Precisamente por eso fracasa con los nombres que un modelo de lenguaje inventa libremente.

El término slopsquatting se atribuye a Seth Larson (Python Software Foundation); lo difundió Andrew Nesbitt el 08/04/2025. Designa lo siguiente: un modelo de lenguaje alucina un nombre de paquete inexistente y un atacante lo registra con código malicioso. La medición de referencia procede de Spracklen et al. (USENIX Security 2025, Distinguished Paper Award), que no utilizan el término.

Los investigadores hicieron que 16 modelos de código generaran 576.000 muestras de código en Python y JavaScript. Se consideró alucinado lo que el 10/01/2024 no existía en PyPI o npm, lo que constituye un límite inferior. El 19,7 % se refiere a las referencias a paquetes, no a las muestras de código.

Evidencias de la investigación y la práctica, de 2023 a 2026

En 2023, Bar Lanyado demostró en Vulcan Cyber que ChatGPT 3.5 recomendaba paquetes no publicados en más de 40 de 201 preguntas sobre Node.js y en más de 80 de 227 preguntas sobre Python. Para su estudio de seguimiento, publicado en 2024 en Lasso Security, subió un paquete vacío con el nombre alucinado de forma reiterada huggingface-cli (el real: huggingface_hub[cli]); según Lasso, obtuvo más de 30.000 descargas auténticas en tres meses. Alibaba incluyó pip install huggingface-cli en el primer commit del README de su repositorio GraphTranslator (26/02/2024).

Hasta ahora, ningún ataque documentado

A 08/10/2026 no se conoce ningún caso documentado públicamente en el que un atacante haya registrado con fines maliciosos un nombre demostrablemente alucinado y las víctimas lo hayan instalado a raíz de una sugerencia de IA. Que PhantomRaven (2025), por ejemplo, aprovechara el slopsquatting es una valoración de Koi sin evidencia publicada. Tampoco para los 53 nombres de Churilov observan Socket e InfoWorld registros maliciosos.

Valoración de VamiSec: esto no es motivo para bajar la guardia. Las condiciones previas están documentadas: las alucinaciones se repiten, una pequeña intersección es común a varios modelos y los marcadores de posición inofensivos recibieron instalaciones reales, últimamente, al parecer, por parte de agentes. Al mismo tiempo, un acierto sigue siendo difícil de detectar: el nombre no suele parecer una errata, y Seth Larson considera difícil, probablemente imposible, cuantificar los intentos de instalación de paquetes alucinados (The Register, 12/04/2025). Por tanto, la ausencia de casos documentados no demuestra que el riesgo sea bajo.

Entre la sugerencia de un nombre y el daño se encuentra la ejecución. Los gestores de paquetes ofrecen para ello varios puntos de detonación, y no todos pueden desactivarse con un solo interruptor. El consejo habitual de desactivar los scripts de ciclo de vida (ignore-scripts) es correcto, pero incompleto.

Seis incidentes, un patrón

1. 1
   CLI de IA como herramienta del atacantes1ngularity/Nx – 26/08/2025

   A través de un flujo de trabajo pull_request_target con inyección de shell, los atacantes se hicieron con el token de npm y publicaron versiones maliciosas de Nx durante unas cuatro horas. La carga útil buscaba CLI de IA instaladas localmente y, según Wiz, las iniciaba con --dangerously-skip-permissions, --yolo o --trust-all-tools para inventariar secretos. Según GitGuardian, solo lo logró en 95 de 366 sistemas objetivo (alrededor del 26 %); en total se hicieron públicos 2.349 secretos únicos.

2. 2
   Phishing, clipper de criptomonedaschalk/debug – 08/09/2025

   Un maintainer cayó en un correo de phishing de support@npmjs[.]help; el dominio se había registrado el 05/09/2025. Versiones maliciosas de 18 paquetes populares (Aikido; Socket cuenta 19 versiones), con más de 2.000 millones de descargas semanales según Aikido, sustituían en el navegador las direcciones de monederos interceptando fetch, XMLHttpRequest y window.ethereum.

3. 3
   Gusano mediante tokens robadosShai-Hulud – septiembre de 2025

   Un gusano autorreplicante inyectaba scripts post-install, buscaba secretos con TruffleHog, en variables de entorno y en metadatos de la nube y publicaba más paquetes con los tokens de npm sustraídos. GitHub retiró más de 500 paquetes comprometidos; Wiz atribuye la campaña a credenciales procedentes de s1ngularity.

4. 4
   preinstall y puerta trasera en runnersShai-Hulud 2.0 – desde el 24/11/2025

   La segunda oleada se activaba ya en la fase preinstall, camuflada como instalador de Bun, registraba los hosts infectados como runners de GitHub autoalojados y, según Wiz, creó más de 25.000 repositorios maliciosos. Si no conseguía robar credenciales ni exfiltrar datos, intentaba, según Unit 42, destruir el directorio personal.

5. 5
   Equipo del maintainer comprometidoaxios – 31/03/2026

   Tras una acción de ingeniería social y la infección de su equipo con un RAT (troyano de acceso remoto), aparecieron a través de la cuenta personal del maintainer principal axios 1.14.1 y 0.30.4 con una dependencia adicional que, en varias etapas, descargaba más malware, incluido un RAT, durante unas tres horas. En su alerta del 20/04/2026, CISA recomendó expresamente ignore-scripts=true y min-release-age=7 (días) en el .npmrc, así como MFA resistente al phishing.

6. 6
   Provenance válida, el agente como lugar de persistenciaTanStack / Mini Shai-Hulud – 11/05/2026

   A través de un flujo de trabajo pull_request_target y una caché de Actions envenenada, los atacantes leyeron de la memoria del runner el token OIDC para Trusted Publishing y publicaron 84 versiones maliciosas de 42 paquetes @tanstack, con provenance SLSA Build Level 3 válida (StepSecurity). Para persistir, el malware escribía un hook SessionStart en .claude/settings.json que ejecuta node .vscode/setup.mjs cada vez que se inicia Claude Code, además de una tarea de VS Code con runOn: folderOpen.

Dos lecciones

Primera: la provenance —la prueba firmada de qué repositorio y de qué build procede un paquete— acredita el origen, no la inocuidad. En palabras de StepSecurity, la provenance SLSA confirma qué pipeline generó un artefacto, no si se comportó como estaba previsto. En el caso «Miasma» de Red Hat, 32 paquetes manipulados también llevaban firmas válidas, porque los atacantes utilizaron la vía legítima de publicación OIDC (Microsoft, 02/06/2026). La propia documentación de npm señala que la provenance no garantiza un contenido libre de código malicioso.

Segunda: los tokens son la moneda de la propagación. La mayoría de estas cargas útiles buscaban credenciales de npm, GitHub, la nube o API de LLM y utilizaban los permisos de publicación para la siguiente oleada. Valoración de VamiSec: cada sesión de agente en la que sean accesibles tokens en texto claro, perfiles en la nube o permisos de escritura en el registro es un posible punto de partida de una oleada así. Mini Shai-Hulud muestra además que la propia configuración del agente se convierte en lugar de persistencia.

En su marco del 28/07/2026, HiddenLayer sitúa una tesis en el centro: la superficie de ataque esencial de un agente de código no es el modelo, sino su harness, es decir, los prompts, las herramientas, las skills, los servidores MCP y la lógica de orquestación en torno al modelo. HiddenLayer ve la raíz de los ataques en una confianza mal depositada. Ya el 16/07/2026, la empresa había calificado toda fuente que lee un agente como posible punto de entrada para la inyección indirecta de prompts.

Clases de ataque documentadas

OWASP clasifica las propias alucinaciones de paquetes en LLM09 Misinformation («Unsafe Code Generation»), no en LLM03 Supply Chain. En la lista agéntica, ASI05 cubre el caso de que paquetes instalados sin comprobar ejecuten código malicioso durante la instalación o la importación; ASI04 recomienda, entre otras cosas, comprobar si hay typosquats.

IDEsaster (Ari Marzouk) describe para Copilot, Cursor, Windsurf, Claude Code y otros IDE con IA una nueva cadena: inyección de prompts → herramientas → funciones básicas del IDE, como los esquemas JSON remotos o los ajustes del espacio de trabajo sobrescritos. A ello se suman errores en la lógica de aprobación y de sandbox de las CLI de agentes, como un diálogo de confirmación eludible en Claude Code (CVE-2025-54795, CVSS 4.0: 8,7) o una fuga del sandbox a través de un directorio de trabajo indicado por el modelo en Codex CLI (CVE-2025-59532, CVSS 4.0: 8,6).

Idea central: seguridad fuera del modelo

La mayoría de los casos comparten una estructura: el modelo hizo lo que su contexto le sugería. Donde los fabricantes introdujeron mejoras, no lo hicieron en el modelo, sino en el harness: mediante una nueva aprobación de las configuraciones MCP modificadas, el diálogo de confianza antes de cada ejecución, la comprobación canónica de rutas o listas de permitidos más restrictivas. En consecuencia, HiddenLayer titula así su capa de monitorización: la seguridad debe existir fuera del modelo. Valoración de VamiSec: trate los archivos de reglas, las configuraciones MCP, los hooks y las skills como código ejecutable —con revisión, control de versiones y aprobación— y cada fuente que lea el agente como entrada no fiable.

Lo que recomienda HiddenLayer (práctica)

HiddenLayer titula la primera capa de su marco del 28/07/2026 «Understand Every Trust Relationship», es decir, comprender cada relación de confianza. Se refiere a cuatro elementos:

• Todos los agentes, modelos, harnesses, herramientas, servidores MCP y skills en uso, incluida expresamente la IA en la sombra.
• Los permisos de cada agente y los sistemas a los que puede acceder.
• El origen y la integridad de las herramientas, las skills y los servicios externos.
• Las interacciones en tiempo de ejecución entre agentes, herramientas, repositorios y sistemas externos.

El origen y la integridad no son un formalismo: los servidores MCP remotos pueden cambiar sin que la organización lo advierta (HiddenLayer, 16/07/2026). Por eso, un inventario que solo contiene nombres queda obsoleto sin que nadie lo note. Frente a la IA en la sombra, el BSI y la ANSSI recomiendan cuentas corporativas controladas en lugar de accesos privados y reglas claras sobre qué herramientas pueden utilizarse con qué datos. En su recomendación sobre gestores de paquetes del 10/03/2026, jurídicamente no vinculante, ENISA aconseja además tener visibilidad sobre todos los paquetes que seleccionan las herramientas de IA.

Implantación: lista de materiales de agentes y SBOM (recomendación de VamiSec)

Recomendamos llevar el inventario como lista de materiales de agentes (AI-BOM): un registro legible por máquina que recoja, para cada agente, la herramienta y su versión, el modelo y el proveedor, el modo de funcionamiento, los servidores MCP y skills conectados con su versión o hash, los archivos de reglas y la identidad utilizada. Junto a él figura la SBOM (Software Bill of Materials, lista de materiales de todos los componentes de software) de cada release. Ambas responden en caso de incidente a la misma pregunta: ¿dónde está el componente afectado?

En cuanto a la profundidad de la SBOM, conviene ser preciso. El CRA exige en el anexo I, parte II, punto 1 una SBOM en un formato habitual y legible por máquina que cubra como mínimo las dependencias de primer nivel, aplicable a partir del 11/12/2027; actualmente no prescribe un formato concreto. La BSI TR-03183-2 (versión 2.1.0), en cambio, exige para las SBOM conformes con la TR una resolución recursiva y menciona CycloneDX a partir de la 1.6 o SPDX a partir de la 3.0.1. El código malicioso puede llegar a través de dependencias transitivas: la versión maliciosa axios 1.14.1 añadía la dependencia plain-crypto-js, que descargaba etapas maliciosas adicionales (CISA, 20/04/2026). Por eso recomendamos la SBOM recursiva como estándar de trabajo, como buena práctica y no como obligación del CRA. Según ENISA (SBOM Adoption State of Play, junio de 2026), el 24 % de los encuestados necesita un análisis de profundidad completa, pero solo el 14 % lo obtiene.

Relación con la cadena de ataque

La visibilidad no es un punto de ruptura, pero sí la condición previa para todos los demás. Dificulta la etapa 03 (Adopción), porque los nuevos paquetes, servidores MCP y skills llaman la atención. Sin inventario, las listas de permitidos, el aislamiento y la monitorización no pueden imponerse de forma generalizada. Tras un incidente, limita la etapa 07 (Propagación): los repositorios, hosts y tokens afectados pueden identificarse de inmediato, en lugar de tener que buscarlos primero.

Anclaje normativo: las entidades financieras sujetas al marco completo de DORA deben hacer un seguimiento, conforme al art. 10(2)(d) del Reglamento Delegado (UE) 2024/1774 (RTS sobre gestión del riesgo de TIC), de las bibliotecas de terceros y de código abierto que utilizan los servicios TIC que soportan funciones críticas o importantes, incluidas sus versiones y actualizaciones. Grundschutz++ del BSI prevé como requisito SOLLTE (recomendado) documentar los componentes mediante una SBOM antes del release (DEV.4.3, con referencia a la TR-03183-2).

Lo que recomienda HiddenLayer (práctica)

Bajo «Limit the Impact of Compromise», HiddenLayer menciona cinco medidas: el mínimo privilegio como norma, la aprobación humana para acciones con consecuencias, el acceso únicamente a herramientas, servidores MCP y skills aprobados, la limitación de las conexiones de red salientes innecesarias y la revisión de los prompts de sistema y de las configuraciones por defecto antes de su uso. El OWASP Top 10 for Agentic Applications 2026 amplía el mínimo privilegio a «Least Agency»: ninguna autonomía donde no se necesite. La guía de CISA, la NSA y las autoridades asociadas de Five Eyes del 01/05/2026 aconseja igualmente no conceder a los agentes un acceso amplio a datos sensibles y sistemas críticos.

Que los valores por defecto no son automáticamente seguros lo demuestran vulnerabilidades documentadas: antes de la versión 1.0.4, Claude Code contenía una lista demasiado amplia de comandos «seguros» a través de los cuales podía filtrarse el contenido de archivos sin confirmación (CVE-2025-55284, CVSS 4.0: 7,1). En GitHub Copilot (VS Code/Visual Studio), la obligación de confirmación podía desactivarse por completo mediante inyección de prompts (CVE-2025-53773, véase el capítulo 5).

Implantación en seis pasos (recomendación de VamiSec)

1. 1
   Entorno de ejecuciónAislar

   Los agentes con acceso al terminal y las builds se ejecutan en contenedores, devcontainers o máquinas virtuales, sin credenciales del host montadas, sin agente SSH ni perfiles en la nube. Si se ejecuta código malicioso, debe encontrar lo menos posible que merezca la pena robar.

2. 2
   IdentidadAsignar una identidad propia

   El agente no trabaja con los tokens personales de la desarrolladora, sino con una identidad propia y acotada: solo los repositorios y scopes que necesita la tarea, sin permiso de publicación.

3. 3
   TokensCredenciales de corta duración

   Publicar los paquetes propios mediante Trusted Publishing (OIDC) en lugar de con tokens almacenados; en npm, disponible de forma general desde el 31/07/2025, a partir de npm CLI 11.5.1. Donde sigan existiendo tokens, elegir la vigencia más corta que resulte practicable.

4. 4
   Herramientas, MCP, skillsImponer listas de permitidos

   Solo pueden cargarse herramientas, servidores MCP y skills aprobados; los paquetes llegan exclusivamente a través del proxy interno (véase Higiene de dependencias).

5. 5
   RedLimitar el egress

   Tráfico saliente solo hacia destinos aprobados. También las herramientas inofensivas transportan datos: en 2025, HiddenLayer mostró cómo una clave SSH se filtraba a través de la URL de imagen de un diagrama.

6. 6
   ConfiguraciónDefinir los ajustes de forma centralizada

   Autoaprobación desactivada; aprobación obligatoria para instalaciones, comandos de red y accesos de escritura a la configuración del agente. Bloquear flags como --dangerously-skip-permissions, --yolo o --trust-all-tools: según Wiz, el malware de s1ngularity invocaba las CLI de IA locales precisamente con ellos. Donde la herramienta admita políticas gestionadas de forma centralizada, estas deben prevalecer sobre los ajustes procedentes del repositorio.

La aprobación humana solo es eficaz si la persona ve lo que aprueba. En la demo de tool poisoning de Invariant Labs, el diálogo de confirmación no mostraba las entradas completas. El BSI recomienda expresamente una confirmación por parte del usuario antes de que un LLM ejecute funciones (Evasion Attacks on LLMs, 06/11/2025). Recomendamos diálogos que muestren por completo el comando, el nombre del paquete y el destino, y pocas aprobaciones, tomadas en serio, en lugar de confirmaciones constantes.

Relación con la cadena de ataque

Esta capa aporta la mayoría de los puntos de ruptura: el aislamiento sin secretos del host interrumpe la etapa 06 (Acceso); el control del egress, la etapa 07 (Propagación); la lista de permitidos en el proxy, la etapa 04 (Resolución). La aprobación humana dificulta la etapa 03 (Adopción). Los tokens de corta duración y acotados limitan hasta dónde llegan las credenciales robadas.

Evidencias para auditores

• Configuración centralizada por agente (autoaprobación, obligaciones de aprobación, flags bloqueados) con historial de cambios.
• Definición de la imagen o del devcontainer sin credenciales montadas, junto con las reglas de egress.
• Inventario de tokens con identidad, scope y fecha de caducidad; Trusted Publishing para los paquetes propios.
• Muestras de los registros de aprobación.

Anclaje normativo: para las entidades esenciales e importantes, el art. 21(2)(e) de NIS2 y el § 30(2), segunda frase, n.º 5 BSIG exigen medidas de seguridad en la adquisición, el desarrollo y el mantenimiento. El Reglamento de Ejecución (UE) 2024/2690 exige, para los tipos de entidades allí mencionados, como los proveedores de servicios en la nube y de servicios gestionados, requisitos de seguridad para los entornos de desarrollo (anexo, punto 6.2). Las entidades financieras sujetas al marco completo de DORA deben separar la aprobación de los cambios de su solicitud y ejecución (art. 17(1) del RTS 2024/1774 en relación con el art. 9(4)(e) de DORA); un agente que aprueba sus propios cambios difícilmente es compatible con ello (valoración de VamiSec).

Lo que recomienda HiddenLayer (práctica)

• Probar los agentes con entradas adversariales antes de su uso (red teaming).
• Comprobar las acciones propuestas antes de su ejecución.
• Comprobar las herramientas y skills de terceros, incluidos los metadatos ocultos.
• Aprobar versiones concretas en lugar de confiar de forma permanente en «latest».

El último punto apunta al rug pull: un servidor MCP modifica la descripción de su herramienta después de haber sido aprobado (Invariant Labs, 01/04/2025). MCPoison mostró el mismo patrón en la configuración: tras la primera aprobación, bastaba un commit para sustituir el comando de una entrada MCP sin nueva confirmación (CVE-2025-54136, véase el capítulo 5). Según The Register, el paquete npm no oficial postmark-mcp entregó 15 versiones inocuas antes de que la versión 1.0.16 enviara cada correo electrónico saliente con copia oculta a una dirección ajena.

Los metadatos ocultos son el segundo foco. Las instrucciones en las descripciones de herramientas son invisibles para los usuarios, pero el modelo las lee (Invariant Labs); los archivos de reglas pueden contener instrucciones en caracteres Unicode invisibles (Pillar Security, 18/03/2025). De las 3.984 agent skills analizadas por Snyk, 76 eran demostrablemente maliciosas (05/02/2026; detalles en el capítulo 5).

Implantación: aprobación por componente (recomendación de VamiSec)

Para el código de IA no hay una vía especial. El BSI y la ANSSI señalan que los asistentes de código con IA no sustituyen a los desarrolladores experimentados y que las ganancias de productividad deben compensarse con más aseguramiento de la calidad (04/10/2024). Los archivos de instrucciones como AGENTS.md ayudan, pero no son un control. La guía de la OpenSSF para asistentes de código (01/08/2025) recomienda la instrucción de no añadir dependencias que puedan ser maliciosas o alucinadas. Esto puede reducir el riesgo, pero el modelo puede ignorar la regla, e instrucciones de skills de apariencia inofensiva pueden incluso reforzar las alucinaciones de paquetes (Hsu et al., aceptado para EMNLP 2026).

Red teaming antes del despliegue

1. 1
   Definir escenarios

   Tareas que provoquen sugerencias de paquetes; README, issues y descripciones de herramientas preparados con instrucciones ocultas; intentos de modificar los ajustes del agente o de leer archivos de credenciales.

2. 2
   Ejecutar en la configuración objetivo

   Exactamente con el modelo, el harness, los servidores MCP y las skills que se vayan a desplegar, en un entorno aislado.

3. 3
   Medir

   ¿Con qué frecuencia inventa paquetes el agente? ¿Sigue instrucciones inyectadas? ¿Funcionan la aprobación, el proxy y el aislamiento de la capa 2?

4. 4
   Repetir

   Con cada cambio de modelo, versión de la herramienta o integración, y como prueba de regresión tras los incidentes.

Relación con la cadena de ataque: la validación dificulta las etapas 01 (Invención) y 03 (Adopción), porque los nombres inventados llaman la atención en las pruebas y en la revisión. La aprobación de versiones impide que un componente modificado sin aviso se descargue en la etapa 04 (Resolución). Evidencias para auditores: informe de red team por configuración de agente, lista de permitidos con versiones y hashes, actas de revisión de las nuevas dependencias, evidencias de pruebas del código generado por IA.

Anclaje normativo: para las entidades financieras sujetas al marco completo de DORA, el art. 16 del RTS 2024/1774 exige revisiones del código fuente con pruebas estáticas y dinámicas (apartado 3), pruebas de seguridad de los paquetes de software a más tardar en la fase de integración (apartado 4) y, en la medida de lo posible, el análisis y las pruebas del código fuente abierto antes de su paso a producción (apartado 8). El CRA exige a los fabricantes, a partir del 11/12/2027, pruebas y revisiones de seguridad eficaces y periódicas (anexo I, parte II, punto 3).

HiddenLayer justifica la cuarta capa de forma escueta: los modelos de lenguaje están diseñados para seguir instrucciones, no para imponer políticas de seguridad (en sustancia). Un control que solo figura en el prompt cae con la primera inyección de prompts que tenga éxito. Por eso, la supervisión se sitúa en el sistema operativo, la red, la pipeline y el harness. El OWASP Top 10 for Agentic Applications califica una observabilidad sólida de «no negociable».

Lo que HiddenLayer quiere observar (práctica)

• Movimientos de datos sensibles
• Uso de herramientas y operaciones con archivos
• Intentos de escalada de privilegios
• Actividad de IA en la sombra
• Uso de API y consumo de computación anómalo

Ideas de detección a partir de incidentes reales (recomendación de VamiSec)

Las campañas de los últimos meses aportan patrones concretos. Según StepSecurity, la oleada Mini Shai-Hulud en torno a TanStack se afianzó mediante un hook SessionStart de Claude Code y una tarea de VS Code (detalles en el capítulo 4). Según Socket, SANDWORM_MODE registraba un servidor MCP propio en la configuración de Claude Code, Cursor y otras herramientas. Según Microsoft, Miasma mantenía en reserva un canal de exfiltración latente a través de api.anthropic.com; según Snyk, el dominio de exfiltración de las releases de litellm se había registrado un día antes. Varias oleadas iniciaban Bun como entorno de ejecución, una forma de eludir la monitorización centrada en Node.

Telemetría mediante hooks de agentes

Varios agentes de código ofrecen interfaces de hooks que inician programas propios cuando se llama a herramientas. Recomendamos utilizarlas para registrar de forma centralizada las llamadas a herramientas, los comandos de shell y los accesos a archivos, y para comprobar las llamadas de riesgo antes de su ejecución. Sin embargo, esa misma interfaz es una vía de persistencia, como demuestra la oleada de TanStack; en Claude Code, los hooks de archivos de proyecto llegaron a ejecutarse temporalmente sin consentimiento (Check Point, corregido el 26/08/2025). Por eso, los hooks deben formar parte de la configuración gestionada de forma centralizada, y cada cambio en ella es en sí mismo una señal de alarma.

Relación con la cadena de ataque: la monitorización no interrumpe ninguna etapa de forma fiable, pero acorta el tiempo durante el cual las etapas 05 (Ejecución), 06 (Acceso) y 07 (Propagación) pasan desapercibidas. Los incidentes muestran lo cortas que son las ventanas: las versiones maliciosas de TanStack se marcaron como obsoletas tras unas 1,7 horas, y las de axios se retiraron tras unas tres horas. De ello concluimos que la detección propia debe reaccionar en horas, no en días.

Anclaje normativo: el Reglamento de Ejecución (UE) 2024/2690 exige, para los tipos de entidades allí mencionados, protección frente a software malicioso y no autorizado, incluidas medidas de detección (anexo, punto 6.9); para las demás entidades NIS2 sirve de orientación. La guía de Five Eyes sobre IA agéntica (01/05/2026) menciona expresamente la monitorización continua.

Lo que recomienda HiddenLayer (práctica)

Bajo «Security Requires Ownership», HiddenLayer menciona cuatro puntos: una persona responsable (owner) para cada agente en uso productivo, la inclusión de los agentes de código en los modelos de amenazas y programas de gobernanza de IA existentes, procedimientos de respuesta a incidentes específicos para la IA agéntica y la revisión periódica de los permisos y de las integraciones de confianza. También la guía de Five Eyes del 01/05/2026 recomienda integrar los riesgos de la IA agéntica en los marcos existentes y practicar el modelado de amenazas.

Para las entidades NIS2, es una tarea de la dirección. Los órganos de dirección deben aprobar las medidas de gestión de riesgos, supervisar su aplicación y pueden ser considerados responsables (art. 20(1) y (2) de NIS2). En Alemania, el § 38 BSIG obliga a los órganos de dirección de las entidades esenciales e importantes a la aplicación, la supervisión y la formación periódica; la responsabilidad se rige por el derecho de sociedades. Por eso, una política para herramientas de código con IA debería estar aprobada por la dirección.

Elementos de una política para herramientas de código con IA (recomendación de VamiSec)

• Herramientas, modelos y modos de funcionamiento autorizados; uso solo a través de cuentas corporativas.
• Clases de datos: qué información puede introducirse en qué herramienta.
• Niveles de autonomía: qué puede hacer un agente por sí mismo, qué requiere aprobación y qué está prohibido.
• Reglas para paquetes: obtención solo a través del proxy interno, periodo de espera, ningún script de instalación sin aprobación.
• Proceso de aprobación para servidores MCP, skills y archivos de reglas, vinculado a una versión o un hash.
• Principio de los cuatro ojos para los merges, también en los pull requests de agentes.
• Registro, procedimiento de excepciones y recertificación de permisos e integraciones, por ejemplo, semestral.
• Formación: desde el Ómnibus Digital (Reglamento (UE) 2026/1744, en vigor desde el 27/07/2026), el art. 4 del Reglamento de IA exige a proveedores y responsables del despliegue medidas para apoyar la alfabetización en IA, pero no un nivel garantizado.

En el modelo de amenazas, el agente aparece como un actor propio con permisos; los archivos de reglas, las skills, los servidores MCP y las fuentes de paquetes son fronteras de confianza. El borrador de ENISA sobre desarrollo de software asistido por IA (v0.4, septiembre de 2026) describe para ello amenazas STRIDE como la introducción subrepticia de paquetes, skills o archivos de instrucciones maliciosos.

Playbook de respuesta a incidentes: paquete malicioso instalado o agente comprometido

1. 1
   ContenerAislar

   Desconectar de la red los hosts, contenedores y runners afectados, finalizar las sesiones de agente en curso y detener las pipelines que usen el paquete. Preservar las evidencias antes de reinstalar.

2. 2
   ContenerRotar las credenciales

   Todos los secretos accesibles: tokens del registro, tokens de la plataforma Git, accesos a la nube y a Vault, claves de API de modelos. Tras Shai-Hulud, CISA aconsejó expresamente la rotación. Sin el inventario de tokens de las capas 1 y 2, este paso queda incompleto.

3. 3
   LimpiarRevisar lockfiles y cachés

   ¿Qué repositorios, lockfiles y cachés de paquetes y de CI contienen las versiones afectadas? En TanStack, el ataque se produjo a través de una caché de GitHub Actions envenenada: las cachés forman parte de la limpieza.

4. 4
   LimpiarBuscar persistencia en la configuración del agente

   Hooks y entradas MCP en las configuraciones de usuario y de proyecto, tareas de VS Code con runOn: folderOpen, nuevos runners autoalojados y flujos de trabajo, archivos .pth. En caso de duda, reinstalar en lugar de limpiar.

5. 5
   NotificarComprobar las obligaciones de notificación

   Desde el 11/09/2026, los fabricantes sujetos al CRA notifican las vulnerabilidades activamente explotadas de sus productos a través de la Single Reporting Platform, simultáneamente al CSIRT coordinador y a ENISA: alerta temprana en un plazo de 24 horas, notificación en un plazo de 72 horas e informe final a más tardar 14 días después de que esté disponible una medida correctora. Es relevante si el código malicioso ha podido llegar a un producto entregado (valoración de VamiSec; revisar jurídicamente en cada caso). Las entidades NIS2 y DORA comprueban en paralelo sus propias vías de notificación.

6. 6
   AprenderAnalizar a posteriori

   Documentar la causa, la etapa alcanzada y los puntos de ruptura que faltaban, recertificar permisos e integraciones e informar a los operadores del registro y a los maintainers.

Relación con la cadena de ataque: la gobernanza dificulta la etapa 07 (Propagación), porque está aclarado de antemano quién rota qué tokens, quién bloquea qué y quién notifica a quién. Al mismo tiempo, mantiene actualizadas las demás capas: sin recertificación, los permisos y las integraciones crecen de forma insidiosa.

En la obtención de paquetes, el peso principal recae en el periodo de espera —una antigüedad mínima de las nuevas versiones antes de su instalación— y en el bloqueo de los scripts de instalación. Preste atención a las unidades.

Hay dos límites que deben tenerse en cuenta. En primer lugar, un periodo de espera intercepta las versiones maliciosas que, según pnpm, suelen detectarse y retirarse en el plazo de una hora, pero no un nombre alucinado que un atacante ocupa pronto y deja reposar. En segundo lugar, ignore-scripts es incompleto: las dependencias Git pueden ejecutar código a través de un .npmrc propio (contra ello, --allow-git=none desde npm 11.10.0), las dependencias por URL como en PhantomRaven necesitan --allow-remote=none (desde 11.15.0) y ningún bloqueo de scripts abarca el código de importación.

Configuración para builds y agentes (recomendación de VamiSec)

# Builds de CI y agentes: solo a través del proxy interno (marcador de posición)
registry=https://registry.intern.example/
# sin scripts de ciclo de vida
ignore-scripts=true
# solo versiones con más de 7 días de antigüedad (desde npm 11.10.0)
min-release-age=7

# pyproject.toml: solo versiones con más de 7 días de antigüedad (desde uv 0.9.17)
[tool.uv]
exclude-newer = "7 days"
# Excepciones por paquete: exclude-newer-package

# pip desde 26.1: duración en días, además de hashes obligatorios
pip install --require-hashes --uploaded-prior-to P7D -r requirements.txt

Excluir las actualizaciones de seguridad: un periodo de espera no debe retrasar las correcciones. Dependabot y Renovate lo omiten por defecto para las actualizaciones de seguridad, y los gestores de paquetes admiten listas de excepciones (min-release-age-exclude, minimumReleaseAgeExclude, minimumReleaseAgeExcludes, exclude-newer-package). PyPI aconseja combinar los periodos de espera con análisis de vulnerabilidades.

Lockfiles, revisión, proxy, provenance

En los entornos de CI y de agentes, instalar solo de forma reproducible: npm ci, pnpm install --frozen-lockfile, pip con --require-hashes. En el caso de LiteLLM, según PyPI, alrededor del 40 al 50 % de las instalaciones en la ventana del ataque no tenían versiones fijadas. OWASP describe el caso de un agente que regenera un lockfile a partir de especificaciones sin fijar y obtiene una versión menor comprometida; por eso, cada nueva dependencia y cada cambio en el lockfile necesitan una aprobación nominal en la revisión de dependencias. Técnicamente, esto lo impone un proxy de registro interno con lista de permitidos; el BSI y la ANSSI recomiendan una lista de permitidos de paquetes autorizados. Una mera comprobación de existencia no basta: el atacante puede haber registrado el nombre previamente (Spracklen et al.).

npm audit signatures comprueba las firmas del registro y las atestaciones de provenance (desde npm 9.5.0); desde el 14/11/2024, PyPI admite atestaciones conforme a PEP 740, que, según Trail of Bits, pip y uv no comprueban automáticamente. Ambas acreditan el origen, no la inocuidad: también los paquetes maliciosos de TanStack y Miasma llevaban provenance o firmas válidas (véase el capítulo 4). Como comprobación adicional es útil; como único criterio de aprobación, inadecuada.

Anclaje normativo: la recomendación de ENISA sobre gestores de paquetes (10/03/2026), jurídicamente no vinculante, aconseja utilizar registros oficiales y verificables, lockfiles y comprobaciones de integridad en CI/CD. Grundschutz++ prevé como requisitos SOLLTE (recomendados) prohibir los artefactos externos de fuentes desconocidas, comprobar su integridad y verificar si hay actualizaciones de seguridad (DEV.4.2, DEV.4.4, DEV.4.5); el Kompendium 2023 exige fuentes de confianza y la comprobación de los componentes desconocidos (CON.8.A6, CON.8.A20). El art. 21(2)(d) de NIS2 y el § 30(2), segunda frase, n.º 4 BSIG exigen seguridad de la cadena de suministro; a partir del 11/12/2027, los fabricantes sujetos al CRA tienen la obligación de diligencia debida respecto a los componentes de terceros conforme al art. 13(5), también expresamente para el código abierto.

El CRA, NIS2 y DORA parten de un enfoque similar: es responsable quien integra el componente o explota el sistema (valoración de VamiSec). Para el Cyber Resilience Act (CRA), lo muestra el ejemplo 34 de las directrices de la Comisión C(2026) 5252 del 27/07/2026: un desarrollador individual que publica una biblioteca libre de código abierto en un repositorio público de paquetes, y el propio repositorio, no tienen obligaciones derivadas del CRA. La obligación de diligencia debida del art. 13(5) recae, a partir del 11/12/2027, en el fabricante integrador, con un enfoque basado en el riesgo conforme al considerando 34. Las directrices no son vinculantes. Que el paquete lo eligiera una persona o un agente no cambia nada al respecto (valoración de VamiSec).

Cyber Resilience Act: obligación de notificación desde 2026, diligencia debida desde 2027

• Obligación desde el 11/09/2026 (art. 14(1)–(2)): notificar las vulnerabilidades activamente explotadas a través de la Single Reporting Platform (SRP) al CSIRT y a ENISA — alerta temprana en un plazo de 24 h, notificación en un plazo de 72 h, informe final a más tardar 14 días después de que esté disponible una medida correctora; también para los productos ya comercializados.
• Obligación a partir del 11/12/2027: diligencia debida con los componentes de terceros, incluido el software libre de código abierto (art. 13(5)); notificar las vulnerabilidades de los componentes a su fabricante o maintainer (apartado 6); no entregar productos con vulnerabilidades explotables conocidas (anexo I, parte I, punto 2, letra a).
• SBOM: el anexo I, parte II, punto 1 exige como mínimo las dependencias de primer nivel; solo la BSI TR-03183-2 v2.1.0 exige una resolución recursiva — buena práctica, no obligación del CRA. El CRA no prescribe ningún formato como CycloneDX o SPDX; la Comisión no recoge en su lista ningún acto de ejecución al respecto (art. 13(24), disposición potestativa; a 27/07/2026).
• Multas (art. 64(2)): por infracciones del anexo I, del art. 13 o del art. 14, hasta 15 millones de EUR o el 2,5 % del volumen de negocios anual mundial, si esta cuantía es superior.

NIS2 y BSIG: cadena de suministro y desarrollo como medidas mínimas

NIS2 exige seguridad en la cadena de suministro (art. 21(2)(d)) y en la adquisición, el desarrollo y el mantenimiento (letra e). El art. 21(3), según el cual las entidades, al elegir las medidas relativas a la cadena de suministro, tienen en cuenta también los procesos de desarrollo seguro de sus proveedores directos, no figura literalmente en el BSIG; puede invocarse mediante la interpretación conforme a la directiva. En Alemania se aplica desde el 06/12/2025 el § 30(2), segunda frase, n.º 4 y 5 BSIG; el órgano de dirección aplica, supervisa y responde, en caso de incumplimiento culposo, conforme al derecho de sociedades (§ 38 BSIG, art. 20 NIS2). Por medidas inexistentes o no documentadas, el § 65 prevé multas de hasta 10 millones de EUR (entidades esenciales) o 7 millones de EUR (entidades importantes) y, con un volumen de negocios total superior a 500 millones de EUR, de hasta el 2 % o el 1,4 % del volumen de negocios total. El Reglamento de Ejecución (UE) 2024/2690 solo es vinculante para los tipos de entidades enumerados en su art. 1, como los proveedores de servicios en la nube, de centros de datos y de servicios gestionados; para todos los demás sirve de orientación.

DORA: los anclajes precisos están en el RTS

Desde el 17/01/2025, DORA exige que los cambios en los sistemas de TIC se registren, prueben, evalúen, aprueben, implementen y verifiquen (art. 9(4)(e)), y mantiene la plena responsabilidad de las entidades financieras sobre los servicios TIC (art. 28(1)). Para las bibliotecas obtenidas libremente, el RTS 2024/1774 es más preciso (marco completo, título II): hacer un seguimiento de las bibliotecas para funciones críticas o importantes (art. 10(2)(d)), revisiones de código con pruebas estáticas y dinámicas (art. 16(3)), probar los paquetes de software a más tardar en la integración (apartado 4), proteger la integridad del código fuente (apartado 7), comprobar el código abierto antes de su paso a producción, en la medida de lo posible (apartado 8), y separar la aprobación y la implementación de los cambios (art. 17(1)). Un agente que hace merge de sus propios pull requests no encaja en ello (valoración de VamiSec).

AI Act y responsabilidad por productos

Según el AI Act, un asistente de código no suele ser un sistema de alto riesgo, ya que el desarrollo de software no figura en el anexo III. Para las empresas que lo utilizan queda el art. 4: desde el Ómnibus Digital (Reglamento (UE) 2026/1744, en vigor desde el 27/07/2026), deben adoptar medidas para apoyar la alfabetización en IA, sin tener que garantizar un nivel. Las obligaciones relativas a los modelos GPAI recaen en los proveedores de modelos, no en los usuarios. Según la Directiva sobre responsabilidad por productos defectuosos (UE) 2024/2853, el software es un producto; para los productos introducidos en el mercado después del 09/12/2026, el fabricante responde frente a las personas físicas también por los componentes defectuosos integrados bajo su control, y la falta de actualizaciones de seguridad no lo exime. La directiva surte efecto a través del derecho nacional; a 08/10/2026 no se ha verificado la promulgación del proyecto de ley del Gobierno alemán (BT-Drs. 21/4297).

Guías: orientación no vinculante

• ENISA, Secure Use of Package Managers (10/03/2026): menciona expresamente el slopsquatting y recomienda hacer visibles los paquetes elegidos por IA y comprobarlos de forma automatizada en CI/CD.
• ENISA, AI-assisted software development (borrador v0.4, septiembre de 2026): paquetes alucinados, skills y archivos de instrucciones introducidos de forma subrepticia — aún no definitivo.
• BSI y ANSSI, AI Coding Assistants (04/10/2024): las alucinaciones de paquetes como vía hacia la «package confusion»; comprobación de plausibilidad, listas de permitidos, sandboxing.
• BSI Grundschutz++ DEV.4.2 a DEV.4.5 (requisitos SOLLTE, recomendados): prohibir los artefactos de fuentes poco fiables o desconocidas, también paquetes y modelos; SBOM, pruebas de integridad. Kompendium 2023: CON.8.A6, CON.8.A20.

El plan es una recomendación de VamiSec y sigue la cadena de ataque: primero crea visibilidad y cierra las brechas evidentes, después introduce puntos de ruptura en las etapas 04 Resolución y 05 Ejecución y, por último, hace que las reglas sean vinculantes y medibles. El punto de partida es un inventario honesto de la situación, por ejemplo, con la autoevaluación de esta página. Las empresas reguladas empiezan por lo que ya está en vigor: obligaciones de notificación del CRA desde el 11/09/2026, medidas del BSIG desde el 06/12/2025, DORA desde el 17/01/2025.

Diez indicadores con valores objetivo

Mida lo que realmente interrumpe la cadena, no el número de formaciones. Los valores objetivo son recomendaciones de VamiSec, no umbrales regulatorios; la mayoría pueden obtenerse automáticamente de los logs del proxy, de la configuración de CI y de la configuración centralizada de los agentes. Lo arriesgados que son los modos sin confirmación lo muestra s1ngularity: según Wiz, el malware invocaba las CLI de IA instaladas localmente con flags como --dangerously-skip-permissions y --yolo para inventariar secretos. Informe trimestralmente al órgano de dirección; en las entidades NIS2, este debe supervisar en cualquier caso la aplicación de las medidas conforme al § 38 BSIG.

Evidencias para auditores

• Inventario de las herramientas de código con IA, agentes, servidores MCP y skills con owner, versión y permisos (AI-BOM)
• Política para herramientas de código con IA, aprobada por el órgano de dirección (art. 20(1) de NIS2; aplicación y supervisión conforme al § 38 BSIG)
• Configuración versionada del proxy, los gestores de paquetes, los bots de actualización y las reglas de egress — el § 30(1) BSIG exige documentar el cumplimiento de las medidas
• Registros de aprobación de nuevas dependencias y extensiones de agentes procedentes del historial de pull requests, con aprobación humana de los cambios de los agentes (para entidades financieras sujetas a DORA: segregación de funciones conforme al art. 17(1) del RTS 2024/1774)
• SBOM por release: como mínimo las dependencias de primer nivel (CRA, anexo I, parte II, punto 1, a partir del 11/12/2027), mejor de forma recursiva conforme a la BSI TR-03183-2 v2.1.0
• Evidencias de pruebas de los paquetes de software a más tardar en la fase de integración (art. 16(4) del RTS 2024/1774) e informe de red teaming de los agentes
• Playbook de incidentes con lista de rotación de tokens y vías de notificación conforme al art. 14 del CRA (24 h / 72 h / 14 días), junto con el acta del ejercicio
• Informe trimestral de KPI al órgano de dirección