Las skills maliciosas de IA amplían el riesgo de seguridad empresarial

Google News ha puesto de relieve un marcado conflicto en torno a la IA empresarial: los agentes adquieren capacidades útiles mediante skills, mientras los atacantes explotan esas mismas extensiones. Investigaciones recientes identificaron más de 3.000 skills maliciosas entre casi 900.000 analizadas por el proveedor de seguridad ESET. Este hallazgo convierte una función práctica de los agentes en un problema de cadena de suministro de software.

La preocupación va más allá de un único marketplace o campaña de malware. Las skills de IA pueden combinar instrucciones, scripts, documentación externa y acceso a sistemas sensibles. Por lo tanto, una skill comprometida puede influir tanto en las decisiones de un agente como en las herramientas que controla.

Las empresas se enfrentan ahora a una disyuntiva entre autonomía y control. Los ecosistemas abiertos aceleran la experimentación, pero sus señales de confianza siguen siendo más débiles que las que rodean a los paquetes de software consolidados. Los investigadores ya han demostrado que la popularidad de un repositorio, la aprobación de un marketplace y el análisis estático pueden fallar simultáneamente.

Lo que Google News reveló sobre las skills maliciosas de IA

El cambio importante es la escala, no la primera aparición de una extensión maliciosa.

La investigación H1 2026 de ESET abarcó la actividad de amenazas observada entre diciembre de 2025 y mayo de 2026. La empresa indicó que analizó casi 900.000 skills de IA y encontró decenas de miles de ejemplos sospechosos. Más de 3.000 fueron clasificadas como maliciosas.

Una skill de IA es un paquete reutilizable que indica a un agente cómo completar una tarea, usar herramientas y gestionar información relacionada. Algunas skills contienen poco más que instrucciones. Otras conectan al agente con scripts, servicios, archivos, herramientas de línea de comandos o recursos web cambiantes.

La población analizada creció con fuerza durante el periodo de investigación. Según reportes basados en los hallazgos, ESET examinó unas 60.000 skills únicas en marzo y casi 900.000 en mayo. Los hallazgos sospechosos aumentaron de unos 10.000 a más de 25.000 durante ese intervalo.

Los hallazgos maliciosos pasaron de aproximadamente 600 a más de 3.000. Estas cifras no demuestran que cada repositorio tenga la misma tasa de infección. Sí muestran que los equipos de seguridad afrontan un volumen creciente de comportamiento de agentes de terceros que deben evaluar.

El resumen público del informe de amenazas de ESET describe las skills como pequeños componentes funcionales utilizados por los agentes. La empresa encontró instancias maliciosas y sospechosas en los repositorios que examinó.

Los investigadores observaron capacidades asociadas con ejecución de comandos, inyección de código, acceso a archivos, carga de credenciales, ofuscación y descargas externas. No son funciones automáticamente maliciosas. Se vuelven peligrosas cuando el propósito declarado de la skill no las justifica.

Una skill legítima para desarrolladores podría necesitar acceso al shell para crear una aplicación. Un asistente de documentos podría requerir permiso para leer archivos seleccionados. La cuestión de seguridad es si esos permisos siguen siendo limitados, visibles y vinculados a un propósito empresarial aprobado.

El malware tradicional suele llegar como ejecutable, archivo adjunto o paquete comprometido. Las skills maliciosas de IA añaden otro formato de distribución. Las instrucciones dañinas pueden aparecer dentro de lenguaje corriente que un agente interpreta como guía operativa.

Este diseño complica la detección. Al revisarla, una skill podría no contener un binario malicioso reconocible. En cambio, puede dirigir al agente hacia una página externa, obtener nuevas instrucciones más adelante o abusar de herramientas legítimas ya disponibles.

El artículo de Google News importa porque conecta estos hallazgos independientes en una historia de riesgo empresarial. La amenaza ya no se limita a agentes personales experimentales. Las skills están entrando en flujos de trabajo utilizados por ingenieros, especialistas en marketing, analistas, diseñadores y equipos de ventas.

Es posible que estos usuarios instalen extensiones sin considerar la acción como un despliegue de software. Un archivo de texto breve parece menos peligroso que un instalador de aplicaciones. Sin embargo, el agente que lee ese archivo quizá ya tenga acceso al correo electrónico, almacenamiento en la nube, código fuente o conocimiento interno.

La brecha entre apariencia y autoridad crea la tensión central. Las skills suelen parecer documentación, pero pueden funcionar como lógica ejecutable de flujos de trabajo. Las empresas no pueden gobernarlas de forma segura como si fueran prompts inocuos.

Por qué la seguridad de los agentes de IA ahora se parece a la defensa de la cadena de suministro

Una skill se convierte en una dependencia empresarial cuando un agente depende de ella para actuar dentro de los sistemas de la empresa.

La seguridad de la cadena de suministro de software rastrea el origen de los componentes, quién los mantiene, qué versiones se despliegan y cómo las actualizaciones llegan a producción. Las skills maliciosas de IA requieren muchos de los mismos controles. También introducen riesgos de comportamiento que el análisis convencional de paquetes no fue diseñado para interpretar.

Una skill puede coordinar varias herramientas de confianza sin explotar una vulnerabilidad de software. Podría indicar a un agente que localice una credencial, transforme un archivo y envíe el resultado a otro lugar. Cada llamada individual a una herramienta puede parecer legítima cuando se observa por separado.

El riesgo aumenta con la autoridad del agente. Un asistente limitado a redactar texto presenta una exposición menor que uno conectado a un shell, navegador, repositorio de código y cuenta en la nube. Los agentes empresariales se sitúan cada vez más cerca del segundo modelo.

Esto crea un efecto multiplicador. La skill proporciona instrucciones, mientras el agente aporta permisos, razonamiento y ejecución. Un atacante no necesita incorporar cada capacidad en la extensión maliciosa.

El marketplace ClawHub de OpenClaw se convirtió en un caso de estudio temprano. Los investigadores documentaron skills maliciosas dirigidas a credenciales y activos de criptomonedas. Algunas distribuían malware establecido, mientras otras manipulaban transacciones impulsadas por agentes.

Unit 42 de Palo Alto Networks examinó la actividad del marketplace entre febrero y mayo de 2026. Su análisis de la cadena de suministro identificó cinco skills maliciosas no bloqueadas después de que se introdujeran nuevas medidas de control.

Dos distribuían stealers de información para macOS conectados a infraestructura de mando y control. Otra utilizaba archivos inflados para eludir los umbrales de los escáneres. Otras skills perseguían la manipulación financiera mediante comportamientos específicos de agentes autónomos.

Unit 42 informó de las cinco skills a ClawHub. El marketplace las eliminó y bloqueó las cuentas asociadas. La respuesta redujo la exposición inmediata, pero no eliminó el problema subyacente de distribución.

Descubrimientos anteriores ya habían llevado a ClawHub a integrar VirusTotal y ClawScan. Estos servicios añadieron detección proactiva y análisis a nivel de código. OpenClaw también anunció su trabajo con Nvidia en análisis de skills y documentación.

La secuencia es reveladora. Un marketplace incorporó defensas después de que surgieran campañas maliciosas, pero los investigadores siguieron encontrando skills evasivas. Esto se parece a la larga competencia en torno a las extensiones de navegador, los registros de paquetes y las aplicaciones móviles.

Las skills de agentes añaden otra complicación porque su contenido efectivo puede extenderse más allá del artefacto descargado. Una skill local puede indicar al agente que lea documentación en línea. Esa página externa puede cambiar sin modificar la skill revisada.

Por lo tanto, los equipos de seguridad no pueden depender únicamente de un veredicto en el momento de la instalación. Un resultado seguro describe lo que un escáner observó en un momento concreto. No garantiza que cada dependencia permanezca sin cambios.

El inventario empresarial también se vuelve más difícil cuando los empleados pueden añadir skills directamente. Una empresa puede aprobar una plataforma de agentes sin saber qué extensiones de la comunidad instalan los usuarios después. Esto crea comportamiento de IA en la sombra dentro de un producto oficialmente autorizado.

La distinción importa para la respuesta a incidentes. Los investigadores necesitan saber qué skill se ejecutó, qué instrucciones cargó, qué herramientas llamó y a qué información accedió. Los registros ordinarios de aplicaciones pueden no capturar toda esa cadena.

Las organizaciones ya mantienen listas de materiales de software para sistemas seleccionados. Los despliegues de agentes necesitan un registro relacionado que cubra modelos, herramientas, skills, fuentes externas de instrucciones, permisos y versiones. Sin ese mapa, los equipos de respuesta no pueden determinar la exposición de forma fiable.

Un registro interno con capacidad de búsqueda también puede respaldar las investigaciones después de que se descubra una extensión riesgosa. Los equipos que organizan evidencia técnica local mediante una base de conocimiento de ingeniería pueden conservar decisiones de revisión, responsables y contexto de remediación.

Ese registro no sustituye la seguridad en tiempo de ejecución. Ayuda a establecer quién aprobó una dependencia y por qué. El requisito más amplio sigue siendo un control continuo sobre lo que los agentes pueden leer, invocar y transmitir.

La disyuntiva central es la autonomía del agente frente al control empresarial

Las skills hacen que los agentes sean más capaces al reducir la supervisión repetida, lo que también da a las instrucciones maliciosas margen para operar.

Un agente empresarial se vuelve útil cuando puede completar trabajo de varios pasos. Puede recopilar requisitos, inspeccionar archivos, consultar un servicio, generar un artefacto y entregar el resultado. Exigir aprobación después de cada acción menor eliminaría gran parte de ese valor.

Otorgar una autonomía amplia resuelve el problema de usabilidad, pero amplía el radio de impacto potencial. Una extensión comprometida puede reutilizar las mismas conexiones que hacen productivo al agente. El atacante hereda acceso indirectamente a través del flujo de trabajo autorizado del agente.

No se trata simplemente de una competencia entre plataformas abiertas y cerradas. Un catálogo seleccionado también puede distribuir un componente comprometido. Una skill privada también puede volverse peligrosa después de que cambie su repositorio, la cuenta de su mantenedor o una dependencia externa.

Los marketplaces abiertos aumentan la exposición porque publicar e instalar puede implicar poca fricción. También hacen posible la investigación, la eliminación y la revisión comunitaria. Restringir a cada agente a skills escritas internamente reduciría algunos riesgos, pero crearía nuevas cargas de mantenimiento.

La cuestión decisiva es si la autoridad sigue el principio de mínimo privilegio. Una skill de página de destino no debería necesitar acceso sin restricciones a claves SSH o credenciales en la nube. Una skill de resumen no debería ejecutar en silencio scripts de shell descargados.

El principio resulta familiar porque lo es. El mínimo privilegio ha guiado la seguridad de identidades y aplicaciones durante décadas. Los sistemas agénticos dificultan la aplicación de este principio porque un agente puede ensamblar varias acciones permitidas individualmente en una secuencia insegura.

Las skills también operan en una capa semántica. Sus instrucciones describen objetivos y procedimientos en lenguaje natural. Los controles de seguridad tradicionales destacan al identificar patrones de código conocidos, hashes de archivos e indicadores de red.

Son menos eficaces cuando el comportamiento peligroso se expresa como una guía operativa plausible. Una instrucción podría pedir al agente que obtenga un requisito previo, valide una cuenta o sincronice una configuración. La intención dañina solo surge del contexto.

La guía de OWASP sobre skills agénticas separa esta capa de comportamiento de la capa de conexión de herramientas. Las herramientas definen las acciones disponibles, mientras las skills organizan esas acciones en flujos de trabajo.

OWASP identifica las skills maliciosas, el compromiso de la cadena de suministro, los privilegios excesivos, las instrucciones externas no confiables, el aislamiento débil y la deriva de actualizaciones entre los principales riesgos. Esa lista muestra por qué un solo escáner o una sola política no pueden cubrir todo el problema.

Una arquitectura segura necesita varios límites. El marketplace debe establecer la procedencia. La plataforma de agentes debe aplicar permisos. Los controles de tiempo de ejecución deben observar las acciones, mientras la organización debe mantener el inventario y la propiedad.

La aprobación humana sigue siendo útil cuando se aplica a riesgos significativos. Enviar un borrador ordinario a una carpeta interna podría realizarse automáticamente. Cargar archivos confidenciales o modificar infraestructura de producción debería requerir una autorización más sólida.

El desafío consiste en evitar avisos sin sentido. Los usuarios aprueban rutinariamente solicitudes que no comprenden, especialmente cuando las interrupciones se vuelven frecuentes. Un cuadro de aprobación no puede compensar permisos predeterminados excesivos ni cambios invisibles en las dependencias.

Los compradores empresariales también deberían distinguir la utilidad de una skill de su fiabilidad. La popularidad demuestra adopción, no seguridad. Un elevado número de estrellas puede aportar prueba social sin decir nada sobre el comportamiento actual de las instrucciones externas.

La misma cautela se aplica a las insignias del marketplace. La aprobación podría confirmar que una propuesta superó una revisión. No establece que los recursos vinculados, la propiedad del repositorio o los paquetes posteriores seguirán siendo estables.

Esta disyuntiva moldeará la adopción empresarial. Los equipos de seguridad que bloqueen todas las extensiones impulsarán la experimentación hacia entornos no gestionados. Los equipos que permitan instalaciones sin restricciones crearán un grafo de dependencias en expansión que no podrán inspeccionar.

El punto medio viable es la autonomía gobernada. Los usuarios pueden acceder a capacidades aprobadas, mientras las acciones de alto riesgo siguen aisladas y observables. Las skills reciben permisos vinculados a su propósito, no todos los permisos disponibles para el agente anfitrión.

La autonomía gobernada también exige revocación. Cuando una skill deja de ser segura, los administradores necesitan localizar cada instalación, desactivarla, invalidar las credenciales expuestas y revisar la actividad relacionada. Retirar una simple entrada del marketplace es insuficiente.

Los escáneres estáticos están perdiendo la carrera por la confianza

La advertencia más contundente provino de una skill de investigación de apariencia inofensiva que, según se informó, llegó a más de 26.000 agentes tras superar los escáneres disponibles.

Los investigadores de AIR Security crearon una skill llamada brand-landingpage. Parecía ayudar a usuarios no técnicos a crear una página de destino con la herramienta de diseño Stitch de Google. La skill ofrecía funcionalidad real, lo que hacía creíble la propuesta.

Los investigadores la enviaron a una popular colección de código abierto que contenía 156 skills y alrededor de 36.000 estrellas en GitHub. La contribución fue aceptada tras varios días. AIR luego promocionó la skill mediante un anuncio de Instagram dirigido a especialistas en marketing, diseñadores y vendedores.

La skill empaquetada no contenía inicialmente una carga maliciosa evidente. En cambio, dirigía a los agentes a documentación de instalación en un dominio controlado por los investigadores. Ese dominio redirigía inicialmente a los visitantes hacia el servicio legítimo de Stitch.

AIR modificó posteriormente las instrucciones externas. La página revisada indicaba a los agentes que descargaran y ejecutaran un script. Para el experimento, la carga recopilaba direcciones de correo electrónico para que se pudiera notificar a los usuarios afectados.

Los investigadores afirmaron que ningún agente resultó perjudicado. También señalaron que la técnica podría haber llegado a conversaciones privadas y sistemas internos conectados. Esos impactos más amplios eran resultados posibles, no pérdidas documentadas del experimento.

El relato de AIR sobre la prueba controlada de la skill indica que los escáneres de Cisco, Nvidia y skills.sh marcaron la propuesta como segura. El resultado expuso un límite estructural de la revisión estática.

Un escáner puede inspeccionar los archivos actuales de una skill y aun así pasar por alto contenido futuro alojado en otro lugar. La documentación externa funciona como una dependencia mutable. Su propietario puede cambiar las instrucciones después de que el marketplace y los usuarios hayan establecido confianza.

Este método se asemeja a las actualizaciones maliciosas diferidas en ecosistemas de software consolidados. La diferencia reside en la entrega. El atacante puede modificar lenguaje ordinario que el agente interpreta más tarde como orientación procedimental autorizada.

El análisis estático sigue teniendo valor. Puede identificar código malicioso conocido, comandos ofuscados, URL sospechosas, permisos excesivos y dependencias de paquetes peligrosas. El error es tratar un escaneo limpio como una decisión de confianza duradera.

Las pruebas de comportamiento añaden otra capa. Un sandbox puede ejecutar la skill en un entorno de agentes restringido y observar intentos de acceso a archivos, descargas, comandos y comunicaciones de red. Ese enfoque puede revelar comportamientos ocultos tras texto plausible.

Sin embargo, el sandboxing también tiene límites. Un atacante puede retrasar la activación, reaccionar a señales del entorno o servir instrucciones inocuas a sistemas de análisis conocidos. Una prueba tampoco puede anticipar cada interacción entre una skill y las herramientas internas de una empresa.

Por ello, la supervisión continua importa después de la instalación. Los sistemas de seguridad deben detectar cuándo una skill contacta un dominio nuevo, solicita datos más amplios, cambia su patrón de ejecución o invoca herramientas fuera de su propósito previsto.

La fijación de contenido puede reducir la deriva de las instrucciones externas. Una empresa puede conservar la versión revisada de la documentación o exigir hashes criptográficos para los componentes descargados. El agente no debería confiar automáticamente en lo que sirva más tarde una URL mutable.

Los controles de red proporcionan otro punto de control. Las skills que no necesitan acceso a internet no deberían recibirlo. Otras pueden limitarse a dominios, métodos y destinos aprobados.

La visibilidad en tiempo de ejecución debe ir más allá del tráfico de red. Los defensores necesitan un rastro que conecte la solicitud del usuario, la skill seleccionada, las instrucciones recuperadas, las decisiones del modelo, las llamadas a herramientas y el movimiento de datos resultante. De lo contrario, cada acción pierde su contexto conductual.

El experimento de AIR no demuestra que todas las skills populares sean inseguras. Demuestra que las señales comunes de confianza pueden alinearse en torno a una conclusión falsa. La reputación, la aceptación en el marketplace y el escaneo respaldaron el mismo artefacto diseñado de forma maliciosa.

Ese es el ángulo escéptico que los líderes empresariales deberían conservar. Los proveedores de seguridad están introduciendo escáneres específicos para IA, pero ningún escáner puede ofrecer garantía permanente para flujos de trabajo mutables. Las afirmaciones sobre productos deberían evaluarse frente a pruebas de evasión en vivo y tasas de fallo transparentes.

La cobertura de Google News puede aumentar la conciencia, pero la conciencia no establece control técnico. Los compradores necesitan pruebas de que las plataformas de agentes pueden restringir acciones después de que una skill supere la revisión. La prevención y la contención deben operar juntas.

Quién está bajo presión por el riesgo en expansión

Las plataformas de agentes, los proveedores de seguridad y los compradores empresariales comparten ahora la responsabilidad por una dependencia que ninguno puede gobernar por sí solo.

Los operadores de marketplaces enfrentan la presión más inmediata. Deben equilibrar el rápido crecimiento de la comunidad con la verificación de editores, la revisión de artefactos, los controles de actualización y la respuesta a incidentes. Una mayor fricción en los envíos puede ralentizar el crecimiento, pero unos controles débiles dañan la confianza.

Los desarrolladores de plataformas de agentes controlan el entorno de ejecución. Deciden si las skills se ejecutan con permisos del anfitrión, dentro de contenedores o mediante herramientas restringidas. Su arquitectura determina hasta dónde puede llegar una instrucción maliciosa.

Los proveedores de seguridad enfrentan una prueba distinta. Deben identificar comportamientos dañinos expresados mediante código, lenguaje natural, sitios web mutables y herramientas administrativas legítimas. Las señales existentes de endpoints y redes siguen siendo valiosas, pero el contexto semántico se vuelve esencial.

Los equipos de seguridad empresarial no pueden externalizar todo el problema. Eligen qué plataformas entran en la organización y qué conexiones reciben esas plataformas. También determinan si los empleados pueden instalar skills de la comunidad sin revisión.

Los desarrolladores siguen siendo un grupo de alto riesgo porque los agentes de programación suelen tener acceso al shell y a repositorios. Una skill maliciosa podría dirigirse al código fuente, credenciales de paquetes, claves de firma, tokens de nube o configuración de despliegue.

Los usuarios no técnicos presentan una exposición diferente. Una skill de marketing o ventas puede acceder al correo electrónico, registros de clientes, activos de marca, notas de reuniones y sistemas de contenido. Su interfaz amigable puede ocultar la autoridad del agente subyacente.

Por lo tanto, los equipos de compras necesitan preguntas que vayan más allá de la precisión del modelo. Deberían preguntar cómo la plataforma descubre las skills instaladas, registra versiones, gestiona instrucciones externas y separa los entornos de usuarios.

También necesitan entender la revocación. ¿Pueden los administradores desactivar una skill en cada endpoint? ¿Pueden identificar qué credenciales estuvieron disponibles durante su período de instalación?

A los equipos de cumplimiento les importará la evidencia. Si un agente transmite información de clientes mediante una skill no aprobada, la organización debe reconstruir lo ocurrido. Una transcripción genérica de chatbot puede no explicar cada llamada posterior a herramientas.

Los equipos de respuesta a incidentes enfrentan exigencias similares. Necesitan registros inmutables y una cronología fiable. También necesitan saber si una skill eliminada creó persistencia en otro lugar, como un proceso programado o una configuración modificada.

Los hallazgos de Unit 42 ilustran este problema. Los investigadores observaron mecanismos de persistencia asociados con actividad maliciosa en marketplaces. Eliminar la entrada visible no neutralizó automáticamente todas las cargas desplegadas ni todos los canales de comandos.

Las empresas deberían tratar las credenciales de agentes como potencialmente expuestas tras una instalación maliciosa confirmada. Eso implica revocar los tokens pertinentes, revisar la actividad de autenticación, comprobar los archivos modificados y examinar las conexiones salientes.

El riesgo no se distribuye de forma uniforme en todos los despliegues. Un agente de investigación aislado con datos sintéticos genera consecuencias limitadas. Un agente autónomo conectado a sistemas de producción crea un problema de control mucho mayor.

Esta distinción debería guiar la política. Las organizaciones pueden clasificar agentes y skills según los datos accesibles, las herramientas disponibles, la autonomía, el alcance de red y el impacto empresarial. Las combinaciones de mayor riesgo reciben una revisión y supervisión más estrictas.

La presión también alcanza a los programas de gobernanza de IA. Muchos programas se centran en la selección de modelos, los términos de privacidad, la precisión de las salidas y el uso aceptable. Las skills maliciosas de IA introducen dependencias operativas que se parecen más a la seguridad de aplicaciones que a la gobernanza de modelos.

Los comités de gobernanza necesitan propiedad técnica, no solo principios escritos. Alguien debe aprobar las fuentes de skills, mantener el inventario, establecer límites de permisos y responder cuando cambie una dependencia de confianza.

El enfoque ganador no dependerá de un único departamento. La ingeniería de plataformas puede aplicar controles de despliegue. Seguridad puede supervisar el comportamiento, mientras los responsables de negocio definen las tareas aceptables y el acceso a datos.

Sin esa coordinación, las organizaciones crearán dos caminos insatisfactorios. Los agentes aprobados seguirán demasiado restringidos para ayudar, mientras los empleados instalan alternativas menos controladas. Ambos resultados debilitan la supervisión empresarial.

Tres señales mostrarán si las defensas se están poniendo al día

La siguiente fase se medirá mediante controles de marketplace, evidencia empresarial en tiempo de ejecución y pruebas independientes de detección.

La primera señal es si los principales registros de skills adoptan procedencia verificable y versionado inmutable. Un marketplace debería identificar al editor, conservar los artefactos revisados y exponer cada cambio. Las instrucciones externas también necesitan controles de inventario e integridad.

Si los registros implementan esas medidas de forma generalizada, los atacantes enfrentarán más fricción al reemplazar contenido de confianza. Eso reforzaría la idea de que los ecosistemas abiertos de skills pueden madurar sin abandonar las contribuciones de la comunidad.

Si los registros siguen confiando en la popularidad y el escaneo único, la evaluación actual del riesgo se vuelve más sólida. Deberían esperarse más cargas diferidas y tomas de control de dependencias a medida que las skills valiosas acumulen usuarios.

La segunda señal es si las plataformas de agentes empresariales ofrecen permisos aplicables a nivel de habilidad. Los administradores necesitan límites para archivos, herramientas, credenciales, comandos y destinos de red. Esos límites deben acompañar a la habilidad en cada despliegue.

Los rastros claros de ejecución son igualmente importantes. Un analista de seguridad debería poder relacionar una acción con la habilidad y las instrucciones externas que la provocaron. Los registros deben resistir la manipulación local y permitir búsquedas en toda la organización.

Si las plataformas ofrecen esos controles, será más fácil contener una habilidad maliciosa. Podría seguir entrando en el entorno, pero su capacidad para acceder a activos no relacionados se reduciría. Eso debilitaría los escenarios empresariales más graves.

Si las plataformas exponen cada habilidad a toda la autoridad del agente, el riesgo seguirá concentrado en el endpoint. Una extensión pasada por alto puede heredar acceso a muchos sistemas no relacionados.

La tercera señal es la realización de pruebas independientes frente a ataques mutables y diferidos. Las evaluaciones de escáneres deberían incluir cambios en instrucciones externas, redirecciones desde dominios de confianza, cargas útiles inactivas, toma de control de repositorios y herramientas legítimas utilizadas en secuencias inseguras.

El experimento con 26.000 agentes proporcionó una de esas pruebas. Las evaluaciones futuras necesitan métodos repetibles, muestras transparentes y divulgaciones que distingan el comportamiento sospechoso del malware confirmado.

Una detección consistente entre herramientas independientes sugeriría que el mercado está desarrollando bases de seguridad compartidas. Grandes discrepancias mostrarían que los proveedores aún definen el comportamiento malicioso de formas distintas.

Las organizaciones no deberían esperar estándares perfectos. Pueden empezar por inventariar las habilidades instaladas y asociar cada una con un responsable, origen, versión, permisos y dependencias externas.

Pueden aislar a los agentes con alta autoridad, limitar el acceso a la red y exigir aprobación para acciones sensibles. También pueden volver a analizar las habilidades cuando cambien las dependencias, no solo cuando los usuarios las instalen por primera vez.

Los equipos deben tratar las habilidades eliminadas o recién marcadas como desencadenantes de incidentes. La respuesta debe examinar credenciales, persistencia, acceso a datos y comunicaciones salientes. Eliminar la habilidad local es solo el primer paso.

La atención de Google News en torno a las habilidades maliciosas de IA debería conducir a una pregunta práctica: ¿puede su organización explicar qué está permitido hacer a cada agente empresarial? Si la respuesta es incompleta, empiece por los agentes conectados al código, los sistemas en la nube, los datos de clientes y las comunicaciones internas. Trace sus habilidades, restrinja la autoridad innecesaria y conserve las pruebas necesarias para investigar sus acciones. La seguridad de los agentes de IA no dependerá de encontrar un escáner perfecto. Dependerá de combinar una distribución fiable, permisos limitados, observación continua y una revocación rápida antes de que una extensión aparentemente útil se convierta en un incidente empresarial.