La trampa de la confianza en las skills de IA: cuando una habilidad aparentemente inocua se convierte en puerta de acceso a tus sistemas

Una empresa de seguridad, AIR, demostró una debilidad estructural en el ecosistema de “skills” para agentes de IA: creó una skill aparentemente inocua llamada brand-landingpage, la subió a un repositorio popular para heredar sus estrellas de GitHub, publicó un anuncio en Instagram y, según su informe, llegó a decenas de miles de agentes —incluyendo algunos registrados en cuentas corporativas— sin que ningún escáner la marcara como maliciosa.

El truco técnico que explotaron es sencillo y ancestral en la seguridad de software: el escáner revisa el paquete que se le entrega (los archivos que vienen con la skill), pero la skill puede apuntar a documentación o scripts externos que se descargan en tiempo de instalación. AIR dejó inicialmente un enlace a documentación legítima para pasar la revisión, y una vez que la skill se había difundido lo suficiente, cambió el contenido del enlace por instrucciones que pedían ejecutar un script. En su prueba el payload solo devolvía direcciones de correo para contar instalaciones, pero el vector podría haber servido para leer archivos, exfiltrar datos o moverse lateralmente dependiendo de los permisos del agente.

Esta no es una sorpresa aislada: otros equipos de investigación, como Trail of Bits, han mostrado cómo escáneres de skills pueden ser burlados por la misma técnica de separar el contenido analizado de lo que realmente descarga el agente en tiempo de ejecución. El problema no es un bug puntual, sino una falla de modelo de confianza: se asume que una skill verificada y con señales externas de legitimidad (estrellas, repositorio reconocido, escaneo limpio) seguirá siendo inofensiva, cuando en realidad puede cambiar el contenido que ejecuta después de la revisión.

Las implicaciones para empresas y responsables de seguridad son claras y profundas. Un agente que ejecuta una skill actúa muchas veces con el contexto y permisos del usuario o de un sistema automatizado; eso significa que una skill maliciosa o manipulada puede convertirse en una puerta a recursos internos. Las señales públicas de confianza no sustituyen controles técnicos continuos.

Para organizaciones que ya han desplegado agentes, la primera prioridad debe ser el inventario: identificar qué skills están instaladas en cuentas corporativas, comprobar qué dominios y URL externas consultan, y bloquear o poner en cuarentena aquellas que no hayan pasado por controles centralizados. La revisión puntual en el momento de la instalación no es suficiente; hay que monitorizar y volver a verificar cuando cambien recursos remotos.

En términos operativos, conviene tratar las skills como software de terceros, no como fragmentos de texto. Eso requiere medidas que van más allá del escaneo estático típico: pinchar versiones (apuntar a artefactos inmutables firmados o a commits concretos), exigir que todo código ejecutable vaya dentro del paquete verificado o en un almacenamiento inmutable (releases con hash), aplicar el principio de menor privilegio y limitar el egress de red desde los agentes mediante proxies o filtros DNS que eviten descargas desde dominios no aprobados.

Los marketplaces y proveedores de plataformas de agentes también deben asumir responsabilidad técnica: auditar no solo el paquete entregado sino los dominios y endpoints que la skill declara, exigir firmas y manifiestos reproducibles, ofrecer controles automáticos de re-escaneo cuando cambien recursos externos y exponer permisos detallados al usuario final antes de la instalación. Sin estos cambios, el ecosistema seguirá confiando en señales frágiles como estrellas de GitHub o un resultado puntual de escaneo.

No todo en el informe de AIR puede tomarse al pie de la letra sin comprobación independiente: la cifra de “26,000 agentes” y ciertos escenarios de control absoluto son reclamaciones de la propia empresa, que además anuncia un mercado gestionado en su comunicado. Aun así, el método que exhibieron y la debilidad estructural que expone se sostienen con base en pruebas previas y análisis de terceros.

Desde el punto de vista defensivo, recomendaciones concretas y realizables incluyen: auditar e inventariar skills instaladas, centralizar la aprobación de nuevas skills en una ventanilla única controlada, aplicar inspección y bloqueo de egress, exigir artefactos inmutables y firmados en los paquetes, re-evaluar automáticamente skills ante cambios en sus URLs externas, y reducir al mínimo los permisos que una skill pueda obtener. Estas medidas no eliminan el riesgo, pero cambian la dinámica de ataque, elevando el coste operativo para un atacante.

El incidente es también una llamada a la industria: los proveedores de agentes y marketplaces deben mejorar sus procesos de validación continua y ofrecer herramientas para que las organizaciones impongan políticas de seguridad. Mientras tanto, equipos de seguridad y responsables TI no deben confiar en métricas visibles públicamente como sustituto del control técnico. Para seguir aprendiendo sobre riesgos técnicos y auditorías de seguridad de software, recursos como el blog de Trail of Bits ofrecen análisis detallados https://blog.trailofbits.com, y proyectos de seguridad de la cadena de suministro como OWASP contienen guías aplicables a este contexto https://owasp.org.