La skill de confianza fue el ataque: Copilot Cowork y la cadena de suministro de agentes

La propuesta de los agentes de IA es que pueden usar herramientas en tu nombre. Un investigador que examinó Microsoft Copilot Cowork encontró una forma de volver esa propuesta contra el usuario, y el camino que siguió dice mucho sobre hacia dónde se dirige la seguridad de los agentes.

PromptArmor reveló el hallazgo el 30 de septiembre. La versión corta: una “skill” descargada que parecía un inofensivo verificador de documentos podía secuestrar la propia ruta de red de Cowork, abrir un canal de comandos hacia el servidor de un atacante y extraer datos de Outlook, SharePoint y Teams. Según el relato del investigador, Microsoft recibió el informe en junio y completó la remediación en agosto, por lo que los detalles técnicos se publicaron después de una corrección, no antes.

Cuatro pasos, y solo dos te involucran a ti

El ataque necesitaba que el usuario hiciera dos cosas comunes: subir un documento para revisar e invocar una skill.

En la demostración, la skill decía comparar un contrato con una propuesta y señalar inconsistencias. Lo hacía, que es lo que hace difícil detectar esta clase de ataque. El problema era un script incluido junto con la skill. Cowork se ejecuta dentro de un sandbox que se supone que no debería acceder a internet abierto, pero sí mantiene un puente para las solicitudes que necesita para generar respuestas. El script malicioso usó un servicio de sincronización de archivos accesible a través de ese puente y, de manera crucial, el servicio aceptaba una URL proporcionada por el solicitante.

Ese detalle es todo el exploit. Una vez que el script podía alcanzar una dirección controlada por el atacante, abría un bucle. Cada pocos segundos obtenía un archivo que contenía un comando, ejecutaba el comando dentro de Cowork y codificaba el resultado en un parámetro de URL enviado de vuelta al servidor. Eso es un canal de comandos bidireccional, no una baliza unidireccional, lo que significa que el atacante podía emitir nuevas instrucciones basándose en lo que devolvía el comando anterior.

En la demo, el investigador listó el correo de Outlook de la víctima y leyó el contenido de un hilo de correo. Según el informe, la misma ruta de acceso también exponía archivos de SharePoint, historial de sesiones y datos de plugins. Hasta dónde llega depende de lo que el usuario en cuestión ya puede ver, que es el amplificador habitual en estos casos: el agente hereda los permisos del usuario, así que el radio de impacto es todo lo que esa cuenta pueda tocar.

Un detalle más vale la pena repetir porque cambia la forma en que la gente piensa sobre detener un ataque. Seleccionar el control de detener no terminaba el proceso en segundo plano. El turno visible podía terminar mientras el script seguía sondeando. El usuario cree que la tarea terminó y el canal sigue abierto.

La skill es la dependencia

La parte interesante de esta revelación no es el bug específico, que ya está corregido. Es que la superficie de ataque no era una inyección de prompt en las instrucciones del modelo. Era la cadena de suministro alrededor del agente.

Las skills en un sistema como este son aplicaciones diminutas. Pueden incluir scripts, documentos de referencia y configuración, hasta veinte archivos complementarios en el caso de Cowork, y a menudo llegan desde fuera de la organización, descargadas de un marketplace o compartidas entre colegas. Esa es la misma estructura que produjo años de problemas en los ecosistemas de npm y PyPI, donde una dependencia que no escribiste puede ejecutar código que no leíste. Las skills de agentes son dependencias con un nombre más amigable. La descripción en la página de la skill afirmaba que todo el procesamiento ocurría localmente y que nada se enviaba a terceros. La propia inspección de la plataforma no detectó el verdadero comportamiento del script incluido.

Hay una segunda filtración, más silenciosa, que apunta a la misma debilidad. Un informe de Glow encontró que los agentes habían expuesto más de 13.000 imágenes y capturas de pantalla internas de más de 300 organizaciones a través de repositorios públicos de GitHub. Nadie se propuso publicar esos archivos. Terminaron en abierto porque un agente los escribió en algún lugar que no entendía que fuera público.

Los dos incidentes parecen diferentes y comparten una causa raíz. En uno, una skill maliciosa llegó hacia afuera a propósito. En el otro, un agente que se comporta correctamente escribió datos en algún lugar que no entendía que fuera público. Ambos son fallos del límite en torno a lo que un agente puede alcanzar y hasta dónde viaja su salida. El caso de Cowork muestra a un atacante explotando ese límite. El caso de GitHub muestra el límite fallando por sí solo, sin que nadie intentara romperlo, lo que podría decirse que es el resultado más común en el uso ordinario.

Cómo leer una revelación de seguridad como esta

La cronología es la parte que la mayoría de los lectores se salta, y vale la pena recorrerla porque te dice cómo sopesar el hallazgo. PromptArmor reportó el problema a Microsoft a finales de junio. Microsoft pidió más información en julio, discutió la remediación a principios de agosto y confirmó la corrección a mediados o finales de agosto. La investigación se hizo pública a finales de septiembre, después del parche, que es la secuencia estándar de divulgación responsable. Se desprenden dos lecciones.

Primero, una vulnerabilidad corregida no es lo mismo que una clase de vulnerabilidad corregida. La ruta de exploit específica está cerrada. El patrón que lo hizo posible, que una integración de confianza a la que el agente debe llegar sea utilizable como canal arbitrario, aparece dondequiera que un agente tenga una ruta de red permitida. La misma semana produjo otros ejemplos que apuntan a la misma debilidad, incluidos informes de que los agentes habían expuesto miles de imágenes internas a través de repositorios públicos. Bugs diferentes, misma forma.

Segundo, la corrección llega según el calendario de Microsoft, no el tuyo. Cualquiera que use estas herramientas en una empresa necesita saber en qué versión está y si la actualización realmente le llegó. Una nota de parche en un blog no es lo mismo que un despliegue parcheado.

La skill es la dependencia

El instinto después de una historia como esta es confiar más en el sandbox. El sandbox de Cowork hizo su trabajo contra el acceso directo a internet, y el exploit rodeó el límite usando una ruta que el sandbox tenía que dejar abierta. Ese es el patrón general: un agente sin herramienta de red directa todavía no es un sistema cerrado si puede crear contenido en una superficie que luego obtiene recursos externos, o controlar un servicio que lo haga.

Para los equipos que ejecutan agentes en un entorno empresarial, la respuesta práctica se parece menos a un parche de seguridad y más a la gobernanza ordinaria del software. Sepan qué skills están instaladas y de dónde vinieron. Muevan la instalación de skills al control de TI en lugar de dejarla en manos de usuarios individuales. Traten una skill con una ruta de red como tratarían cualquier nuevo ejecutable, con revisión antes de que se ejecute. Verifiquen si una actualización de seguridad realmente cubre la versión en uso.

Nada de eso es exótico. Es la disciplina que la seguridad de la cadena de suministro impuso a los equipos de software durante la última década, y que ahora llega una capa más arriba. La diferencia son las apuestas. Un paquete npm comprometido puede ejecutar código en la máquina de un desarrollador. Una skill comprometida se ejecuta dentro de un agente que ya tiene acceso a tu correo, tus archivos y tu historial de chat, y puede seguir ejecutándose después de que creas que le dijiste que se detenga.