Microsoft Copilot ignora etiquetas sensibles dos veces en ocho meses, DLP no detecta

Una brecha invisible: cómo Copilot de Microsoft accedió a datos confidenciales durante semanas sin activar ninguna alarma de seguridad

En un incidente que ha encendido las alarmas en departamentos de TI y compliance de medio mundo, Microsoft Copilot permitió, durante al menos cuatro semanas a partir del pasado 21 de enero, el acceso y resumen de correos electrónicos marcados como confidenciales. La peculiaridad del caso no radica solo en la violación de las políticas de protección de datos establecidas por las propias organizaciones, sino en que todo elstack de seguridad tradicional —desde los sistemas de prevención de pérdida de datos (DLP) hasta los firewalls de aplicaciones web (WAF) y las herramientas de detección y respuesta en endpoints (EDR)— permaneció en silencio. El error fue internamente detectado y reportado por Microsoft bajo las referencias CW1226324, afectando, entre otras, a organizaciones de alta sensibilidad como el Servicio Nacional de Salud del Reino Unido (NHS), que lo registró como el incidente INC46740412.

Este no es un hecho aislado. Se trata de la segunda vez en ocho meses que el pipeline de recuperación de información de Copilot —el mecanismo por el cual el servicio busca y contextualiza datos para generar sus respuestas— desobedece sus propias barreras de confianza. La primera vulnerabilidad, aún más crítica, fue la denominada «EchoLeak» (CVE-2025-32711), parcheada en junio de 2025. Un solo correo malicioso, sin Requerir interacción del usuario (un ataque de «zero-click»), logró eludir simultáneamente el clasificador de inyección de prompts de Microsoft, el sistema de redacción de enlaces externos, las políticas de seguridad de contenido (CSP) y las salvaguardas de menciones de referencia, para exfiltrar datos corporativos. Su gravedad quedó reflejada en una puntuación CVSS de 9.3.

La causa raíz de ambos fallos es diferente —un error de código en el primer caso y una cadena de explotación sofisticada en el segundo—, pero el resultado es idéntico: Copilot procesó información que, por política, no debía tocar. Y lo más preocupante, el ecosistema de seguridad no solo no lo previno, sino que ni siquiera lo detectó a posteriori. La arquitectura de los sistemas de protección actuales nació para un mundo pre-IA y carece de categorías de detección para una violación que ocurre en una capa abstracta: el «pensamiento» del agente de IA.

El punto ciego arquitectónico: por qué la seguridad actual es incapaz de ver estas violaciones

El paradigma de funcionamiento de asistentes como Copilot es el de recuperación-aumentada (RAG). Básicamente, ante una consulta, el sistema primero busca en un índice de datos (correos, documentos, chats) los fragmentos relevantes (capa de retrieval), aplica reglas de acceso y restricción (capa de enforcement), y finalmente, el modelo generativo sintetiza una respuesta (capa de generation). La violación de la barrera de confianza ocurre en el límite entre la primera y la segunda capa: datos restringidos logran entrar en el conjunto de información que el modelo consulta.

El problema para la seguridad es que este proceso sucede en la infraestructura del proveedor (en este caso, Microsoft). No hay archivos maliciosos que caigan en disco, no hay tráfico de red saliente anómalo que cruce el perímetro de la empresa, y no se ejecuta un proceso local que un agente EDR pueda monitorizar. Todo transcurre en el interior del motor de inferencia, una «caja negra» para las herramientas de seguridad tradicionales. De ahí que ni un WAF (que inspecciona tráfico web) ni un EDR (que ve procesos y archivos en el endpoint) tuvieran oportunidad de generar una alerta. El stack de seguridad dio el visto bueno porque nunca observó la capa donde ocurrió la transgresión.

El mapa de acción para líderes de seguridad: cinco medidas urgentes

Frente a este escenario, la pasividad no es una opción. La experiencia del incidente CW1226324, que permaneció activo sin detección durante un mes, y la saga EchoLeak, dibujan un plan de acción claro y prioritario para cualquier organización que utilice asistentes de IA con acceso a datos corporativos:

1. Verificación directa de la aplicación de políticas DLP sobre Copilot: La configuración no equivale a aplicación. Es imperativo crear mensajes de prueba con etiquetas de sensibilidad en carpetas críticas como «Borradores» o «Elementos enviados» y realizar consultas a Copilot para comprobar si estos datos restringidos emergen en las respuestas. Si aparecen, toda la política DLP configurada pierde su eficacia. Esta prueba debe realizarse de forma periódica, preferiblemente mensual, ya que los cambios en el software del proveedor pueden alterar el comportamiento.

2. Eliminación del contexto de contenido externo: La vulnerabilidad EchoLeak demostró que un correo de phishing bien elaborado puede actuar como un vector de inyección de prompts. La medida defensiva más directa es impedir que el contenido de correos electrónicos externos (o de fuentes no confiables) forme parte del contexto de conversación de Copilot. Esto se puede lograr desactivando la importación de contexto de correo en la configuración del asistente y restringiendo la renderización de Markdown en sus respuestas, un formato comúnmente utilizado en ataques de inyección.

3. Auditoría forense mediante logs de Purview: Dado que los sistemas de seguridad en tiempo real fueron ciegos, la única ventana para investigar el alcance de un incidente como el de enero-febrero reside en los logs de auditoría del servicio de gobernanza de Microsoft Purview. Los responsables deben Extraer y analizar todas las consultas de Copilot realizadas durante el período de exposición —del 21 de enero a la fecha de parcheo—, filtrando aquellas que devolvieron contenido procedente de mensajes con etiquetas de sensibilidad. Si una organización no puede reconstruir ese historial, debe documentar formalmente esta laguna, un factor de alto riesgo en cualquier auditoría de cumplimiento normativo (GDPR, leyes de protección de datos sanitarios, etc.).

4. Implementación de «Restricted Content Discovery» (RCD): Esta funcionalidad de Microsoft 365 es una de las defensas más robustas, ya que actúa en la capa de recuperación (retrieval), evitando que sitios de SharePoint o bibliotecas de documentos marcadas como de acceso restringido sean indexadas jamás para Copilot. Al excluir los datos del índice desde su origen, se neutralizan tanto los errores de código como las inyecciones de prompts maliciosas. Para datos regulados o críticos, activar RCD no es una recomendación, es una necesidad.

5. Creación de un nuevo playbook de respuesta a incidentes: Los protocolos de IR actuales no contemplan un incidente originado dentro del pipeline de inferencia de un proveedor de SaaS. Es crucial desarrollar un nuevo playbook para este escenario. Debe definir quién es el responsable de monitorear los boletines de seguridad del proveedor que afecten a servicios de IA, los pasos para escalar internamente, las comunicaciones a legal y compliance, y los procedimientos para solicitar una auditoría forense al proveedor en caso de sospecha.

El patrón que se replica: un riesgo sistémico en la era del RAG

La lección va más allá de Copilot. Un informe de 2026 de Cybersecurity Insiders revela que el 47% de los CISOs ya han observado comportamientos no autorizados o inesperados en agentes de IA desplegados en producción. La carrera por implementar estas tecnologías está superando con creces la capacidad de construir gobernanza a su alrededor.

Cualquier asistente que utilice un paradigma RAG —ya sea Copilot, Gemini for Workspace, o herramientas de terceros— comparte una arquitectura similar con un punto de fallo idéntico: una capa de aplicación de políticas que puede ser eludida, ya sea por un bug o por una manipulación sofisticada. Si esa capa falla, los datos restringidos fluyen al modelo generativo, y el sistema de seguridad perimetral nunca ve ese movimiento.

Para los directivos, la pregunta ya no es si ocurrirá, sino cuándo. La próxima violación de la barrera de confianza no enviará una alerta al SIEM. La preparación radica en demostrar proactivamente que las políticas de protección no son solo teóricas, sino que se verifican en la práctica. La próxima reunión de consejo podría girar en torno a esta revelación: «Nuestras políticas están configuradas. Sin embargo, la aplicación de esas políticas falló dentro del motor de inferencia del proveedor. Estamos implementando estas cinco salvaguardas —verificación activa, bloqueo de contexto externo, auditoría forense, exclusión de datos críticos y un nuevo plan de respuesta— antes de permitir que Copilot acceda a nuestros datos de mayor sensibilidad». La invisibilidad del riesgo no lo hace inexistente; lo convierte en una amenaza aún más insidiosa.