El 26% de las skills de IA contiene vulnerabilidades. El 5% es probablemente malicioso. Y la mayoría de los desarrolladores instala esto en Claude Code, Cursor y Codex sin auditoría. Según Liu et al. (arXiv:2601.10338, enero de 2026), que analizaron 31.132 skills, el 26,1% presenta vulnerabilidades y el 5,2% muestra intención probablemente maliciosa. NVIDIA cita ese estudio en el README del SkillSpector, el número es de la investigación, no de NVIDIA. Seguimos este ecosistema desde el inicio y la señal es clara: el problema es estructural, no de herramienta.
El ecosistema de skills es el nuevo npm
Los desarrolladores instalan skills en Claude Code, Cursor y Codex de la misma forma que instalaban paquetes npm en 2015, sin auditoría, sin verificación, sin modelo de amenazas. La diferencia es de magnitud: un paquete npm roba credenciales. Una skill de IA roba credenciales E instruye al agente para que actúe en tu nombre. Un agente comprometido accede a tus datos, ejecuta comandos en tu entorno y puede escalar privilegios dentro de tu pipeline de CI/CD.
Según Liu et al. (arXiv:2601.10338), de las 31.132 skills analizadas, 8.124 contenían vulnerabilidades y 1.619 mostraron intención probablemente maliciosa. Estos números son de la investigación académica, NVIDIA cita el estudio, no lo produjo. El ecosistema está creciendo exponencialmente y la superficie de ataque crece junto.
Trail of Bits demostró que los escáneres pueden ser burlados
Trail of Bits demostró cuatro técnicas que burlan todos los escáneres de skills existentes. Tres se construyeron en menos de 1 hora:
- Whitespace inflation: 100 mil saltos de línea esconden el payload por debajo del límite que el escáner lee. El escáner trunca el análisis antes de llegar al código malicioso.
- Bytecode .pyc: el código compilado en bytecode es invisible para el análisis estático basado en texto. El escáner ve un archivo inofensivo; el runtime ejecuta el payload.
- Indirección .docx: un script malicioso incrustado en el XML ZIP de un documento .docx. El escáner evalúa el documento; el agente ejecuta el script incrustado.
- Prompt injection contra el escáner de LLM: ingeniería social aplicada al propio verificador. El escáner semántico es un LLM, y los LLM son vulnerables a prompt injection. El atacante convence al escáner de que el código es seguro.
Estas técnicas no son teóricas. Son prácticas, rápidas de implementar y eficaces contra toda la clase de escáneres estáticos.
El SkillSpector, el mejor escáner estático disponible
Según el repositorio de NVIDIA en GitHub, el SkillSpector (10.7K estrellas, Apache 2.0, marzo de 2026) usa un pipeline de dos etapas: análisis estático con regex, AST, YARA y OSV.dev, seguido de evaluación semántica opcional vía LLM. Detecta 68 patrones en 17 categorías: prompt injection, anti-refusal, exfiltración, escalada de privilegios, cadena de suministro, agencia excesiva, fuga de system prompt, memory poisoning, tool misuse, rogue agent, trigger abuse, behavioral AST, taint tracking, firmas YARA, MCP least privilege y MCP tool poisoning. Genera salida SARIF para integración con CI/CD.
Es el escáner más completo que existe para el análisis previo a la instalación de skills. Y no resuelve el problema.
Las limitaciones del SkillSpector
Según NVIDIA, el SkillSpector no escanea código binario ni cifrado. Según Trail of Bits, el .pyc burla esa clase de escáner. El pase semántico por LLM es vulnerable a la misma ingeniería social que intenta detectar: un escáner basado en LLM que evalúa código vía prompt injection es, por definición, susceptible a prompt injection.
El escáner más riguroso del mundo no protege contra lo que cambia después de la inspección.
El experimento de AIR, la bomba de tiempo de URL
Según el experimento de AIR, una skill falsa llamada Stitch SDK pasó por TODOS los escáneres de skills existentes, incluido el de NVIDIA. La técnica es simple: la skill apunta a una URL legítima durante el escaneo. Después de la distribución, la URL se cambia por contenido malicioso. AIR reporta que 26 mil agentes fueron alcanzados. Como AIR tiene interés comercial en ese resultado, trata ese número con cautela.
El ataque de bomba de tiempo (time-bomb URL) es la demostración más clara de la falla estructural: no importa qué tan bueno sea el escáner si lo que verificó puede cambiar después de la verificación. npm nunca resolvió ese problema. El ecosistema de IA tiene la misma falla con consecuencias mayores.
La falla estructural: verificar una vez, confiar para siempre
El problema no es la calidad de los escáneres. Es el modelo de confianza. Los escáneres verifican el paquete una vez. Las skills apuntan a URLs externas que cambian después de la verificación. El modelo de confianza necesita cambiar de verificar una vez y confiar para siempre a verificar continuamente mientras se ejecuta.
Esto significa monitoreo en runtime: interceptar las llamadas de red de la skill, monitorear los accesos al filesystem y a APIs sensibles, alertar sobre desvíos de comportamiento respecto al baseline establecido en el escaneo inicial. Significa re-verificación periódica: volver a escanear las skills en intervalos regulares, validar que las URLs referenciadas apunten al mismo contenido del escaneo original, revocar automáticamente las skills cuyo contenido cambió desde la última verificación.
En Tech86 implementamos seguridad verificable para despliegues de IA. No creemos en el escaneo único, creemos en la verificación continua. Si tu organización está adoptando skills de IA sin monitoreo en runtime, estás repitiendo los errores de npm en 2015 con consecuencias mayores. Podemos ayudarte a cambiar eso.
Continúa en el tema
Segurança de Agentes de IA: Prompt Injection, Worms e Supply Chain →