Resumen ejecutivo
Las skills convirtieron a los agentes de IA en algo extensible: cualquiera puede escribir un procedimiento y compartirlo. El problema es que una skill no es solo texto — trae código, y el código se ejecuta con los permisos de tu agente. Un estudio sobre más de 31.000 skills encontró que el 26,1% tiene al menos una vulnerabilidad y el 5,2% patrones de alta severidad. Y ya hay casos: en enero de 2026, la campaña «ClawHavoc» colocó 335 skills maliciosas en un marketplace, disfrazadas de herramientas populares, que robaban claves de API, billeteras, credenciales SSH y contraseñas — una sola acumuló unas 7.000 descargas antes de ser detectada. Andrea Arredondo presenta las cuatro categorías de amenaza, casos reales de cada una, y SkillSpector, la herramienta abierta de NVIDIA que audita una skill antes de instalarla y puede convertirse en un guardarraíl automático.
1. Qué es una skill, y por qué no es lo mismo que MCP o RAG
Una skill es un procedimiento repetible: el equivalente a escribir y detallar un flujo de trabajo con sus estándares. Vive en un archivo SKILL.md con tres partes: metadatos (cuándo usarla y en qué situaciones), procedimiento (los pasos y estándares a seguir) y scripts (las acciones concretas: abrir un archivo, generar un gráfico).
La analogía culinaria de la charla es la más clara que hay para distinguir las tres piezas que todo el mundo confunde:
| Pieza | La analogía | En concreto |
|---|---|---|
| Skills | La receta: cuánta harina, cuánto zapallo, a qué temperatura va el aceite. | Un SKILL.md con el procedimiento para generar un reporte. |
| MCP | Las manos: amasar, aplanar la masa, freír. | Un servidor que expone «leer base de datos» o «enviar un correo». |
| RAG | La despensa: que las sopaipillas llevan zapallo sí o sí. | Una base documental que el agente consulta antes de responder. |
Y ahí está el punto que da origen a toda la charla: las skills no solo agregan conocimiento — integran capacidades, instrucciones y código al sistema. La vulnerabilidad aparece en el código.
2. El problema de fondo, en cifras
skills analizadas (de 42.447 relevadas)
tiene al menos una vulnerabilidad
con patrones de alta severidad
Y la tendencia empeora: según el mismo estudio, existe 2,12 veces más probabilidad de encontrar vulnerabilidades en este contexto que en código convencional — una brecha que sigue creciendo a medida que el ecosistema se expande.
La cadena que va del problema al daño tiene cuatro eslabones y es dolorosamente corta: se instala una skill sin auditar → el agente la ejecuta con sus herramientas → expone claves de API, credenciales o documentos → daño reputacional o financiero.
Caso real · ClawHub, enero de 2026. La campaña «ClawHavoc» colocó 335 skills maliciosas en un marketplace, haciéndose pasar por herramientas populares. Bajo un falso «prerrequisito» de instalación, infectaban con el ladrón de credenciales Atomic Stealer: claves de API, billeteras de criptomonedas, llaves SSH y contraseñas. Un solo atacante acumuló cerca de 7.000 descargas antes de ser detectado.
3. Cuatro categorías de amenaza, cuatro casos reales
La charla organiza el riesgo en cuatro pilares, y cada uno viene con un incidente documentado que le da peso:
① Instrucciones maliciosas — inyección de prompts, evasión de negativas, ejecución innecesaria de herramientas, agentes rebeldes, envenenamiento de memoria. El caso: texto invisible incrustado en una demanda laboral instruía a la IA del tribunal a revisar el caso «superficialmente» y no impugnar las pruebas. Fue una de las primeras sanciones judiciales del mundo por inyección de prompts.
② Código peligroso — comandos construidos con datos no confiables, ejecución dinámica u ofuscada, inyección de comandos. El caso: paquetes publicados en npm con nombres tipográficamente similares a herramientas legítimas contenían un gusano que reescribía y ofuscaba su propio código para evadir detección, robaba llaves SSH, credenciales de nube y claves de API de servicios de IA, e incluía un kill switch para borrar el equipo.
③ Acceso y movimiento de información — lectura de variables de entorno, acceso a credenciales, exfiltración, permisos excesivos. El caso: EchoLeak, donde una instrucción oculta en un documento común hacía que el asistente corporativo filtrara datos de almacenamiento, intranet y chat sin que la víctima hiciera clic en nada, aprovechando los permisos amplios que el asistente ya tenía.
④ Cadena de suministro — dependencias vulnerables, descargas dinámicas, paquetes no confiables, diferencias entre lo declarado y lo real. El caso: paquetes troyanizados que robaban credenciales de las tres grandes nubes, se instalaban como hooks dentro de asistentes de programación, e incluían un mecanismo que borraba el equipo si detectabas el robo.
Sobre todo esto opera un factor humano que la charla nombra con precisión: los 30 segundos para decidir. Muchas instalaciones piden aceptar o rechazar de inmediato, y bajo esa presión es fácil instalar sin revisar. Como resume Arredondo, ahí es exactamente donde se compromete la información sensible — y el objetivo del taller es «darles la posibilidad de descargar las herramientas que necesitan, sin que alguien malintencionado se aproveche de su urgencia».
4. SkillSpector: auditar antes de instalar
SkillSpector es una herramienta de código abierto de NVIDIA, en actualización constante, que inspecciona una skill y produce un reporte con puntaje de 0 a 100, severidad y recomendación. La escala va de LOW · SAFE a CRITICAL · NO INSTALAR.
Acepta repositorios Git, URLs, archivos comprimidos, carpetas o archivos sueltos, y analiza contra 68 patrones en 17 categorías (inyección de prompts, exfiltración, agente rebelde, envenenamiento de memoria, seguimiento de datos contaminados y más). El análisis ocurre en cuatro pasos: patrones textuales → análisis AST (recorre el código como árbol de sintaxis, no como texto plano) → flujo de datos (sigue una credencial desde que se lee hasta dónde termina) → dependencias (qué se instala junto con la skill), consultando la base OSV.dev para verificar CVEs reales.
Y tiene dos modos que conviene entender bien porque resuelven cosas distintas:
- Modo estático (
--no-llm). Rápido y sin enviar tu contenido a un modelo externo. Ideal para diagnóstico inmediato de patrones conocidos. - Modo semántico (con LLM). Compara lo declarado en el
SKILL.mdcontra el comportamiento real del código. Detecta mentiras de intención que el análisis estático no puede ver.
La demostración muestra por qué esa distinción importa tanto:
| Caso | Puntaje | Veredicto |
|---|---|---|
| Skill legítima | 0/100 | LOW · segura |
| Skill maliciosa evidente | 93/100 | CRITICAL · no instalar |
| Skill que miente sobre su intención — solo estático | 23/100 | MEDIUM · precaución |
| La misma skill — con análisis semántico | 100/100 | CRITICAL · no instalar |
| Skill real con falsos positivos, tras aplicar baseline | 97 → 0/100 | LOW · segura |
Las dos últimas filas son las lecciones. La skill que declara una cosa y hace otra pasa casi desapercibida en modo estático (23/100, apenas «precaución») y se revela como crítica al comparar declaración contra comportamiento. Y en sentido inverso: una skill legítima puede dar 97/100 por falsos positivos, hasta que se establece una línea base que suprime los hallazgos ya revisados — de ahí en adelante, los reescaneos solo muestran lo nuevo.
5. De auditoría manual a guardarraíl automático
Todo lo anterior es out-of-band: alguien corre el escaneo a mano antes de instalar. El salto que propone la charla es exponer la misma herramienta por Model Context Protocol, de modo que otro agente la invoque automáticamente y bloquee la instalación según el veredicto — una respuesta booleana de «seguro de instalar: sí/no» integrada al flujo.
El ciclo completo en el día a día: (1) escribir o traer una skill —propia, de un repositorio o de un marketplace—; (2) escaneo automático en pre-commit, en integración continua o como guardarraíl antes de instalar; (3) veredicto con puntaje, severidad y recomendación; (4) un humano o un agente decide instalar o bloquear. Y un detalle que lo vuelve sostenible: si el código cambia, la huella cambia y el escaneo se repite. Es auditoría continua, no un evento único.
6. Honestidad sobre los límites
La charla dedica una lámina completa a lo que la herramienta no resuelve, y eso la hace más creíble. Entre sus fortalezas: es fácil de ejecutar, cubre riesgos propios del mundo agéntico, es abierta y extensible, se integra a flujos automáticos, no requiere enviar el contenido a un modelo externo y genera reportes tanto para personas como para pipelines. Entre sus limitaciones: hay falsos positivos y negativos; el modo semántico depende del modelo que lo respalde; la ofuscación puede evadirlo; el código que se descarga en tiempo de ejecución puede no estar visible al escanear; y —la más importante— el puntaje no es una garantía y no reemplaza el aislamiento en sandbox.
7. Conclusiones
Tres ideas para recordar, en los términos de la autora. Primero, las skills no solo dan conocimiento: integran código, y el código puede fallar o dañar. Segundo, un puntaje de 0 a 100 no es garantía: es una guía para decidir dónde mirar primero. Y tercero, la que resume el costo-beneficio de todo el asunto: auditar antes de instalar toma minutos; recuperarse de una filtración, no.
El cierre de Arredondo va más allá de la herramienta: «en esta era tan sorpresiva y transversal, la tecnología centrada en el humano es aquella que nos permite tomar decisiones informadas, conscientes y voluntarias». Contra los treinta segundos de presión para aceptar, el antídoto no es desconfiar de todo — es tener con qué mirar antes de decir que sí.
Referencias
- Arredondo Navarrete, A. (2026). ¿Qué trae esta receta? Auditando skills de IA con SkillSpector [presentación]. I Congreso IA-LATAM. PDF de la charla.
- Arredondo Navarrete, A. (2026). ¿Qué trae esta receta? Auditando Skills de IA con SkillInspector [video]. Canal de Comunidad IA LATAM en YouTube. youtube.com/watch?v=rIR1v6btExs.
- NVIDIA. SkillSpector [repositorio de código abierto]. github.com/NVIDIA/SkillSpector. Requiere Python ≥3.12, <3.15.
- OSV.dev — base de datos de vulnerabilidades open source consultada por la herramienta para verificar CVEs.
- Casos citados en la charla: campaña ClawHavoc en ClawHub (enero 2026) · EchoLeak · paquetes troyanizados en registros públicos de dependencias.
Sobre la autora
Andrea Arredondo Navarrete es CEO de Chimera, empresa chilena dedicada a la ciberseguridad de inteligencia artificial y robótica, y miembro del Laboratorio de Emprendimiento e Innovación (LEIND) de la Universidad de Santiago de Chile. Participa en retos de seguridad ofensiva, desarrolla soluciones basadas en IA y modelos de lenguaje, y se define como investigadora amateur — de las que publican sus hallazgos. LinkedIn · chimera.cl
Artículo elaborado por la Comunidad IA LATAM a partir de la presentación oficial y la transcripción del video de la charla. Los incidentes citados son públicos y ya divulgados. Este contenido se comparte con fines educativos y de seguridad defensiva.