Ahora mismo hay desarrolladores descargando skills de terceros directo de GitHub para sus agentes de IA. Diez minutos ahorrados, una capacidad nueva, listo.

El problema es lo que se procesa poco: una skill de IA es código ejecutable que corre con los permisos de tu sistema, y no un prompt. La skill que tomaste para ahorrar tiempo puede leer tus variables de entorno, levantar tus llaves de API y mandarlas a un servidor externo mientras hace, además, lo que decía que iba a hacer.

Esa es la tesis, y va antes que la herramienta: instalar una skill sin revisarla es instalar una dependencia de código sin revisarla, con todo lo que eso implica. Para empresas que construimos sobre agentes, y más todavía cuando construimos para clientes, eso convirtió la revisión de skills en parte de la entrega, no en un detalle técnico. Es justo el tipo de riesgo que cubre Socio Tecnológico.

Los números que obligan a parar

Charly Wargnier resumió en LinkedIn el dato que vuelve esto urgente: una investigación encontró que el 26.1% de las skills públicas tiene vulnerabilidades y más del 5% son directamente maliciosas.

Detente en esas cifras. No es un caso de borde ni un titular alarmista. Una de cada cuatro skills que circulan en repositorios públicos carga una vulnerabilidad, y más de una de cada veinte fue construida para hacer daño. Si tu equipo instala skills de terceros con la misma ligereza con la que copia un fragmento de Stack Overflow, ya estás expuesto. La diferencia es que el fragmento de Stack Overflow no corre solo con acceso a tus secretos. La skill sí.

La razón por la que esto sorprende es un malentendido de categoría. La palabra skill suena a configuración, a un texto de instrucciones que le das al modelo. Pero una skill empaqueta código que se ejecuta. Tiene el mismo nivel de acceso que cualquier script que corras en tu máquina o en tu servidor: tus variables de entorno, tu sistema de archivos, tu red. Tratarla como si fuera un prompt es el error que la vuelve peligrosa.

Qué hace SkillSpector, sin sobrevenderlo

NVIDIA liberó SkillSpector con licencia Apache 2.0, y responde una sola pregunta: ¿esta skill es segura de instalar?

El funcionamiento es directo. Le apuntas a un enlace de GitHub, una carpeta local o un solo archivo SKILL.md. La primera pasada es un escaneo estático rápido que marca robo de credenciales, inyecciones de prompt y cruza datos de CVE en vivo. La segunda pasada, opcional, usa un modelo para evaluar la intención semántica del código y descartar falsos positivos. Al final entrega un puntaje de riesgo de 0 a 100 y un veredicto claro: seguro, precaución o no instalar. Escanea skills para Claude Code, Codex CLI y Gemini.

Es una herramienta que vale la pena correr antes de confiar en la próxima skill que encuentres. Pero acá es donde hay que ser honesto, porque la parte que se omite es la que importa.

Un escaneo al instalar no es confianza en ejecución

El contraargumento más afilado a esta clase de herramientas lo plantearon en los mismos hilos. Un escáner en el momento de instalar revisa un estado. Los agentes no operan en un estado fijo: traen y encadenan skills de forma dinámica en tiempo de ejecución. Una skill puede pasar el escaneo y después comportarse distinto según el contexto que reciba, o invocar otra que nunca revisaste.

Eso no anula a SkillSpector. Lo ubica. Es una capa de defensa al momento de instalar, no una garantía de comportamiento. La confianza tiene que ser continua, no una compuerta de una sola vez. Quien venda un escáner como solución completa está repitiendo el error que el escáner intenta corregir: tratar un problema de ejecución como si fuera un problema de revisión estática.

Hay quien lleva el argumento más lejos y dice que sin código abierto y reproducible de extremo a extremo, cualquier escáner es teatro de seguridad. No comparto el extremo, una capa imperfecta es mejor que ninguna, pero el núcleo es correcto: la revisión al instalar reduce riesgo, no lo elimina. La pregunta operativa apunta a “¿quién es dueño de la decisión de qué skills entran a producción y quién la vigila cuando ya están corriendo?”, más que a “¿corro el escáner o no?”.

Lo que esto significa si construyes para clientes

Acá está el ángulo que cambia el cálculo para una empresa de servicios. Cuando construyes agentes para un cliente, le pides acceso a sus CRMs, a sus APIs, a veces a su stack completo. Si una skill que tomaste de un repositorio público levanta esas llaves, el daño va más allá de un incidente técnico que se parchea. Es la confianza del cliente, y es tu reputación.

Esto conecta con algo que ya tratamos. En el post sobre las trampas que leen los agentes el riesgo venía del contenido que el agente consume sin que tú lo veas. En el post sobre el ataque a LiteLLM venía de la cadena de dependencias rota. Las skills son la misma familia de riesgo: superficie de ataque que entra por la puerta de “esto me ahorra tiempo”. La cadena de suministro de la IA no es solo los modelos y las librerías. Ahora incluye las skills que tu agente carga.

Socio Tecnológico trata esa superficie como parte del trabajo, no como un extra. Mantenemos el rol que define qué skills pueden entrar a un proyecto, las revisa antes de usarlas, y diseña el control de qué puede tocar cada agente cuando ya está en producción. Para un cliente que nos confía su operación, verificar una skill de terceros es parte de la diligencia de entrega, no algo opcional. Correr un escáner como SkillSpector antes de tocar cualquier cosa de terceros es la línea base, no el final del trabajo.

Antes de cerrar la semana, hazle una pregunta a tu equipo. La última skill o herramienta de agente que alguien instaló de un repositorio público, ¿quién la revisó, y sabe esa persona a qué tenía acceso mientras corría? Si la respuesta es que nadie la revisó porque venía recomendada, ya sabes dónde está tu próxima brecha. No la abrió un atacante sofisticado. La instaló alguien de tu equipo para ahorrar diez minutos.

Poner control sobre lo que tus agentes instalan y ejecutan