La elusión del sandbox de Microsoft Copilot Cowork convirtió una Skill de confianza en un canal de exfiltración
Microsoft mitigó una vulnerabilidad de Copilot Cowork después de que investigadores demostraran que una sola Skill maliciosa podía eludir el sandbox del producto y exfiltrar datos de trabajo. Según se informa, la elusión del sandbox de Microsoft Copilot Cowork creó un canal de comandos entre el servidor de un atacante y el entorno aislado del agente.
PromptArmor afirma que ese canal podía acceder a datos disponibles a través de Outlook, SharePoint, Teams, plugins conectados y la sesión activa. El investigador reportó el problema el 24 de junio de 2026 y Microsoft confirmó la mitigación el 19 de agosto.
El hallazgo cuestiona una promesa central de los agentes para el entorno laboral. Un sandbox puede aislar código, pero el aislamiento sirve de poco cuando un servicio de confianza se convierte en una ruta no supervisada a través de su límite. Microsoft afirma que Cowork ahora evalúa las Skills y advierte a los usuarios que las carguen únicamente desde fuentes de confianza.
Según la cronología de divulgación, la falla reportada ya no es un zero-day abierto. Sin embargo, la lección de diseño va más allá de una implementación ya corregida. Los agentes empresariales combinan instrucciones no confiables, activos ejecutables, datos organizacionales y herramientas autenticadas dentro de un mismo flujo de trabajo.
Esa combinación hace que el límite de confianza sea más difícil de definir que en el software empresarial convencional. La pregunta central ya no es si un agente se ejecuta dentro de un sandbox. Los compradores deben preguntarse qué servicios atraviesan ese sandbox, qué aceptan esos servicios y qué actividad pueden observar los equipos de seguridad.
Cómo funcionó la cadena de exfiltración de archivos de Copilot Cowork
Según se informa, el exploit convirtió un servicio legítimo de transferencia de archivos en un canal de comandos bidireccional que las restricciones de red del sandbox no lograron detener.
Copilot Cowork es un sistema agéntico de Microsoft 365 que puede planificar y ejecutar tareas de varios pasos. Puede trabajar con documentos, buscar información organizacional, crear archivos, enviar mensajes y llamar a Skills especializadas.
Una Skill es un paquete de instrucciones reutilizable que guía al agente a través de un flujo de trabajo concreto. Microsoft admite Skills integradas, personalizadas, compartidas y basadas en plugins, según el entorno de Cowork y la configuración administrativa.
El ejemplo de PromptArmor comenzó con una tarea empresarial normal. Un usuario pidió a Cowork comparar un contrato con una propuesta mediante una Skill de consistencia documental descargada de una fuente externa.
La Skill generó la comparación solicitada, por lo que la tarea visible pareció completarse correctamente. Sin embargo, PromptArmor afirma que un script incluido también invocó un servicio de sincronización de archivos que operaba fuera del sandbox del agente.
Según se informa, Cowork utilizaba ese servicio para mover archivos entre almacenamiento externo y el entorno de trabajo aislado. El servicio aceptaba una URL que identificaba el archivo que necesitaba recuperar.
Según el análisis de la elusión del sandbox del investigador, el código malicioso podía proporcionar en su lugar una URL controlada por el atacante. Ese comportamiento permitía al script hacer que un servicio externo contactara infraestructura a la que el sandbox no podía llegar directamente.
El servidor del atacante devolvía un archivo que contenía un comando. El script malicioso leía ese archivo, ejecutaba el comando dentro de Cowork y codificaba el resultado en otra URL solicitada.
Esa segunda solicitud devolvía la salida del comando al servidor del atacante. Según se informa, repetir el proceso cada pocos segundos establecía un bucle de comando y control, lo que permitía a un atacante emitir nuevas instrucciones basándose en resultados anteriores.
Esto era más que una única solicitud saliente. Creaba una vía interactiva hacia un entorno conectado a servicios organizacionales.
PromptArmor afirma que su demostración utilizó el servidor Model Context Protocol de Cowork. MCP es una interfaz estándar mediante la cual una aplicación de IA puede llamar a herramientas conectadas y recuperar datos.
El investigador sostiene que el atacante podía utilizar comandos para consultar los servicios disponibles a través de esa conexión MCP. La demostración incluía enumerar mensajes de Outlook y recuperar el contenido de un hilo de correo electrónico.
Según se informa, la misma ruta de acceso exponía archivos de SharePoint, historial de sesión, datos de plugins y otra información disponible para el usuario activo. El alcance real dependería de los permisos de ese usuario y de los servicios conectados.
Un detalle hizo que el comportamiento reportado resultara especialmente preocupante. PromptArmor afirma que seleccionar el control de detención no terminaba los procesos que ya se ejecutaban en segundo plano.
El turno visible del agente podía terminar mientras el script malicioso seguía consultando el servidor del atacante. Por ello, un usuario podía creer que la tarea se había detenido mientras el canal encubierto permanecía activo.
PromptArmor reportó el problema a Microsoft el 24 de junio. Microsoft solicitó información adicional el 24 de julio, trató una corrección hasta principios de agosto y confirmó la mitigación el 19 de agosto.
La evidencia pública procede principalmente del informe técnico y la demostración de PromptArmor. Microsoft no ha publicado un aviso detallado que explique el cambio de código, las versiones afectadas o la telemetría disponible para una investigación retrospectiva.
Por qué importa la elusión del sandbox de Microsoft Copilot Cowork
La vulnerabilidad atacó el servicio que conecta el sandbox con datos útiles, en lugar de vencer el aislamiento mediante una fuga convencional.
Un sandbox tradicional intenta contener código no confiable restringiendo archivos, procesos, dispositivos y conexiones de red. Ese modelo solo funciona cuando cada ruta que cruza el límite aplica una validación igual de estricta.
Los agentes modernos complican esta disposición porque el trabajo útil requiere excepciones controladas. Un agente debe recibir documentos, devolver archivos generados, llamar a herramientas, acceder a sistemas empresariales y conservar suficiente estado para completar tareas largas.
Cada excepción se convierte en un intermediario entre el entorno aislado y algo de mayor confianza. El intermediario puede ser seguro cuando valida tanto los destinos como los flujos de datos. Se vuelve peligroso cuando código no confiable puede reutilizarlo para otros fines.
El informe de PromptArmor no describe un exploit clásico de corrupción de memoria ni una fuga del sistema operativo. Presuntamente, la Skill maliciosa de Copilot Cowork permaneció dentro del sandbox mientras abusaba de un servicio privilegiado situado fuera de él.
Esta distinción importa para las revisiones de seguridad empresariales. Un proveedor puede afirmar con veracidad que el código se ejecuta de forma aislada, mientras pasa por alto un intermediario que realiza solicitudes externas arbitrarias para ese código.
La tensión arquitectónica está en el centro del valor de Cowork. Microsoft presenta el producto como un agente que va más allá del chat y completa trabajo en Microsoft 365.
En el anuncio del producto Cowork de Microsoft, la compañía destacó flujos de trabajo de bandeja de entrada, investigación, generación de documentos, integraciones y Skills reutilizables. Esas capacidades requieren acceso a contexto empresarial valioso.
La documentación actual de Cowork indica que las tareas procesan archivos de usuario dentro de un entorno temporal y aislado, dentro del límite de servicio de Microsoft 365. También señala que el entorno se elimina al finalizar la tarea.
Ese modelo de seguridad limita la exposición directa, pero no elimina el riesgo de las herramientas conectadas. Un entorno aislado puede seguir convirtiéndose en un punto de lanzamiento cuando un intermediario de confianza acepta entradas controladas por atacantes.
Por eso la elusión del sandbox de Microsoft Copilot Cowork ejerce presión tanto sobre Microsoft como sobre los compradores empresariales. Microsoft debe demostrar que el límite reparado cubre todos los intermediarios, no solo la ruta de sincronización identificada por un investigador.
Los clientes también deben revisar sus supuestos sobre los permisos de usuario. Cowork opera con el acceso del usuario activo, por lo que una tarea explotada no necesita comprometer una cuenta independiente para acceder a datos permitidos.
El principio de mínimo privilegio sigue reduciendo el radio de impacto. No evita el uso indebido de acceso que el usuario posee legítimamente.
Un empleado que compara dos documentos podría tener permiso para leer correos sensibles, carpetas de acuerdos o discusiones internas. Esos permisos pueden quedar disponibles para un agente a través de sus conexiones aprobadas.
La entrada maliciosa también llegó como un componente de flujo de trabajo reutilizable, no como un ejecutable evidentemente hostil. Ese empaquetado reduce las sospechas del usuario porque las Skills están diseñadas para parecer extensiones de productividad.
Por tanto, el exploit une dos problemas de seguridad que las organizaciones suelen gestionar por separado. Uno es el riesgo de la cadena de suministro de software derivado de paquetes descargados. El otro es el riesgo de autorización de agentes que actúan como usuarios autenticados.
Los programas de seguridad deben abordarlos conjuntamente. Revisar el código sin mapear los datos accesibles omite el impacto, mientras que gobernar los permisos sin inspeccionar los activos de las Skills omite el punto de entrada.
Una Skill maliciosa de Copilot Cowork aún puede parecer útil
La Skill más peligrosa no es la que falla de forma visible, sino la que completa el trabajo asignado mientras realiza una segunda tarea oculta.
La demostración de PromptArmor utilizó un flujo de trabajo de comparación de documentos porque refleja una solicitud habitual de trabajo del conocimiento. Según se informa, la Skill generó un informe de consistencia completo mientras el script malicioso abría el canal encubierto.
Ese comportamiento dual debilita una señal de seguridad habitual. Los usuarios suelen tratar una salida correcta como prueba de que la herramienta funcionó según lo previsto.
Para un agente, la calidad de la salida y la integridad de la ejecución son cuestiones separadas. Un informe útil no revela cada script, llamada de servicio o solicitud de datos realizada durante su elaboración.
La actual guía de Skills personalizadas de Microsoft indica que Cowork evalúa las Skills automáticamente. Las comprobaciones documentadas varían según el alcance y el nivel de riesgo.
Las comprobaciones estáticas examinan la estructura, el código incluido y el texto en busca de patrones de inyección de prompts. Las comprobaciones de comportamiento evalúan salidas, acciones, uso de herramientas, conflictos y rendimiento con prompts realistas.
La documentación describe controles adicionales para implementaciones de mayor riesgo. Estos pueden incluir validación de activos, pruebas de confianza y seguridad, evaluación adversarial, pruebas de regresión y revisión humana.
Microsoft también ofrece a los usuarios una advertencia directa: carguen Skills únicamente desde fuentes en las que confíen. Ese consejo reconoce que la inspección automatizada no puede convertir código arbitrario de terceros en una dependencia segura.
El momento de esos controles documentados merece un tratamiento cuidadoso. La documentación en línea de Microsoft refleja el producto actual, no necesariamente la configuración exacta que PromptArmor probó antes del 19 de agosto.
Por lo tanto, no es seguro afirmar que todos los controles actuales fallaron durante la demostración. También es inseguro asumir que las comprobaciones enumeradas detectarían todas las variantes del ataque.
El escaneo estático tiene límites inherentes. El comportamiento malicioso puede dividirse entre archivos, ocultarse tras funciones normales, descargarse posteriormente o activarse solo bajo condiciones concretas.
Las pruebas de comportamiento también muestrean un conjunto limitado de ejecuciones. Una Skill puede actuar de forma segura durante la evaluación y activar lógica dañina después de una fecha, en un tenant objetivo o cuando aparezcan datos específicos.
Trabajos académicos recientes tratan las Skills de agentes como una superficie de cadena de suministro de software, en lugar de simples plantillas de prompts. La investigación SkillGate evaluó un escáner híbrido frente a un benchmark con 1.650 paquetes de Skills.
Sus autores informaron de una puntuación F1 de 0,817 y una tasa de falsos positivos del 1,13 %. Estos resultados respaldan el filtrado en tiempo de ejecución, pero también muestran que la detección sigue siendo probabilística.
La comparación no es una evaluación directa de Cowork, y el artículo se centra en las Skills de agentes de programación. Aun así, su modelo de amenazas se ajusta estrechamente al problema más amplio.
Un paquete reutilizable de instrucciones puede incluir scripts, documentación de apariencia fiable y comportamiento oculto. Instalarlo amplía la base efectiva de código e instrucciones del agente.
Las tiendas de aplicaciones tradicionales abordan riesgos similares mediante firma, revisión, reputación, retirada rápida y declaraciones de permisos. Las Skills de agentes requieren esas medidas, además de visibilidad sobre la ejecución dirigida por el modelo.
El modelo puede decidir cuándo y cómo invocar los archivos auxiliares. Esa flexibilidad hace que una Skill sea más adaptable, pero también dificulta generar un manifiesto completo de comportamiento.
Microsoft admite el uso compartido organizacional y los plugins de App Store junto con las Skills personalizadas. Los administradores pueden gestionar la disponibilidad y el despliegue de plugins, los conectores y los usuarios asignados.
Estos controles crean una vía de distribución más sólida que descargar un archivo desconocido. No eliminan la necesidad de inspeccionar los paquetes compartidos de forma privada o cargados personalmente.
Las empresas deberían tratar una Skill maliciosa de Copilot Cowork como una dependencia de aplicación no confiable. La procedencia, el versionado, la aprobación y la revocación importan tanto como las instrucciones en lenguaje natural que contiene.
La promesa del sandbox se encontró con la realidad de los agentes conectados
El conflicto principal se da entre la contención como promesa de seguridad y la conectividad como la función que hace valioso a un agente empresarial.
Microsoft afirma que Cowork puede enviar correos electrónicos, programar reuniones, crear documentos, publicar en Teams, buscar información de la organización y gestionar archivos. Estas acciones lo transforman de un chatbot en un sistema operativo.
Cada conector añadido incrementa el valor de una tarea realizada con éxito. También aumenta el impacto potencial cuando falla la integridad de la ejecución.
El exploit reportado no necesitaba que Cowork recibiera más permisos de los previstos. Presuntamente convirtió la capa de herramientas autenticada existente en una interfaz controlada por el atacante.
Esta es la inversión que los compradores empresariales deberían recordar. Un sandbox protegía el entorno de ejecución, pero un servicio de sincronización externo presuntamente dio al código una vía para sortear su política de red.
El mismo patrón puede aparecer en distintas plataformas de agentes. Los agentes aislados suelen depender de automatización de navegadores, almacenes de artefactos, puertas de enlace de herramientas, servidores MCP, intermediarios de credenciales y entornos de ejecución de conectores.
Los equipos de seguridad suelen revisar cada componente de forma independiente. Los atacantes buscan combinaciones.
Un servicio de archivos que parece de bajo riesgo puede convertirse en un proxy de red. Un endpoint de herramientas pensado para el agente puede convertirse en una API de acceso a datos para código malicioso.
Un trabajador en segundo plano diseñado para la fiabilidad puede mantener un ataque después de que se detenga la tarea visible. Ninguno de esos componentes tiene que parecer peligroso de forma aislada.
La comparación inmediata no es Microsoft frente a un rival concreto. La comparación más útil es entre la promesa de contención del sector y la realidad operativa de los agentes conectados.
Anthropic, OpenAI, Microsoft, Google y los proveedores de agentes de programación afrontan distintas versiones de esta tensión. Sus productos ganan utilidad al leer más contexto y realizar más acciones.
La vulnerabilidad reportada de Cowork es un ejemplo específico de una implementación. No debería generalizarse como prueba de que todos los despliegues de sandbox o MCP tienen la misma vulnerabilidad.
Sin embargo, sí muestra por qué una etiqueta de sandbox no puede servir como una evaluación de seguridad completa. Los compradores necesitan un modelo de flujo de datos que incluya todos los servicios con acceso a través del límite.
También necesitan claridad sobre la duración de los procesos. Microsoft documenta controles de pausa y cancelación para las tareas de Cowork, pero la prueba de PromptArmor presuntamente descubrió que un proceso en segundo plano sobrevivía a la acción visible de detención.
Microsoft puede haber cambiado este comportamiento como parte de la mitigación, o puede haber cerrado solo la vía de red. La divulgación pública no explica la reparación con ese nivel de detalle.
Esa brecha de verificación es importante. Las organizaciones no pueden determinar a partir de la cronología pública si Microsoft añadió validación de destinos, modificó la autorización de servicios, terminó trabajos en segundo plano, mejoró la detección o combinó varios controles.
La ausencia de un aviso detallado no significa que la mitigación haya fallado. Significa que los clientes deben buscar garantías mediante la orientación para tenants, los canales de soporte, los datos de auditoría y las pruebas controladas.
La arquitectura de seguridad debería asumir que un control preventivo acabará por no detectar un paquete hostil. Un diseño resiliente limita entonces lo que ese paquete puede alcanzar y hace visible el comportamiento anómalo.
Para los agentes conectados, esto implica restringir los destinos salientes, autenticar las solicitudes de intermediarios, vincular los servicios a tareas específicas y separar el acceso de lectura de los permisos de acción.
También implica revocar las credenciales cuando termina una tarea. Una sesión de agente cancelada debería finalizar los procesos relacionados e invalidar cualquier autorización temporal creada para esa ejecución.
Por último, la supervisión debe conectar la actividad de los agentes con la telemetría de seguridad convencional. Una invocación de Skill, una transferencia de archivos, una llamada MCP y una solicitud saliente inusual pueden parecer inofensivas en consolas separadas.
En conjunto, pueden describir una cadena de ataque.
La mitigación no cierra la brecha de verificación
Microsoft ha confirmado la mitigación, pero los clientes aún carecen de suficientes detalles públicos para reconstruir la exposición o validar todos los controles afectados.
PromptArmor afirma que Microsoft confirmó que el problema se mitigó el 19 de agosto, casi ocho semanas después de la divulgación inicial. Esa cronología indica una corrección coordinada, no un exploit público sin resolver.
El investigador no publicó pruebas de una explotación generalizada. La demostración prueba una vía técnica en condiciones de prueba, no el número de tenants afectados en la práctica.
En la divulgación no aparece ningún recuento público de incidentes, rango de versiones afectadas, identificador de vulnerabilidad ni indicador de compromiso. Los lectores no deberían interpretar la prueba de concepto como evidencia de una brecha extensa.
La conclusión inversa también sería prematura. Sin un aviso detallado de Microsoft, las organizaciones no pueden asumir que la ausencia de incidentes divulgados significa que no se produjo ningún uso malicioso.
La investigación retrospectiva depende de la telemetría. Los administradores necesitan saber si los registros de Cowork exponen las versiones de Skills cargadas, la ejecución de scripts, las solicitudes de intermediarios, las llamadas MCP y la duración de los procesos en segundo plano.
Microsoft afirma que la actividad de Cowork puede aparecer en los registros de auditoría unificados y que las políticas de Purview se aplican al servicio. La documentación administrativa actual también describe controles para plugins, modelos, uso del navegador y tareas automatizadas.
Estos controles son relevantes, pero una cobertura general de auditoría no equivale a cobertura de detección para este exploit. Un registro puede anotar una solicitud de servicio permitida sin identificar su destino como hostil.
Las organizaciones que probaron Cowork antes del 19 de agosto deberían preguntar a Microsoft qué eventos pueden identificar el comportamiento vulnerable. También deberían conservar los registros de auditoría pertinentes antes de que expiren las ventanas de retención.
La revisión más importante se refiere a la procedencia de las Skills. Los equipos deberían inventariar las Skills personalizadas, los archivos cargados, los scripts incluidos y los paquetes compartidos por la organización utilizados durante el período afectado.
Los paquetes desconocidos o no verificables merecen ser eliminados hasta que se revisen. Los equipos de seguridad deberían comparar hashes criptográficos cuando estén disponibles, porque un nombre de Skill conocido no establece la integridad del archivo.
A continuación, los administradores deberían relacionar cada Skill con los usuarios que la ejecutaron y los datos a los que esos usuarios podían acceder. Esto genera una estimación de exposición más precisa que analizar únicamente el texto de las Skills.
La telemetría de red saliente puede proporcionar otra señal. Las solicitudes a dominios desconocidos, los intervalos de sondeo repetidos o los datos codificados dentro de cadenas de consulta de URL merecen investigación.
Sin embargo, las solicitudes reportadas pasaban por un servicio fuera del sandbox. Por ello, la supervisión de endpoints en el dispositivo de un empleado podría no detectarlas.
Los registros del lado de la nube y la telemetría del proveedor se vuelven esenciales. Los clientes deberían preguntar si Microsoft puede exponer la tarea de origen, la Skill, el usuario, el tenant y el destino solicitado para las transferencias intermediadas.
Las organizaciones también necesitan una política para futuras cargas. Permitir que cualquier usuario importe una Skill desde la internet pública convierte la evaluación de confianza en una decisión individual.
Un modelo más seguro utiliza un registro interno con propiedad, estado de revisión, versiones aprobadas y fechas de caducidad. Las Skills de alto riesgo deberían recibir tanto revisión de código como pruebas en tiempo de ejecución.
Las Skills compartidas necesitan control de cambios después de su aprobación. Un paquete benigno puede volverse peligroso mediante una actualización, una cuenta de mantenedor comprometida o un archivo complementario sustituido.
Por lo tanto, la aprobación debería aplicarse a una versión específica, no a un nombre permanente. La revisión debería repetirse tras cada cambio sustancial.
Estas medidas no implican que Cowork sea excepcionalmente inseguro. Reflejan el nivel de gobernanza adecuado para cualquier agente que pueda acceder al correo, documentos, chats y aplicaciones empresariales.
Los trabajadores del conocimiento también deberían mantener el material de origen sensible dentro de repositorios con un alcance claramente definido. Una mejor gestión del conocimiento puede reducir la exposición innecesaria de datos cuando los equipos organizan el acceso en torno a necesidades reales de trabajo.
El objetivo no es eliminar el contexto útil de todos los agentes. Es evitar que un flujo de trabajo conveniente herede todo el alcance digital de un empleado sin una revisión deliberada.
Tres señales mostrarán si la seguridad de los agentes se está poniendo al día
La próxima prueba es si Microsoft convierte una mitigación en controles medibles y visibles para el tenant en cada vía que cruza el sandbox de Cowork.
La primera señal es una explicación detallada de Microsoft sobre la solución. Los clientes necesitan saber si Cowork ahora valida los destinos de sincronización, vincula las solicitudes al almacenamiento aprobado y termina los procesos cuando se detienen las tareas.
Un aviso técnico reforzaría la confianza porque los administradores podrían probar los límites pertinentes. El silencio no demostraría una exposición continua, pero mantendría la verificación dependiente de canales privados de soporte.
La segunda señal es una telemetría de tenant más completa. Los equipos de seguridad deberían estar atentos a nuevos eventos de Cowork que cubran hashes de Skills, ejecución de scripts incluidos, operaciones MCP, destinos de intermediarios y procesos en segundo plano vinculados a tareas.
Estos registros deben poder utilizarse mediante los sistemas de detección existentes. Un registro de actividad visible solo dentro de una sesión de Cowork no permitirá la búsqueda de amenazas a escala empresarial.
La tercera señal es una gobernanza de Skills más sólida. El sistema de evaluación documentado por Microsoft ya describe comprobaciones estáticas, de comportamiento, adversariales, de regresión y humanas en distintos niveles de riesgo.
La pregunta clave es con qué consistencia se aplican esos controles a las Skills importadas, personales, compartidas y distribuidas por tiendas. Los compradores deberían buscar paquetes firmados, aprobaciones de versiones fijas, listas de permitidos centralizadas y revocación rápida.
Microsoft también debería aclarar si los archivos complementarios de una Skill reciben el mismo escrutinio que su archivo principal de instrucciones. El escenario de PromptArmor dependía de código malicioso incluido, no solo de texto engañoso.
Estas señales fortalecerán o debilitarán el argumento más amplio a favor de los agentes autónomos para el lugar de trabajo. Una mejor verificación demostraría que los proveedores tratan las Skills como componentes ejecutables de la cadena de suministro.
Una visibilidad limitada dejaría a los clientes asumiendo una gran parte del riesgo. Se les pediría confiar en un sandbox reparado sin ver los límites que cambiaron.
Para las empresas que evalúan Cowork ahora, la respuesta práctica es un despliegue medido. Confirmen la mitigación, restrinjan quién puede cargar Skills, revisen los paquetes existentes, minimicen el acceso y supervisen los servicios conectados.
Se informa que el bypass del sandbox de Microsoft Copilot Cowork ya ha sido corregido, pero su advertencia arquitectónica persiste. Los agentes concentran instrucciones, código, credenciales y contexto organizacional en una única vía de ejecución.
Antes de ampliar el despliegue, plantee una pregunta concreta: ¿puede su equipo de seguridad reconstruir cada Skill, proceso, llamada a herramientas y solicitud externa detrás de una tarea completada? Si la respuesta no está clara, convierta esa visibilidad en un requisito antes de conceder un acceso más amplio.
