MalSkillBench: no sabemos medir los detectores de skills maliciosos porque los datos de prueba están sesgados

¿Qué es esto?

En junio de 2026, un equipo de investigación publicó MalSkillBench (arXiv:2606.07131), presentado como el primer benchmark con verificación en ejecución de skills de agente maliciosos. La aportación del artículo no es un ataque nuevo: es un resultado de medición que debería preocupar a cualquiera que confíe en un escáner de skills. Hoy no sabemos qué detectores funcionan realmente, porque los datos con los que se prueban son escasos, estrechos y nunca se contrastan con el comportamiento real.

Un skill es la unidad de extensión de los agentes de código como Claude Code, Gemini CLI, OpenCode y Cursor. Es un paquete markdown (un SKILL.md) que reúne instrucciones en lenguaje natural, scripts ejecutables y permisos de herramientas. Como un skill es a la vez código ejecutable e instrucción dirigida al agente, constituye una dependencia de cadena de suministro cuyo riesgo no es «ni puro código ni puro prompt». El ecosistema ha crecido rápido: el artículo cita mercados que alojan más de 1,6 millones de skills y un registro que lista más de 64.000, con envíos diarios que pasaron de menos de 50 a más de 500 en pocas semanas.

Cómo funciona

El problema central que documenta MalSkillBench es el sesgo de evaluación, y procede de tres carencias. Primera: no existe una verdad de base pública a escala; los informes del sector publican recuentos pero retienen las muestras, y el mayor conjunto de datos académico público previo suma solo 157 muestras. Segunda: los datos «de campo» disponibles cubren solo una franja estrecha de la superficie de ataque: de 703 skills maliciosos recopilados en condiciones reales, el 86,3 % son ataques de suplantación de dependencia (un skill declara un requisito de aspecto fiable que el agente acaba instalando), mientras que los ataques por inyección de prompt están casi ausentes. Tercera: no hay una metodología de evaluación compartida; cada detector se mide sobre su propio conjunto de datos privado y con sus propias métricas.

Para resolverlo, los autores construyen una tubería de bucle cerrado Generate-Verify-Feedback. Cada skill candidato es cargado por un agente de código real dentro de un sandbox Docker instrumentado con strace e inotifywait, más un juez LLM; solo se admiten las muestras cuyo comportamiento observado coincide con su indicador de verdad de base declarado. La verificación convierte una etiqueta declarada en evidencia de comportamiento. La cobertura se organiza mediante una taxonomía de tres dimensiones —vector de ataque × comportamiento malicioso × estrategia de inserción— que produce 108 celdas:

Dimension          Values (defines the 108-cell attack space)
-----------------  ------------------------------------------------------
Attack vector      CI  (Code Injection — payload in scripts/inline code)
                   PI  (Prompt Injection — adversarial markdown instructions)
                   MIXED (chain split across markdown + script)
Insertion (CI)     New Script File, Function Append, Function Inject,
                   Inline Code Block
Insertion (PI)     Full Camouflage, Partial Injection, Steganographic
                   (HTML comments, zero-width chars, homoglyphs)
Insertion (MIXED)  Download+Execute, Config+Load, Fetch+Run

Aquí no se reproduce ninguna carga útil, y ninguna hace falta para entender la idea: una misma rutina maliciosa (por ejemplo, un reverse shell) puede migrar del setup.py de un paquete Python al scripts/calculate.py de un skill cambiando solo el portador y el disparador. El caso MIXED es el más evasivo: el markdown prepara un artefacto y un script aparte lo consume, de modo que ninguna de las dos capas parece del todo maliciosa por separado.

Por qué importa

El hallazgo principal trata sobre la confianza en las herramientas, no sobre una CVE aislada. Cuando los autores evalúan 12 herramientas de detección en un banco unificado y justo, el recall de un mismo detector varía 66 puntos según el subconjunto de skills empleado para la medición, lo bastante como para mover un agregador antivirus comercial del fondo a la cabeza de la clasificación. Dicho de otro modo, un benchmark de proveedor ejecutado solo sobre datos «de campo» (mayoritariamente suplantación de dependencia) puede dar la ilusión de un detector excelente mientras permanece ciego a los skills por inyección de prompt y de vector mixto, que apenas aparecen en la naturaleza por ahora.

Esa brecha importa porque la superficie de ataque es genuinamente híbrida. Un skill puede llevar un cuerpo markdown de aspecto limpio cuya única función es hacer que un script posterior ejecute una acción dañina: exfiltración de datos, recolección de credenciales o persistencia. La inserción esteganográfica (comentarios HTML, caracteres de ancho cero, homóglifos) burla la revisión humana del SKILL.md, y la mitad ejecutable burla los escáneres que solo analizan el prompt. El artículo es investigación sobre un benchmark y una metodología de medición, no el relato de una brecha en condiciones reales, pero llega en un contexto de contaminación documentada de mercados de skills y de una cadena de suministro ya a escala de internet.

Defensas

MalSkillBench es en sí una aportación defensiva: medir mejor es un requisito previo para detectar mejor. Las medidas trasladables:

1. Trate los skills de terceros como dependencias de software no confiables, no como configuración. Un SKILL.md incorpora scripts ejecutables y permisos de herramientas. Aplíquele la misma revisión, fijación de versiones y controles de procedencia que a un paquete npm o a una extensión de IDE, y recuerde que un cuerpo markdown de aspecto limpio aún puede pilotar un script malicioso.
2. No crea las cifras de marketing de un detector; pregunte sobre qué se midió. Si un escáner anuncia un recall alto, pregunte si se probó tanto con vectores de inyección de código como de inyección de prompt, y con skills de vector mixto, y no solo con el patrón de suplantación de dependencia que domina los conjuntos «de campo». Un recall sobre una muestra sesgada dice poco de la cobertura real.
3. Ejecute los skills bajo monitorización en ejecución, no solo con análisis estático. La verdad de base del benchmark procede de la ejecución en sandbox con monitorización de llamadas al sistema. Los defensores pueden adoptar la idea: ejecute o prepare cada skill nuevo en un sandbox instrumentado y vigile los comportamientos (salida de red, lecturas de credenciales, persistencia) antes de concederle acceso a las herramientas de producción.
4. Apile controles para que ninguna verificación sea decisiva por sí sola. Los escáneres estáticos pierden el comportamiento en ejecución; los escáneres de prompt pierden las cargas ejecutables; la revisión humana pierde el texto esteganográfico. Combine permisos de herramientas de mínimo privilegio, filtrado de salidas y monitorización de comportamiento, de modo que un skill que pase una capa sea atrapado por otra.

Estado

Elemento	Referencia	Fecha	Notas
Artículo MalSkillBench	arXiv:2606.07131	2026-06	Primer benchmark con verificación en ejecución de skills de agente maliciosos
Escala del conjunto de datos	MalSkillBench	2026-06	3.944 skills maliciosos (703 reales + 3.214 generados + 27 curados) + 4.000 benignos
Taxonomía	MalSkillBench	2026-06	Vector de ataque × comportamiento × inserción = 108 celdas
Medición clave	MalSkillBench	2026-06	El recall de un mismo detector varía 66 puntos entre subconjuntos; 12 herramientas evaluadas
Sesgo de los datos reales	MalSkillBench	2026-06	El 86,3 % de las 703 muestras reales son suplantación de dependencia; PI casi ausente

La lección duradera es metodológica: en una cadena de suministro que cambia rápido, lo que un detector atrapa sobre las muestras reales de ayer dice muy poco de lo que atrapará mañana. Mida los detectores sobre toda la superficie de ataque —verificada por comportamiento, no por etiquetas— y trate los skills de agente con la misma desconfianza que ya aplica a cualquier dependencia de terceros.