Durante cuatro semanas a partir del 21 de enero, Copilot de Microsoft leyó y resumió correos electrónicos confidenciales a pesar de que todas las etiquetas de confidencialidad y las políticas de DLP le indicaban que no lo hiciera. Los puntos de cumplimiento se rompieron dentro del propio proceso de Microsoft y ninguna herramienta de seguridad en la pila lo detectó. Entre las organizaciones afectadas se encontraba el Servicio Nacional de Salud del Reino Unido, que lo registró como INC46740412 – una señal de hasta qué punto el fracaso llegó a los entornos sanitarios regulados. Microsoft lo rastreó como CW1226324.
El aviso, reportado por primera vez por BleepingComputer el 18 de febrero, marca la segunda vez en ocho meses que el proceso de recuperación de Copilot violó su propio límite de confianza: una falla en la que un sistema de inteligencia synthetic accede o transmite datos que no podía tocar explícitamente. El primero fue peor.
En junio de 2025, Microsoft parchó CVE-2025-32711una vulnerabilidad crítica sin clic que los investigadores de Goal Safety denominaron “EchoLeak”. Un correo electrónico malicioso pasó por alto el clasificador de inyección rápida de Copilot, su redacción de enlaces, su política de seguridad de contenido y sus menciones de referencia para exfiltrar silenciosamente datos empresariales. No se requirieron clics ni ninguna acción del usuario. Microsoft le asignó 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 ante esto
La detección y respuesta de endpoints (EDR) monitorea el comportamiento de archivos y procesos. Los firewalls de aplicaciones internet (WAF) inspeccionan las cargas útiles HTTP. Tampoco tiene una categoría de detección para “su asistente de IA acaba de violar su propio límite de confianza”. Esa brecha existe porque los canales de recuperación de LLM se encuentran detrás de una capa de cumplimiento que las herramientas de seguridad tradicionales nunca fueron diseñadas para observar.
Copilot ingirió un correo electrónico etiquetado que le dijeron que omitiera y toda la acción ocurrió 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 que un agente de punto remaining pudiera marcar. 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 en la ruta del 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 Goal Safety demostraron que un correo electrónico malicioso, redactado para que pareciera una correspondencia comercial ordinaria, 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 un atacante.
Los investigadores de Goal Safety 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. Ese defecto de diseño no desapareció cuando Microsoft parchó EchoLeak. CW1226324 demuestra que la capa de cumplimiento que la rodea puede fallar de forma independiente.
La auditoría de cinco puntos que se relaciona con ambos modos de falla
Ninguno de los fallos provocó una sola alerta. Ambos fueron descubiertos a través de canales de asesoramiento 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 habían estado expuestos desde el 21 de enero. Microsoft no ha revelado cuántas organizaciones se vieron afectadas ni a qué datos se accedió durante ese período. Para los líderes de seguridad, esa 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 de DLP directamente contra Copilot. CW1226324 existió durante cuatro semanas porque nadie probó si Copilot realmente respetaba las etiquetas de confidencialidad en los elementos enviados y los borradores. Cree mensajes de prueba etiquetados en carpetas controladas, consulte a Copilot y confirme que no puede mostrarlos. Ejecute esta prueba mensualmente. La configuración no es aplicación; la única prueba es un intento fallido de recuperación.
2. Bloquee el contenido externo para que no 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 las instrucciones inyectadas se ejecutaron como si fueran la consulta del usuario. El ataque pasó por alto cuatro capas de defensa distintas: el clasificador de inyección cruzada de Microsoft, la redacción de enlaces externos, los controles de política de seguridad de contenido y las salvaguardias de mención de referencias, según la divulgación de Goal Safety. 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 rápida al eliminar por completo la superficie de ataque.
3. Auditar los registros de Purview para detectar interacciones anómalas del Copilot durante el período de exposición de enero a febrero. Busque consultas de Copilot Chat que devolvieron contenido de mensajes etiquetados entre el 21 de enero y mediados de febrero de 2026. Ninguna clase de error produjo alertas a través de EDR o WAF existentes, por lo que la detección retrospectiva depende de la telemetría de Purview. Si su inquilino no puede reconstruir a qué accedió Copilot durante el período de exposición, documente esa brecha formalmente. Es importante para el cumplimiento. Para cualquier organización sujeta a un examen regulatorio, una brecha de acceso a datos de IA no documentada durante una ventana de vulnerabilidad conocida es un hallazgo de auditoría a punto de suceder.
4. Energetic 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, en primer lugar, los datos nunca ingresan a la ventana contextual. Esta es la capa de contención que no depende del punto de cumplimiento que se rompió. Para organizaciones que manejan datos confidenciales o reguladosel RCD no es opcional.
5. Cree un handbook 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 límites de confianza dentro del proceso de inferencia del proveedor. Definir rutas de escalada. Asignar propiedad. Establezca una cadencia de monitoreo para los avisos de estado de los servicios de los proveedores que afectan el procesamiento de la IA. Su SIEM tampoco captará el siguiente.
El patrón que se traslada más allá de Copilot
A Encuesta 2026 realizada por Cybersecurity Insiders descubrió que el 47% de los CISO y líderes senior de seguridad ya 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.
Esa trayectoria es importante porque este marco no es específico 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 cumplimiento falla, la capa de recuperación alimenta datos restringidos al modelo y la pila de seguridad nunca los ve. Copilot, Gemini for Workspace y cualquier herramienta con acceso de recuperación de documentos internos conlleva el mismo riesgo estructural.
Realice la auditoría de cinco puntos antes de su próxima reunión de la junta directiva. Comience con mensajes de prueba etiquetados en una carpeta controlada. Si Copilot los saca a la luz, todas las políticas subyacentes son un teatro.
La junta respondió: “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.
