Skills maliciosas en agentes de IA: qué esconden y cómo revisar una skill de Claude, Codex o Copilot antes de instalarla

Las skills se recomiendan en redes sociales como atajos para sacar más partido a Claude, Codex, Copilot o Cursor, y se instalan copiando una carpeta o pegando un comando. Una skill es un conjunto de instrucciones y, a veces, de scripts que el agente de IA sigue con los mismos permisos que su usuario. Una skill maliciosa es la que usa ese acceso para robar datos, instalar malware o desviar al agente de su función.

A principios de febrero de 2026, Koi Security revisó 2.857 skills de ClawHub, el mercado del agente de código abierto OpenClaw, y encontró 341 maliciosas, según The Hacker News. La firma Antiy elevó después la cifra a 1.184.

A pesar de tratarse de un tema relativamente nuevo la problemática es la de siempre con el software sin verificar, y Anthropic recomienda en su documentación sobre skills usarlas solo de fuentes de confianza y tratarlas como la instalación de un programa. La novedad está en que una parte del daño puede ir escrita en lenguaje natural, sin una sola línea de código sospechosa.

¿Qué es una skill y por qué puede ser peligrosa?

Una skill es una carpeta con un fichero SKILL.md que indica al agente cómo hacer una tarea, y puede incluir scripts, plantillas y otros recursos. Anthropic creó el formato y lo publicó como estándar abierto, que hoy mantiene el proyecto Agent Skills y que han adoptado herramientas como Codex de OpenAI, Gemini CLI, GitHub Copilot y Cursor. Una skill escrita para un agente suele funcionar en los demás, así que una skill maliciosa puede llegar a usuarios de todos ellos.

El agente carga al arrancar el nombre y la descripción de cada skill instalada. Cuando una tarea encaja con esa descripción, lee las instrucciones completas y, si lo indican, ejecuta los scripts que lleva la carpeta. En Claude Code, según Anthropic, las skills tienen acceso completo a la red, el mismo que el resto de programas del equipo, y sus órdenes pasan por los avisos de permiso salvo que se hayan aprobado antes. En claude.ai, la red depende de la configuración del usuario y del administrador, y en la API las skills se ejecutan en un contenedor sin red.

También puede llegar una skill sin instalarla. Claude Code carga las skills que un repositorio incluye en su carpeta .claude/skills al trabajar en él, y GitHub Copilot lee además las de .github/skills y .agents/skills, así que abrir con el agente un proyecto descargado de internet equivale a aceptar sus skills.

Ese diseño explica el riesgo. Quien escribe la skill decide qué hará el agente cuando la use, y el agente actúa con las credenciales, los ficheros y las conexiones de quien lo maneja. Anthropic advierte de que una skill maliciosa puede llevar al agente a usar herramientas o ejecutar código de formas que no corresponden a su propósito declarado, con riesgo de fuga de datos o de acceso no autorizado a los sistemas.

¿Hay casos documentados de skills maliciosas?

Hay varios, y el mejor documentado es el de ClawHub, aunque la investigación posterior muestra que el problema sigue abierto y que el mismo patrón aparece en otros componentes para agentes.

¿Cómo se infectó el mercado de OpenClaw?

Para publicar en ClawHub solo se exigía una cuenta de GitHub con al menos una semana de antigüedad, y eso facilitó una campaña masiva que Koi Security llamó ClawHavoc. De las 341 skills maliciosas que encontró Koi, 335 incluían un apartado de «requisitos previos» con instrucciones para instalar Atomic Stealer (AMOS), un programa que roba credenciales en macOS, mediante un comando para pegar en la terminal. En Windows, el señuelo era un archivo ZIP protegido con contraseña y alojado en GitHub que contenía un troyano capaz de registrar lo que se teclea.

Antiy contó al menos 1.184 skills maliciosas publicadas en ClawHub desde 12 cuentas, 677 de ellas desde una sola, según su análisis de ClawHavoc. Los nombres imitaban herramientas útiles, como bots de criptomonedas, utilidades para YouTube o integraciones con Google Workspace. El programa robaba contraseñas del navegador, claves SSH, sesiones de Telegram y monederos de criptomonedas, y otras muestras abrían una puerta trasera o enviaban fuera el fichero de credenciales de servicios de IA que usa el agente.

¿Cuántas skills con fallos encontró Snyk?

Snyk encontró fallos de seguridad en 1.467 de las 3.984 skills de ClawHub y skills.sh, el 36,8 %, que analizó en su estudio ToxicSkills, publicado el 5 de febrero de 2026, y confirmó 76 con cargas maliciosas. De esas 1.467 skills, 534 tenían algún fallo crítico. El 91 % de las maliciosas combinaba código dañino con instrucciones manipuladas para el modelo, y ocho seguían disponibles al publicarse el estudio.

Las 1.467 no son skills maliciosas, sino skills con algún fallo, fuera cual fuera su gravedad. Distinguir las dos cifras evita exagerar el problema, aunque una skill vulnerable también puede explotarse.

¿Siguen apareciendo skills maliciosas?

Siguen apareciendo, y algunas de las más recientes han esquivado los filtros del mercado. Unit 42, la unidad de investigación de Palo Alto Networks, publicó el 23 de junio de 2026 un análisis de cinco skills que no habían sido bloqueadas por las revisiones automáticas de ClawHub, que combinan VirusTotal con ClawScan, el escáner de la plataforma. Una de ellas engordaba su fichero README hasta unos 22 MB para superar los límites de tamaño que aplican muchos sistemas de análisis.

Dos de esas skills no robaban credenciales, sino que usaban al agente para ganar dinero. Una se presentaba como asesor financiero y recomendaba productos con enlaces de afiliado que su autor podía cambiar a distancia después de la instalación. La otra hacía que los agentes que la instalaban aportaran fondos a una cartera del operador, que compraba antes que nadie una criptomoneda especulativa a precio mínimo para venderla en la subida artificial que provocaba la actividad coordinada de los agentes.

¿Afecta solo a ClawHub?

Los incidentes masivos documentados se concentran en ClawHub, pero el mismo patrón se ha visto en otros componentes que amplían lo que puede hacer un agente. En septiembre de 2025 apareció en npm, el registro de paquetes de JavaScript, postmark-mcp, el primer servidor MCP malicioso conocido. Un servidor MCP (Model Context Protocol) es un conector que da al agente herramientas sobre otros sistemas, y este, según The Hacker News, añadía a partir de su versión 1.0.16 una dirección externa en copia oculta a cada correo que enviaba.

En Claude Code, Check Point describió en febrero de 2026 varios fallos ya corregidos, dos de ellos con CVE, por los que abrir un proyecto no fiable podía ejecutar órdenes o exponer la clave de la API. Otros casos de la misma familia han pasado por este blog. Entre ellos están Plugin4Shell, que eludía el commit fijado en los plugins de agentes, el gusano de npm que plantaba hooks en Claude Code y la extensión de Claude Code con puerta trasera distribuida en el mercado de Cursor.

¿Qué puede esconder una skill maliciosa?

Bajo una apariencia útil, una skill maliciosa puede esconder instrucciones para el agente, falsos pasos de instalación que descargan malware, scripts dañinos o un cambio de comportamiento que llega después.

Las instrucciones manipuladas son la parte nueva. El SKILL.md puede pedir al agente que lea un fichero de credenciales o que envíe datos a una dirección externa, y el agente lo hará si tiene permiso, porque para él es una instrucción más. Es una forma de inyección de instrucciones (prompt injection), el ataque que cuela órdenes en el texto que lee un modelo, y la Cloud Security Alliance lo llama envenenamiento del contexto del agente.

El investigador Johann Rehberger, de Embrace The Red, demostró además que esas instrucciones se pueden ocultar con caracteres Unicode invisibles, que no aparecen en pantalla y que varios modelos obedecían en su momento. Rehberger observó en febrero de 2026 que Claude Code los detectaba y rechazaba, sin tener claro si era una mitigación deliberada.

Los falsos requisitos previos son el truco de ClawHavoc. Una sección de instalación pide pegar un comando en la terminal o descargar un archivo comprimido con contraseña, la misma técnica de ingeniería social que el ClickFix de los CAPTCHA falsos. En este caso el engaño no se dirige al modelo, porque quien ejecuta el malware es la persona.

Los scripts de la carpeta pueden incluir código ofuscado que envía claves y tokens fuera del equipo o que abre una conexión remota, escondido dentro de una herramienta que funciona. Un antivirus puede detectar parte de ese código, pero no las instrucciones en texto que lo acompañan.

El cambio posterior es el más difícil de ver. Una skill puede ser inocua el día de la instalación y cambiar en una actualización, o descargar instrucciones y datos de una dirección externa que su autor modifica cuando quiere. Anthropic advierte de que incluso una skill de confianza puede verse comprometida si cambian sus dependencias externas, y el caso del asesor financiero de Unit 42 muestra un ejemplo de ello.

¿Por qué los escáneres no detectan todas las skills maliciosas?

Los escáneres no detectan todas las skills maliciosas porque muchos, sobre todo los basados en firmas, buscan código dañino conocido, y una skill puede hacer daño con texto que no es código. Una instrucción en lenguaje natural que pide enviar un fichero a una dirección externa no tiene firma de malware. La Cloud Security Alliance cita investigaciones en las que técnicas basadas solo en texto pasaron sin detectar por los escáneres evaluados.

Muchos sistemas de análisis tienen además límites de tamaño, como aprovechó el README de 22 MB que documentó Unit 42. Y el análisis se hace al publicar, de modo que no cubre lo que la skill descargue después. Por eso la revisión no puede delegarse por completo en el mercado ni en el proveedor del agente.

¿Cómo se revisa una skill antes de instalarla?

La revisión de una skill sigue la lógica del software de terceros y se resume en tres preguntas, que son quién la escribió, qué puede hacer sin preguntar y con quién puede comunicarse. Esas preguntas se repiten antes de instalarla, en la primera prueba y mientras siga instalada.

¿Qué hay que comprobar antes de instalarla?

Antes de instalarla hay que comprobar su origen, leer todos sus ficheros y descartar los requisitos previos dudosos.

1. El origen debe ser identificable. Una skill desarrollada en la empresa, publicada por el proveedor del agente o tomada de un catálogo interno aprobado inspira más confianza que un enlace compartido en redes. Quién la publica, desde cuándo y con qué historial son los primeros datos que deben comprobarse.
2. Todos los ficheros merecen lectura, empezando por el SKILL.md completo y no solo su descripción. Una instrucción que no encaja con el propósito declarado, como leer claves, tokens o ficheros de configuración, enviar datos fuera u ocultar algo al usuario, es motivo suficiente para descartarla.
3. La cabecera del SKILL.md también cuenta. En Claude Code, el campo allowed-tools aprueba herramientas de antemano, y los hooks (órdenes que se disparan solas ante ciertos eventos del agente) siguen activos el resto de la sesión. Algunas órdenes, además, se ejecutan al cargar la skill sin aviso de permiso, si las admiten las reglas del usuario o el campo allowed-tools de la skill.
4. Los requisitos previos que piden pegar comandos en la terminal, descargar archivos comprimidos con contraseña o instalar binarios de origen dudoso son una señal de alarma clara.
5. Los scripts deben revisarse en busca de conexiones de red, lecturas de rutas de credenciales y código ofuscado o codificado en Base64, una forma de disfrazar texto legible.
6. Un escáner de caracteres Unicode invisibles permite descartar instrucciones ocultas que no se ven al leer el fichero.

Hay herramientas de código abierto que automatizan parte de esta revisión. Skill Scanner, publicado por Cisco AI Defense, combina reglas de patrones, análisis del código Python y, de forma opcional, un modelo de lenguaje para buscar instrucciones manipuladas, fugas de datos y código malicioso. Agent Scan, de Snyk, localiza las skills y los servidores MCP instalados en una docena larga de agentes y los analiza, aunque requiere una cuenta de Snyk.

Agent Scan envía el contenido de lo que analiza a Snyk y puede arrancar los servidores MCP que encuentra, por lo que el proyecto recomienda usarlo en un contenedor o una máquina virtual cuando lo analizado no es de confianza. Cisco advierte de que un resultado sin hallazgos no certifica que una skill sea segura, y la lectura manual sigue siendo necesaria.

¿Dónde se hace la primera prueba?

La primera prueba se hace en un entorno aislado, sin credenciales válidas y con la red limitada, observando qué ficheros lee la skill y qué conexiones abre. Las skills que descargan instrucciones o datos de direcciones externas exigen más cautela en esta fase, porque su comportamiento puede cambiar sin actualizar la skill.

¿Y después de instalarla?

Después de instalarla, la skill necesita una versión fijada y una nueva revisión en cada actualización antes de llegar a los equipos, incluidos los cambios que haga el agente en sus skills. Las que se dejan de usar deben retirarse, porque cada una sigue presente en el contexto del agente y amplía lo que se puede manipular.

¿Dónde guarda las skills cada herramienta?

Cada herramienta guarda las skills en carpetas del usuario y del proyecto, y conocerlas es el punto de partida de todo inventario. Varias leen además las carpetas de las otras por compatibilidad, así que una misma skill puede quedar activa en más de un agente del mismo equipo.

Una búsqueda de ficheros SKILL.md en el directorio personal de cada usuario y en los repositorios de trabajo da una primera lista de lo que hay instalado. En Codex, la carpeta /etc/codex/skills afecta a todos los usuarios de la máquina, y cada skill puede desactivarse desde el fichero ~/.codex/config.toml sin borrarla.

¿Se ha instalado ya una skill sospechosa?

Si ya se ha instalado una skill sospechosa, lo primero es retirarla de todas las carpetas en las que esté y averiguar qué hizo mientras estuvo activa. El historial de sesiones del agente y la telemetría del EDR (la herramienta de detección y respuesta instalada en los equipos) muestran qué órdenes lanzó, qué ficheros leyó y con qué destinos se conectó.

• Si alguien siguió sus requisitos previos, pegó un comando o descargó un archivo que indicaba la skill, el equipo debe tratarse como infectado por un ladrón de credenciales y aislarse de la red.
• Las contraseñas guardadas en el navegador, las claves SSH, los tokens de API y de servicios en la nube y las sesiones abiertas se cambian desde otro dispositivo, y los monederos de criptomonedas se dan por expuestos.
• La revisión debe incluir tareas programadas, elementos de inicio y conexiones salientes a destinos desconocidos, porque el malware suele dejar mecanismos para volver a arrancar.
• Si la skill pudo acceder a datos personales de clientes o empleados, hay que valorar la notificación a la AEPD en el plazo de 72 horas que fija el RGPD.

Cuando hay indicios de robo de credenciales o de acceso a sistemas de la empresa, un servicio de respuesta a incidentes ayuda a fijar el alcance antes de dar el equipo por limpio.

¿Cómo debe gestionarlas una empresa?

Una empresa debe tratar las skills, los plugins y los servidores MCP como software de terceros, con inventario, aprobación previa, mínimo privilegio y vigilancia. El primer paso es saber qué hay instalado, porque muchas de estas piezas llegan como IA en la sombra, sin que el área de seguridad lo sepa. El OWASP Top 10 para aplicaciones agénticas, publicado en diciembre de 2025, recoge este riesgo como ASI04, vulnerabilidades de la cadena de suministro agéntica, y sirve de marco común para auditarlo.

Con el inventario hecho, un catálogo interno de skills revisadas y con versión fijada evita que cada empleado instale la última recomendación de las redes. Los agentes deberían trabajar con el mínimo privilegio imprescindible, en entornos aislados cuando ejecutan código y sin credenciales de producción a su alcance. Los registros de actividad de los ordenadores, a través del EDR o de una herramienta similar, deberían recoger las órdenes que lanzan los agentes, las lecturas de rutas de credenciales y las conexiones salientes a destinos que la skill no documenta.

Las herramientas ya incluyen controles para aplicar estas medidas. En Claude Code, la configuración gestionada por la empresa permite limitar los mercados de plugins a una lista aprobada (strictKnownMarketplaces) y bloquear las skills, los hooks, los agentes y los servidores MCP que no lleguen de un plugin o de la configuración gestionada (strictPluginOnlyCustomization). También permite impedir que las skills ejecuten órdenes al cargarse (disableSkillShellExecution) y desactivar la actualización automática de los plugins.

Anthropic permite además a las organizaciones de Claude Enterprise analizar el contenido de las skills que se suben a claude.ai y a Claude Cowork. Ese análisis no cubre las skills subidas por la API ni por la Consola, y la documentación no lo menciona para las que se instalan en local en Claude Code. Los controles de producción para estos componentes están detallados en nuestra guía de seguridad en MCP y agentes de IA empresariales.

En España, la AEPD publicó el 27 de octubre de 2026 un decálogo para delegar tareas en asistentes y agentes de IA. Entre otras pautas, recomienda instalar solo complementos y conectores de origen conocido, conceder los permisos imprescindibles sin autorizaciones permanentes y, en el trabajo, usar solo los asistentes autorizados por la organización. Una auditoría de seguridad de agentes de IA y MCP permite comprobar qué componentes hay instalados y qué podrían hacer con los permisos que tienen.

¿En qué se diferencia una skill maliciosa del software sin verificar?

Una skill maliciosa se diferencia del software sin verificar en que el código malicioso puede no existir, porque las instrucciones en texto son suficientes. Además, quien ejecuta la acción es un agente con los permisos del usuario. Verificar el origen, leer lo que se instala, conceder el mínimo de permisos y revisar cada actualización siguen siendo las defensas que funcionan.

Por eso tiene sentido aplicar ya a las skills la disciplina que se impuso con las extensiones del navegador, los paquetes de npm o las aplicaciones móviles.

Fuentes y atribución: este análisis se basa en información pública disponible a 2 de noviembre de 2026, principalmente la investigación de Koi Security (según The Hacker News), las de Antiy, Snyk, Unit 42, Embrace The Red y Check Point, las notas de la Cloud Security Alliance, la documentación de Anthropic, GitHub y el proyecto Agent Skills y el decálogo de la AEPD. Las cifras corresponden a cada estudio y a su fecha, y los mercados de skills cambian a diario.

Aviso: la lista de comprobación es orientativa y no asegura que una skill sea inofensiva. Las skills, los plugins y los servidores MCP deben evaluarse según los permisos y los datos a los que tenga acceso cada agente.