Antes de instalar esa skill de IA: una revisión práctica de SkillSpector

Una skill de IA aparentemente útil es un lugar cómodo para esconder instrucciones. El mismo paquete puede explicar un proceso, incluir scripts y decirle al agente cuándo ejecutarlos. Instalarla incorpora algo más que documentación a tu entorno.

Ayer escribí sobre dar a cada agente permisos limitados a su tarea. Hoy la pregunta aparece antes: ¿qué debes revisar antes de que una skill nueva llegue al agente?

Probé SkillSpector de NVIDIA con dos entradas pequeñas y sintéticas. El resultado fue útil, pero conviene distinguir entre detectar texto sospechoso y demostrar que una skill es segura.

Qué revisé

El proyecto oficial es NVIDIA/SkillSpector, con licencia Apache 2.0. Utilicé el commit d7338f5, que declara la versión 2.12.0. Fijar la revisión permite reproducir la observación; no significa que esa revisión haya superado una auditoría independiente.

El proyecto combina análisis estático y comprobaciones opcionales asistidas por modelos, con informes procesables. La guía de instalación y análisis de NVIDIA describe el proceso previo a la instalación. Elegí --no-llm, instalé el escáner en un entorno aislado de Python 3.12 y analicé archivos locales. No configuré un proveedor de modelos ni probé el análisis semántico.

Evité una colección grande de skills reales de terceros. Dos ejemplos permiten inspeccionar una afirmación concreta: ¿distingue una instrucción normal para resumir de un intento evidente de anular controles y acceder a credenciales?

Dos entradas con el mismo propósito declarado

Ambas describen una skill llamada summarize-local-notes, presentada como un resumen de un documento suministrado sin modificar archivos.

La versión inocua solicita tres puntos factuales y prohíbe acceder a otros archivos o a la red. La sospechosa pide ignorar instrucciones anteriores, anular restricciones, actuar sin preguntar y subir una clave SSH a un destino example.invalid.

Eran cadenas de texto entregadas al escáner, no órdenes ejecutadas por un agente. No utilicé claves reales ni documentos de clientes. La prueba no demuestra una exfiltración real ni un compromiso.

Puedes consultar la entrada inocua y la entrada sospechosa. La segunda es material de prueba intencionadamente hostil; no la instales como una skill operativa.

Reproduce el análisis estático

Con uv y Git disponibles, esta secuencia instala la revisión examinada. Antes del último comando, copia el ejemplo en un directorio hermano llamado my-skill, con el nombre de archivo SKILL.md.

git clone https://github.com/NVIDIA/SkillSpector.git
cd SkillSpector
git checkout d7338f58200a9ae2a24810cee08911ab68b107a7
uv venv --python 3.12 .venv
uv pip install --python .venv/bin/python .
.venv/bin/skillspector scan ../my-skill/ --no-llm \
  --format json --output report.json --fail-on-findings

Utilicé esa invocación con cada directorio de prueba. La instalación partía del mismo checkout fijado, dentro de un entorno virtual temporal separado. Instalar descarga dependencias; --no-llm desactiva el análisis semántico, pero no garantiza que todas las funciones trabajen sin red. Revisa las comunicaciones antes de analizar material confidencial.

Guarda los informes fuera del directorio de la skill para que no se conviertan en otra entrada en el próximo análisis.

Los resultados observados

Entrada sintética	Hallazgos	Puntuación agregada	Severidad del informe	Código de salida
Resumidor inocuo	0	0	LOW	0
Anulación de instrucciones y acceso a credenciales	6	100	CRITICAL	1

Los seis hallazgos de la entrada sospechosa incluían cinco HIGH y uno MEDIUM. Sus identificadores fueron AR3, P1, P1, YR4, PE3 y EA2. Varias reglas coincidieron sobre el mismo ejemplo: seis hallazgos no equivalen a seis rutas de ataque independientes. La etiqueta agregada CRITICAL tampoco es la severidad individual de cada hallazgo.

En ambos casos, el informe declaró execution_successful: true y analysis_completeness.is_complete: true. Los analizadores semánticos figuraban desactivados. Esa integridad se refiere al análisis configurado; no demuestra que se utilizara un LLM ni que se cubriera todo comportamiento posible.

Los informes JSON inocuo y sospechoso están disponibles junto a las entradas. Son evidencias de esta prueba local del 27 de octubre de 2026, no un benchmark proporcionado por NVIDIA.

Qué demuestra la prueba y qué queda abierto

Demuestra que esta revisión reconoció señales evidentes en este texto concreto y que --fail-on-findings devolvió un código de error. Es evidencia útil para un control previo a la instalación.

No establece una tasa de detección. No probé ofuscación, ataques multilingües, contenido oculto en archivos comprimidos, cargas descargadas dinámicamente ni comportamientos condicionados al entorno del agente. Tampoco medí falsos positivos sobre una muestra representativa de skills legítimas.

La recomendación del ejemplo limpio fue SAFE. Operativamente la interpretaría como «no se encontraron problemas en este análisis configurado», sin convertirla en una garantía sobre una sesión futura. Un escáner no vuelve inmutable un paquete, limita sus credenciales ni determina si sus capacidades encajan con tu tarea de negocio.

Cómo lo incorporaría a un equipo

Trata cada actualización de una skill como una dependencia entrante. Registra origen y commit, analiza una copia inerte, revisa hallazgos e inspecciona los scripts antes de habilitarla. Conserva juntos los bytes aprobados y el informe: el análisis de ayer dice poco sobre el script modificado de hoy.

Para automatizar, distingue tres estados: aceptado tras revisión, rechazado por hallazgos y análisis incompleto o fallido. La ausencia de informe no es un resultado limpio. El comando probado bloquea por hallazgos; revisa los controles de integridad de esa versión antes de depender de él en un pipeline desatendido.

El revisor debe comparar propósito y capacidad. ¿Necesita red un formateador? ¿Necesita credenciales de producción un ayudante para notas de versión? Si una excepción está justificada, documenta hallazgo, responsable, motivo y caducidad. Evita supresiones generales que aprueben silenciosamente cambios futuros.

Por último, ejecuta la skill aprobada con los permisos limitados del artículo anterior. La inspección previa y los controles durante la ejecución cubren momentos diferentes. Necesitas ambos.

Mi valoración

Merece la pena evaluar SkillSpector como herramienta de revisión previa. Esta prueba pequeña produjo evidencia clara e inspeccionable y un código de salida aprovechable. Adoptaría ese proceso antes que cualquier titular sobre cuántas skills maliciosas puede detectar.

Empieza por una skill que tu equipo ya utilice. Fija su revisión, analízala, revisa sus scripts y pregunta si la próxima actualización recibirá la misma atención. Si quieres diseñar esa revisión sobre un flujo real de ingeniería, contacta conmigo.