Problema
Mucha gente sigue tratando los skills de agentes como si fueran prompts empaquetados.
No lo son.
Un skill puede incluir instrucciones, scripts, referencias, assets, permisos, triggers y rutas de accion sobre herramientas o sistemas externos. Eso lo convierte en algo mas cercano a una dependencia ejecutable que a una nota reutilizable.
Si instalas skills sin pipeline de confianza, no estas ampliando capacidades. Estas ampliando superficie de ataque.
Tesis
SkillSpector importa porque convierte la instalacion de skills en un problema explicito de supply chain.
La idea fuerte no es solo “escanear antes de instalar”. La idea fuerte es que un skill deberia pasar por un release gate parecido al de cualquier artefacto serio:
- escaneo
- declaracion de owner y limites
- firma o verificacion de integridad
- politica de aceptacion
El skill deja de ser folklore de comunidad y se convierte en unidad gobernable.
Framework
NVIDIA plantea un pipeline de confianza con tres capas:
- Scan: SkillSpector revisa comportamiento riesgoso antes de instalar.
- Skill card: documenta owner, uso, riesgos y limites.
- Signature: verifica que el artefacto revisado es el que se distribuye.
Mini-caso: un equipo instala un skill que promete ayudar con research. El skill incluye helper scripts, pide acceso a red y toca MCP servers internos. Sin scan ni card, parece una mejora de productividad. Con pipeline, se ve si el comportamiento real coincide con la descripcion y si los permisos estan justificados.
Senal medible: porcentaje de skills instalados con scan, owner y verificacion de integridad antes de uso amplio.
Postura: el nuevo npm de los agentes no deberia entrar en producción sin control de release.
Por que importa ahora
La documentacion oficial de NVIDIA ya trata agent skills como una superficie propia de gobierno.
En SkillSpector, NVIDIA documenta 64 patrones de vulnerabilidad repartidos en 16 categorias, incluyendo:
- prompt injection
- data exfiltration
- privilege escalation
- excessive agency
- system prompt leakage
- memory poisoning
- MCP least privilege
- MCP tool poisoning
Y en su Trust Pipeline, NVIDIA propone un release gate claro: escanear, documentar con skill card, firmar y verificar antes de despliegue amplio.
La lectura BRTHLS es simple: la supply chain agentica ya existe. Lo irresponsable es actuar como si no.
Anti-ejemplo
“El skill esta en GitHub y la descripcion parece razonable.”
Eso no dice nada sobre:
- lo que ejecuta de verdad
- que permisos necesita
- si el codigo coincide con lo que promete
- si el artefacto instalado es el mismo que fue revisado
Confianza por simpatia no es governance.
Protocolo (3 pasos)
- Escanea antes de instalar. Skill directory completo, no solo
SKILL.md. - Exige metadata minima. Owner, uso previsto, riesgos, outputs y referencias.
- Verifica integridad. El artefacto revisado debe ser el que llega a los agentes.
| Capa | Pregunta | Riesgo si falta |
|---|---|---|
| scan | que comportamiento riesgoso aparece | instalacion ciega |
| skill card | quien responde y para que existe | capacidad sin owner |
| signature | es el mismo artefacto | sustitucion o drift |
Relacionado
- Tool Registry: el nuevo mapa de riesgos de los agentes enterprise
- MCP en empresa: el estandar que evita el caos de agentes
- A2A + MCP: los protocolos de agentes no son producto, son sistema nervioso
Fuentes consultadas
- Scan Agent Skills Before Installation
- A Trust Pipeline for Agent Skills
- NVIDIA-Verified Agent Skills Provide Capability Governance for AI Agents
- SkillSpector repository
Proximo paso
Haz una lista de los skills que tus agentes ya usan. Si no puedes decir que scan pasaron, quien los aprobó y como verificas el artefacto instalado, todavia no tienes ecosistema de skills. Tienes imports con fe.