Investigadores analizan 6 309 agent skills: la mitad tiene acceso a shell

Una skill para agentes parece un inofensivo archivo Markdown, pero el agente la lee como una instrucción y la ejecuta con los permisos de la sesión que la cargó. Los autores de un nuevo trabajo publicado en Hugging Face Daily Papers midieron cuánto poder cede el usuario al instalarla. Analizaron 6 309 listados de dos marketplaces, ClawHub y skillsmp. La mitad muestra indicios de poder ejecutar comandos en shell, y siete de cada diez incluyen al menos una capacidad elevada. Al instalar, casi nada de esto es visible.

La metodología tiene dos fases. Primero, un análisis estático de todo el bundle, y no solo del SKILL.md, junto con una verificación del origen de las dependencias. Después, la skill se ejecuta en un sandbox instrumentado y un modelo evalúa por separado las trazas obtenidas. Un detalle importante de la muestra: los listados que se ejecutaron se seleccionaron sin basarse en ninguna señal previa de amenaza o riesgo. Por eso el panorama describe el mercado en su conjunto y no solo las piezas sospechosas, que son las que suelen aparecer en los informes.

Qué mostró la medición

Los autores subrayan que instalar una skill no concede privilegios nuevos: otorga el derecho a dirigir al agente. Lo que calculan es el tamaño de ese derecho. Estas son las proporciones de capacidades en todo el corpus:

• ejecución en shell: 50% de los listados;
• lectura del sistema de archivos: 35%;
• escritura en el sistema de archivos: 31%;
• salida a la red (network egress): 31%;
• acceso a credenciales: 13%;
• al menos una capacidad elevada: alrededor del 70%.

Conviene subrayar que el trabajo no se limita a buscar skills maliciosas. La mayoría de estas capacidades pueden ser perfectamente legítimas: una skill de despliegue no funciona sin shell. Pero el usuario acepta toda esa superficie de ataque con un solo clic, sin conocer sus límites.

Declaraciones frente a realidad

Formalmente, el mecanismo de permisos existe. El autor de una skill puede enumerar en su propio frontmatter las herramientas aprobadas de antemano. Sin embargo, esa opción elimina las solicitudes de confirmación y no restringe nada. La skill conserva acceso a todo lo que alcance.

Según las cifras, el mecanismo casi no se usa. Se pudo analizar el frontmatter de 6 061 listados, y solo 770 de ellos declaran algo. El vocabulario no permite expresar el acceso a credenciales ni a variables de entorno. Nadie comprueba que lo declarado coincida con el contenido del bundle.

Incluso cuando el autor declara, a menudo se equivoca o calla: el 59% de los listados que declaran subestima las capacidades reales. Las plataformas difieren de forma notable. ClawHub declara aproximadamente el doble de veces que skillsmp, pero subestima en el 88% de sus declaraciones frente al 31% de su competidor. Es decir, rellenar los campos con más disposición no implica más honestidad.

Cómo plantear la verificación en la práctica

La principal conclusión de los autores para los marketplaces es que el triaje no debe basarse en lo declarado, sino solo en lo que el bundle es capaz de hacer. Un detector de malicia responde a la pregunta «¿es malintencionado el autor?». Un perfil de capacidades responde a otra: «¿qué pasará si la skill resulta comprometida, comete un error o es engañada mediante prompt injection?». Ambas comprobaciones se complementan.

Los equipos que conectan skills de terceros a sus agentes pueden hacer varias cosas desde ya:

• escanear todo el bundle, incluidos scripts y dependencias, en lugar de leer solo la descripción;
• separar en una lista aparte las skills con shell, escritura en el sistema de archivos, salida a la red y acceso a credentials, y aprobarlas manualmente;
• no tratar las pre-approved tools del frontmatter como una medida de seguridad: es una forma de eliminar confirmaciones;
• ejecutar las skills desconocidas en un sandbox sin secretos y con tráfico saliente limitado;
• no dar a la sesión del agente más permisos de los que necesita la más sensible de las skills cargadas.

Para las plataformas, la conclusión es todavía más directa: hace falta un perfil de capacidades calculado automáticamente y mostrado al usuario antes de la instalación, además de una verificación de que las declaraciones coinciden con el bundle. Mientras eso no exista, ese 70% de capacidades elevadas seguirá siendo una condición invisible del trato.