Las agent skills ya son parte de la capa de ejecución (cada vez más usados usados y fundamentales en Spec-Driven Development aka SDD)... y lamentablemente la mayoría de los equipos las publican sin ningún review de seguridad. Este post recorre el primer review que me tocó realizar sobre 25 skills internas: voy a contarles como combiné el scanner SkillSpector de NVIDIA con un pase manual sobre el nuevo OWASP Agentic Skills Top 10, por qué unos 60 findings crudos terminaron en tan solo 5 reales, y porque los sobrevivientes eran riesgos silenciosos de supply chain y no exploits dramáticos. Es un reporte de campo sobre triage, basado en mi experiencia genuina, no una propaganda de herramienta!
Todo comenzó con un... "-Richie cómo va eso? Necesito pedirte un favor, podes hacer un review de seguridad de nuestras skills?..."
Lo leí y me quedé un rato mirando la pantalla. No porque fuera difícil o super complejo, sino porque no sabía por dónde encararlo... De momento en mi empresa no teníamos un playbook para hacer este tipo de revisiones. Hace aproximadamente siete meses, cuando Anthropic salió con esto allá por octubre 2025, una skill era una carpeta con un markdown adentro, algo que el modelo leía y no mucho más. Hoy esa misma carpeta decide qué corre el agente, qué archivos toca y con qué permisos, incluso hay jerarquías de Skills. Y para agregar algo más, hasta ese momento nadie en el equipo lo había mirado nunca con ojos de seguridad.
Así que hice lo obvio que cualquiera de nosotros haría en este tipo de situaciones novedosas, primero un research sobre el tema para entender si había un marco de testing en la industria, luego si había papers académicos sobre esto, y si existía algún tipo de framework. Descubrí que la semana pasada OWASP sacó el super nuevo top 10 de Skills 'OWASP Agentic Skills Top 10'. Y además descubrí herramientas en github para hacer análisis de skills, siendo lo mejor que encontré, SkillSpector de NVIDIA. Apunté la herramienta a nuestras 25 skills internas de este proyecto en particular, con sus scripts y sus permisos declarados, y le di enter. A los pocos minutos me devolvió unos 60 findings... SESENTA! Mi primera reacción fue de alarma total pensando en que se nos estaba prendiendo fuego la casa.
Sin más suspenso, la realidad es que no se estaba prendiendo fuego nada. Después de sentarme a validar uno por uno, de esos 60 quedaron alrededor de 5 reales. Todos de bajo impacto, todos sutiles, y todos (sin excepción), con la misma forma silenciosa: inofensivos hoy, potencialmente peligrosos el día que alguien envenene algo de lo que dependemos (el famoso supply chain o cadena de suministros).
Lo más valioso no fue encontrar una vulnerabilidad o misconfiguration en una skill X, sino que fue aprender a armar una metodología de testing de algo super nuevo en la industria y poco documentado sin entrar en pánico con el desconocimiento o incluso al obtener ese output alarmista de una herramienta nueva. Lo importante de tener la disciplina de buscar entre líneas lo que de verdad importa entre tanto ruido, entendiendo el contexto y el uso específico... bajando de sesenta a cinco.
Durante casi todo el fin de 2025 y principios de este año, la industria trató a las skills como configuraciones inofensivas. Esa suposición hoy por hoy no solo está muerta sino que además ya está validada por la industria a través del famoso proyecto abierto OWASP Top 10, dejando muy en claro que estamos muy lejos de ese escenario "inofensivo".
Los archivos de skill y de config a nivel repositorio ahora funcionan como parte de la capa de ejecución. Check Point Research divulgó dos vulnerabilidades en Claude Code, CVE-2025-59536 y CVE-2026-21852, mostrando que con solo clonar y abrir un proyecto no confiable se podía disparar ejecución de código y exfiltración de credenciales antes de que apareciera cualquier diálogo de consentimiento. Del lado de los registries, el propio análisis de OWASP describe al marketplace de skills ClawHub como el primer registry de agentes envenenado de forma sistemática a escala, con varias de las skills más descargadas confirmadas como malware en el pico de la infección.
Y las tasas base no dan tranquilidad. La investigación de NVIDIA detrás de SkillSpector reporta que el 26.1% de las skills contienen vulnerabilidades y el 5.2% muestra intención probablemente maliciosa. Si corrés skills de terceros, o incluso derivadas de la comunidad, sin ningún review, estadísticamente estás asumiendo un riesgo.
Ese es el telón de fondo de dos componentes que cayeron casi juntos y que terminaron dando forma a mi review: el OWASP Agentic Skills Top 10 y el scanner SkillSpector de NVIDIA.
Risk Signal
El cambio de modelo mental que tenemos por delante
Una skill no es documentación que el agente lee con buena educación e intención. Son instrucciones, más scripts, más permisos declarados, que el agente está sesgado a seguir y ejecutar. Revisala como revisarías un script que corre con los privilegios de tu desarrollador, porque eso es básicamente lo que es.
OWASP publicó el Agentic Skills Top 10, versión 0.5, en junio de 2026 (aún muy lejos de la v1.0). Cataloga los diez riesgos de seguridad más críticos para agent skills a través de plataformas (Claude, Cursor/Codex, VS Code, y ecosistemas tipo SKILL.md de OpenClaw). Es el primer lenguaje neutral entre vendors que tenemos para hablar de esto, que es justamente por lo que lo usé como el checklist manual detrás del escaneo automatizado.
Acá va la lista tal como la trabajé, con el significado en una línea de cada una:
AST01 - Skills Maliciosas. Skills deliberadamente dañinas, hechas para robar datos o correr comandos no autorizados.
AST02 - Compromiso de Supply Chain. Registries, distribución o canales de update envenenados.
AST03 - Skills Sobre-Privilegiadas. Permisos muy por encima de lo que la función necesita.
AST04 - Metadata Insegura. Parsing o deserialización peligrosa de archivos de config.
AST05 - Instrucciones Externas No Confiables. Skills que traen instrucciones mutables de fuentes externas sin pinning ni validación.
AST06 - Aislamiento Débil. Sandboxing insuficiente, que deja a una skill llegar a recursos del host o cruzar límites entre skills.
AST07 - Update Drift. Brechas explotables entre versiones, atacantes apuntando a lo no parchado.
AST08 - Scanning Pobre. Scanners que se pierden la inyección en lenguaje natural y las amenazas semánticas.
AST09 - Sin Gobernanza. Sin inventario, sin flujo de aprobación, sin log de auditoría.
AST10 - Reuso Cross-Platform. Portar una skill entre plataformas sin revalidar sus propiedades de seguridad.
La división de severidad de la versión 0.5 es dos Critical, cinco High, tres Medium. Lo que importó para mi review es que el Top 10 no es solo una lista de bugs. La mitad (AST02, AST07, AST08, AST09, AST10) es sobre proceso y supply chain, no sobre código. No podés escanear hasta aprobar esos. Esa sola observación y predijo exactamente dónde iban a caer mis findings reales.
NVIDIA/SkillSpector es un scanner de seguridad open source (Apache 2.0) que responde una pregunta antes de que instales una skill: ¿es seguro correr esto? Lo usé como el primer pase automatizado.
Detecta 68 patrones a través de 17 categorías, incluyendo prompt injection, anti-refusal, exfiltración de datos, escalada de privilegios, supply chain, agencia excesiva, fuga de system prompt, memory poisoning, mal uso de herramientas, persistencia de rogue agent, abuso de triggers, código peligroso vía Python AST, taint tracking, firmas YARA, y chequeos de least privilege y tool poisoning de MCP.
La arquitectura es de dos etapas, y entenderla es la clave para no ahogarte en findings:
Perspective
Cómo razona SkillSpector
Etapa 1 (estática): patrones regex, análisis de AST de Python, y lookups en vivo a OSV.dev para CVEs de dependencias. NVIDIA describe esta etapa con honestidad como "alto recall, precisión moderada". Traducción: sobre-reporta a propósito.
Etapa 2 (LLM, opcional pero no se puede hacer la inferencia de forma local aún): evaluación semántica que filtra falsos positivos y explica la intención, empujando la precisión a cerca del 87%. La podés desactivar con el flag --no-llm para correr solo estática.
Escanear es directo. Acepta directorios, archivos sueltos, URLs de Git, y archivos zip:
El scoring es aditivo: CRITICAL +50, HIGH +25, MEDIUM +10, LOW +5, con un multiplicador de 1.3x sobre scripts ejecutables. El puntaje 0-100 mapea a SAFE, CAUTION o DO NOT INSTALL. Útil como señal de triage. No útil como veredicto final, que es justo el punto de la sección que sigue.
LOW
Alerta de Seguridad
La etapa LLM opcional es la que te da precisión, pero transmite el contenido de la skill a OpenAI, Anthropic o NVIDIA según la configuración. Para código in house eso es una decisión de gobernanza de datos, no un default. La controlé a propósito y te recomiendo que si usas la inferencia vía API Key de alguno de estos providers, chequees primero que esas API keys estén bajo ZDR (Zero Data Retention policy o dentro de tu Enterprise Agreement con ese Vendor).
Mitigación
Para skills internas con scripts propietarios, corré solo estática con --no-llm primero, o apuntá la etapa LLM a un proveedor que tu política de datos ya permita. La etapa 2 envía contenido de archivos al proveedor del modelo configurado.
Acá va el proceso real que apliqué sobre las 25 skills internas. La disciplina estaba en el triage, no en el escaneo.
1
1. Inventario y alcance
Antes de escanear nada, armé un inventario: cada skill in house, sus scripts incluidos, y sus permisos declarados de forma super clara. AST09 (Sin Gobernanza) empieza acá. No podés revisar lo que no enumeraste. 25 skills, cada una con su definición SKILL, scripts auxiliares, y superficie de permisos.
2
2. Primer pase automatizado con SkillSpector
Corrí SkillSpector sobre las 25, generando SARIF para el registro. Etapa estática en todo; la etapa LLM la dejé controlada detrás de nuestra política de datos porque eran scripts propietarios. El output crudo fueron unos 60 findings. Ese número asustaba hasta que me acordé de que la etapa 1 está afinada para recall.
3
3. Validación manual contra OWASP AST10
Acá vivía el trabajo real. Recorrí cada finding contra el Top 10 a mano, haciendo tres preguntas por ítem: a qué riesgo AST mapea de verdad, es explotable en nuestro contexto específico, y cuál es el impacto realista. La mayoría de los findings falló la pregunta dos. Un patrón de trigger que parece "demasiado amplio" (AST05, abuso de triggers) solo es riesgo si la skill además trae instrucciones externas, y las nuestras no lo hacían.
4
4. Clasificar, descartar y confirmar
Los ~60 colapsaron rápido. La mayoría eran artefactos de precisión: llamadas de aspecto peligroso en scripts que corrían sobre input confiable y local; triggers amplios sin fetch externo; flags de "privilegio" sobre permisos que la skill genuinamente necesitaba. Después de validar, alrededor de 5 findings sobrevivieron como reales. Todos de bajo impacto. Todos sutiles.
5
5. Caracterizar a los sobrevivientes
Cada finding real compartía una forma: era inofensivo hoy, pero ampliaba nuestra exposición a un compromiso de supply chain (AST02). Helpers sin pin, un camino de update que confiaba en cualquier versión presente (AST07), un script que correría con gusto una dependencia envenenada si alguna vez aterrizaba. Nada era explotable por sí solo. Todo importaría el día que algo upstream cayera.
Best Practice
Por qué los sobrevivientes tenían todos forma de supply chain
Esto no fue casualidad. Los scanners estáticos son buenos con patrones a nivel de código dentro de una sola skill. Los riesgos que no pueden juzgar del todo son los de proceso, AST02, AST07, AST08, AST10, que dependen de contexto que el scanner nunca ve: cómo se actualiza la skill, en qué confía, y qué pasa cuando un upstream cambia. Así que los findings que sobrevivieron al review humano fueron justo los que la herramienta podía marcar pero no resolver. El scanner encontró el humo. El threat model decidió cuál humo era una chispa real, fuego futuro.
El ratio titular, 60 a 5, es la lección que le pasaría a cualquiera que corra su primer review de skills. Un scanner que reporta 60 issues no encontró 60 problemas. Te entregó 60 hipótesis y confió en que vos hicieras la ciencia. El valor que agregás no es correr la herramienta. Es el pase manual de OWASP que convierte el recall en verdad.
MEDIUM
Alerta de Seguridad
Un scanner de skills es un instrumento de alto recall y precisión moderada. Está construido para sobre-reportar y no perderse el 5% malicioso. Si el día uno reenviás esos 60 findings crudos a los ingenieros como "issues confirmados", vas a quemar tu credibilidad antes del segundo review.
Mitigación
Tratá cada finding del scanner como una hipótesis, no como un veredicto. Validá contra un threat model real, confirmá la explotabilidad en contexto, y nunca archives findings crudos como vulnerabilidades confirmadas.
Los fixes fueron poco glamorosos, lo cual es apropiado, porque los riesgos eran silenciosos.
Pin a todo. Cada dependencia auxiliar quedó pineada y con hash. Esto ataca directo AST02 y AST07: un atacante no puede arrastrarte a una versión envenenada que nunca aprobaste.
Least privilege sobre los permisos declarados. Recortamos la superficie de permisos en las skills que sobre-declaraban, cerrando la brecha de AST03 que el scanner había marcado bien incluso donde todavía no era explotable.
Mejorar los scripts, que funciones se usan y con que criterios fueron elegidas
El scanning y este análisis pasó a ser un gate, no algo de una sola vez. Lo ideal sería que SkillSpector corra en CI sobre cambios de skills, con un baseline commiteado para que los findings aceptados queden en silencio y los nuevos resalten. Eso convierte AST08 de un review único en un control continuo.
Un inventario real generaly un paso de aprobación. Lo que no existía antes del review, la gobernanza (AST09), es ahora el control más barato y de mayor palanca que tenemos: nada se publica como skill sin estar inventariado y aprobado por proyecto, por equipos, etc.
Solicitar una API Key bajo Agreement Enterprise con ZDR. Idealmente tener una API key de algun proveedor como OpenAI o Anthropic bajo reglas estrictras de ZDR sería el ideal para correr SkillSpector en CI, de forma periódica y de forma "inteligente" para que el análisis de grandes cantidades de Skills sea lo más escalable posible.
Nada de esto es exótico... ese es el punto. El primer review no descubrió un backdoor dramático. Descubrió que no teníamos proceso, y que nuestra exposición silenciosa tenía forma enteramente de supply chain. Arreglar el proceso valió más que arreglar cualquier finding individual.
Perspective
Si estás por correr tu primer review de skills
Empezá por el inventario, no por el scanner. Corré la herramienta para recall, después validá cada finding contra el OWASP Agentic Skills Top 10 a mano. Esperá que la mayoría se evapore, y esperá que los sobrevivientes sean riesgos de supply chain que la herramienta puede marcar pero no juzgar del todo. Presupuestá tu tiempo para triage, no para escanear.
El primer review de skills no se sintió como el trabajo de seguridad dramático que la gente suele imaginar cuando contamos de que trabajamos fuera del ámbito. Ninguna cadena de exploit, ningún backdoor con pistola humeante. Solo 25 skills internas, un scanner haciendo su trabajo honesto de sobre-reportar, y un humano decidiendo cuál de las 60 hipótesis sobrevivía al contacto con un threat model real. Cinco lo hicieron, y las cinco tenían la misma forma silenciosa: bien hoy, peligrosas el día que alguien envenene aquello de lo que dependemos.
Ese es el salto de madurez. Las herramientas por fin son lo bastante buenas para marcar riesgo de agent skills a escala, y el OWASP Agentic Skills Top 10 por fin nos da un lenguaje compartido para hablarlo. Pero el criterio, la parte que separa 60 findings de 5 reales, sigue siendo nuestro. Corramos el scanner. Después hagamos la ciencia... o magia.
Si llegaste hasta acá gracias por haber compartido este tiempo juntos, hoy en día la lectura, redacción y la atención son bienes preciados que los estamos perdiendo producto de las nuevas tecnologías, un bajo autocontrol y la velocidad incipiente que trajo la IA agéntica. Así que... devuelta gracias por estar acá compartiendo!
Pon a Prueba tu Conocimiento Tecnico
Fácil
En el primer review de skills descrito acá, el scanner devolvió unos 60 findings sobre 25 skills in house. ¿Cuántos sobrevivieron a la validación manual, y de qué carácter eran?
Medio
NVIDIA describe la etapa estática de SkillSpector como "alto recall, precisión moderada". ¿Por qué esa decisión de diseño hace esencial un pase manual de OWASP?
Difícil
La mitad del OWASP Agentic Skills Top 10 (AST02, AST07, AST08, AST09, AST10) es sobre proceso y supply chain en vez de código en una sola skill. ¿Por qué esa estructura predice que los sobrevivientes reales de un scanner estático van a agruparse en riesgo de supply chain?
