Durante cuatro semanas a partir del 21 de enero, Microsoft Copilot leyó y resumió correos electrónicos confidenciales, a pesar de que todas las etiquetas de confidencialidad y las políticas de DLP decían no hacerlo. Los puntos de cumplimiento rompieron el propio proceso de Microsoft y ninguna herramienta de seguridad en la pila los marcó. Entre las organizaciones afectadas se encontraba el Servicio Nacional de Salud del Reino Unido, que se registró como INC46740412 – una señal de hasta qué punto el fracaso ha llegado a los entornos sanitarios regulados. Microsoft lo rastreó como CW1226324.
La consultoría, informado por primera vez por BleepingComputer El 18 de febrero marca la segunda vez en ocho meses que el proceso de recuperación de Copilot ha superado su propio umbral de confianza: una falla en la que un sistema de inteligencia artificial accede o transmite datos que tenía explícitamente prohibido tocar. El primero fue peor.
En junio de 2025, Microsoft solucionó CVE-2025-32711una vulnerabilidad crítica sin clic que los investigadores de Aim Security han denominado “EchoLeak”. Un correo electrónico malicioso pasó por alto el clasificador de inyección inmediata de Copilot, su redacción de enlaces, su política de seguridad de contenido y sus menciones de referencia para exfiltrar silenciosamente datos corporativos. No se requirieron clics ni acciones del usuario. Microsoft le ha asignado un Puntuación CVSS de 9,3.
Dos causas fundamentales diferentes; un punto ciego: un error de código y una sofisticada cadena de exploits produjeron un resultado idéntico. Copilot procesó datos que estaba explícitamente prohibido tocar y la pila de seguridad no vio nada.
Por qué EDR y WAF siguen siendo arquitectónicamente ciegos a esto
La detección y respuesta de endpoints (EDR) monitorea el comportamiento de archivos y procesos. Los firewalls de aplicaciones web (WAF) inspeccionan las cargas útiles HTTP. Tampoco existe una categoría de detección para “su asistente de IA acaba de violar su propio umbral de confianza”. Esta brecha existe porque los canales de recuperación de LLM se encuentran detrás de una capa de aplicación que las herramientas de seguridad tradicionales nunca fueron diseñadas para observar.
Copilot ingirió un correo electrónico etiquetado que se le ordenó ignorar y toda la acción tuvo lugar dentro de la infraestructura de Microsoft. Entre el índice de recuperación y el modelo de generación. No se depositó nada en el disco, ningún tráfico anómalo cruzó el perímetro y no se generó ningún proceso para que un agente de terminal lo marcara. La pila de seguridad informó que todo estaba limpio porque nunca vio la capa donde ocurrió la infracción.
El error CW1226324 funcionó porque un error de ruta de código permitió que los mensajes en Elementos enviados y Borradores ingresaran al conjunto de recuperación de Copilot a pesar de las etiquetas de confidencialidad y las reglas DLP que deberían haberlos bloqueado, según el aviso de Microsoft. EchoLeak funcionó porque los investigadores de Aim Security demostraron que un correo electrónico malicioso, redactado para parecerse a una correspondencia comercial normal, podría manipular el canal de generación de recuperación aumentada de Copilot para acceder y transmitir datos internos a un servidor controlado por el atacante.
Los investigadores de Aim Security lo caracterizaron como un defecto de diseño fundamental: Los agentes procesan datos confiables y no confiables en el mismo proceso de pensamiento, lo que los hace estructuralmente vulnerables a la manipulación. Este defecto de diseño no desapareció cuando Microsoft parchó EchoLeak. CW1226324 demuestra que la capa de aplicación que la rodea puede fallar de forma independiente.
La auditoría de cinco puntos que mapea ambos modos de falla
Ninguna de las fallas provocó una sola alerta. Ambos se descubrieron a través de canales de consultoría de proveedores, no a través de SIEM, ni de EDR, ni de WAF.
CW1226324 se hizo público el 18 de febrero. Los inquilinos afectados han estado expuestos desde el 21 de enero. Microsoft no reveló cuántas organizaciones se vieron afectadas ni a qué datos se accedió durante este período. Para los líderes de seguridad, esta brecha es la historia: una exposición de cuatro semanas dentro del proceso de inferencia de un proveedor, invisible para todas las herramientas de la pila, descubierta sólo porque Microsoft decidió publicar un aviso.
1. Pruebe la aplicación DLP directamente en Copilot. CW1226324 existió durante cuatro semanas porque nadie probó si Copilot realmente respetaba las etiquetas de confidencialidad en los elementos y borradores enviados. Cree mensajes de prueba etiquetados en carpetas controladas, consulte Copilot y confirme que no puede mostrarlos. Ejecute esta prueba mensualmente. La configuración no es una imposición; la única prueba es un intento fallido de recuperación.
2. Evite que contenido externo llegue a la ventana contextual de Copilot. EchoLeak tuvo éxito porque un correo electrónico malicioso ingresó al conjunto de recuperación de Copilot y sus instrucciones inyectadas se ejecutaron como si fueran la consulta del usuario. El ataque pasó por alto cuatro capas distintas de defensa: el clasificador de inyección cruzada de Microsoft, la redacción de enlaces externos, los controles de políticas de seguridad de contenido y las salvaguardas de menciones de referencias, según la divulgación de Aim Security. Deshabilite el contexto de correo electrónico externo en la configuración de Copilot y restrinja la representación de Markdown en las salidas de IA. Esto detecta la clase de falla de inyección inmediata, eliminando por completo la superficie de ataque.
3. Registros de auditoría para interacciones anómalas del Copilot durante el período de exposición de enero a febrero. Busque consultas de Copilot Chat que arrojaron contenido de mensajes etiquetados entre el 21 de enero y mediados de febrero de 2026. Ninguna clase de falla produjo alertas a través del EDR o WAF existente, por lo que la detección retrospectiva se basa en la telemetría de Purview. Si su inquilino no puede reconstruir a qué accedió Copilot durante el período de exposición, documente esta brecha formalmente. Es importante para el cumplimiento. Para cualquier organización sujeta a escrutinio regulatorio, una brecha no documentada en el acceso a los datos de IA durante una ventana de vulnerabilidad conocida es un descubrimiento de auditoría a la espera de suceder.
4. Habilite la detección de contenido restringido para sitios de SharePoint con datos confidenciales. RCD elimina por completo los sitios del proceso de recuperación de Copilot. Funciona independientemente de si la violación de confianza proviene de un error de código o de un mensaje inyectado, porque los datos nunca ingresan a la ventana contextual. Esta es la capa de contención que no depende del punto de inspección que atravesó. Para organizaciones que manejan datos confidenciales o reguladosel RCD no es opcional.
5. Cree un manual de respuesta a incidentes para fallas de inferencia alojadas por el proveedor. Los manuales de respuesta a incidentes (IR) necesitan una nueva categoría: violaciones de los límites de confianza dentro del proceso de inferencia del proveedor. Definir rutas de escalada. Asignar propiedad. Establezca una cadencia de monitoreo para las advertencias de estado del servicio del proveedor que afectan el procesamiento de la IA. Tu SIEM tampoco detectará el siguiente.
El estándar que va más allá de Copilot
UNO Encuesta 2026 realizada por Cybersecurity Insiders descubrió que el 47% de los CISO y líderes sénior de seguridad han observado que los agentes de IA exhiben un comportamiento no intencionado o no autorizado. Las organizaciones están implementando asistentes de IA en producción más rápido de lo que pueden construir una gobernanza a su alrededor.
Esta trayectoria es importante porque esta estructura no es específica de Copilot. Cualquier asistente basado en RAG que extraiga datos empresariales sigue el mismo patrón: una capa de recuperación selecciona el contenido, una capa de aplicación controla lo que el modelo puede ver y una capa de generación produce resultados. Si la capa de aplicación falla, la capa de recuperación alimentará el modelo con datos restringidos y la pila de seguridad nunca los verá. Copilot, Gemini for Workspace y cualquier herramienta con acceso de recuperación a documentos internos presentan el mismo riesgo estructural.
Realice la auditoría de cinco puntos antes de la próxima reunión de la junta directiva. Comience con mensajes de prueba etiquetados en una carpeta controlada. Si Copilot las revela, todas las políticas subyacentes serán un teatro.
La junta responde: “Nuestras políticas se configuraron correctamente. La aplicación falló dentro del proceso de inferencia del proveedor. Estos son los cinco controles que estamos probando, restringiendo y exigiendo antes de volver a habilitar el acceso completo para cargas de trabajo confidenciales”.
El próximo fallo no enviará una alerta.
