EchoLeak: el zero-click que me hizo dudar de Copilot

 

A mí me costó procesar lo que pasó con EchoLeak. No la parte técnica — esa la entiendes leyendo el writeup de Aim Labs. Lo que me costó fue aceptar que un atacante podía mandarte un correo, tú no hacías nada con él, y aún así Copilot terminaba filtrándole datos de tu Outlook y tu Graph al de afuera. Cero clics. Cero interacción. El correo llegaba, Copilot lo procesaba en algún momento mientras hacías otra consulta, y ya estaba.

CVE-2025-32711, CVSS 9.3. Microsoft lo parcheó server-side rapidito y sin advisory ruidosa. Lo cual me parece bien y me parece mal a la vez. Bien porque la mitigación tiene que ser inmediata. Mal porque sospecho que muchos equipos de seguridad ni se enteraron de la magnitud hasta que los investigadores publicaron el detalle en arXiv unos meses después.

 

Lo que más me marcó del writeup es la elegancia del exploit. No es un bug. Es una cadena.

Primero, evade el clasificador XPIA (Cross Prompt Injection Attempt) usando lenguaje que no se ve como instrucción adversaria. Después esquiva la redacción de enlaces con Markdown reference-style (en lugar de poner el enlace con el dato sensible directo, lo separa en una referencia). Después usa imágenes que se auto-fetchean — el simple acto de cargar la imagen ya filtra el dato porque la URL lleva la información. Y el cierre de oro: abusa de un proxy de Teams que está permitido por la Content Security Policy. Filtración limpia.

Lo bauticé en mi cabeza como “el vector que demuestra que la CSP de tu app no es suficiente cuando metes un LLM en medio”. Porque eso es lo que es. La CSP estaba bien para una app tradicional. Para una app que tiene un agente que decide a qué dominio se conecta, la CSP es solo el principio.

Qué hago yo distinto desde EchoLeak

Lo primero, asumo que cualquier dato no estructurado que Copilot toque es input no confiable. No solo correos de fuera. También documentos compartidos por terceros, también notas pegadas de quién sabe dónde. Eso ya cambia cómo configuro las políticas de DLP.

Segundo, miro con otros ojos las funcionalidades de “auto-summarize”. Cualquier cosa donde Copilot procese contenido sin que yo le pida explícitamente que lo haga es vector. Es ahí donde EchoLeak metió la cuchilla.

Tercero, y esto es opinión: creo que Microsoft tardó en sacar Spotlighting. Lo anunciaron en Build 2025, pero la categoría de ataque ya se conocía. Spotlighting marca el origen del input para que el modelo distinga “esto me lo dijo el usuario” de “esto venía dentro de un documento”. Era un control que necesitábamos antes, no después.

Para mi equipo hicimos tres cosas concretas las semanas siguientes. Auditamos qué buzones tienen reglas de auto-procesado que terminen llegando a Copilot — apagamos varias. Forzamos sensitivity labels en todo lo que viene de invitados externos: si entra etiquetado como external, Copilot no lo procesa. Y activamos logging completo de prompts en Purview, aunque pesa un montón. Sin auditoría no hay forensia.

Lo último — y esto es lo que me sigue rondando — es que EchoLeak no fue un fallo en un modelo grande. Fue un fallo en cómo Microsoft pegó el modelo al resto del stack: identidades, permisos, cargas de URL, parsers de Markdown. La superficie de ataque del Copilot empresarial no es el LLM. Es la conexión del LLM con todo lo demás.

El día que entendí eso fue el día que dejé de ver a Copilot como un producto y empecé a verlo como una integración compleja. Y las integraciones complejas se rompen en las costuras.

 

 

 

 

 

El equipo rojo automatizado: AI Red Teaming Agent en Foundry

 

Antes, hacer red team a un agente de IA era trabajo artesanal. Un humano experto, pensando como atacante, probando payloads, observando comportamiento, iterando. Caro, lento, no escalable.

Microsoft sacó el AI Red Teaming Agent en Foundry para cambiar eso. La promesa: red team automatizado, escalable, repetible. La realidad: útil, no sustituto.

Lo probé en serio este trimestre, contra dos agentes de Copilot Studio que tengo en producción ligera. Voy a contar lo que vi.

Qué hace

El agente toma tu agente bajo prueba y le tira payloads adversarios desde una librería curada. Cubre prompt injection directa, indirecta, jailbreak, content harms, tool abuse, agent hijack. La librería se actualiza. También permite cargar payloads custom, así que si tienes tu propio dominio (financiero, salud, legal), puedes meter ataques específicos.

Te entrega un reporte: qué payload pasó, qué se bloqueó, qué generó respuestas problemáticas. Métricas, severidades, sugerencias de mitigación.

 

Lo bueno

Velocidad. Mil ataques en una hora. Un humano hace cien en un día bueno. La cobertura amplia es donde brilla. Si tu agente tiene un patrón de fallo conocido, casi seguro lo encuentra.

Repetibilidad. Cada nueva versión de tu agente la pasas por la misma batería. Detectas regresiones. CI/CD para seguridad de IA. Esto es lo que más me cambió: meter el red teaming en el pipeline, no como ejercicio anual.

Integración con Foundry. El reporting fluye al mismo lugar donde llevas el resto de tus pruebas y safety evaluations. Vista única.

Lo no tan bueno

Encuentra ataques conocidos. Brilla menos con ataques nuevos, sutiles, específicos a tu dominio. Si tienes un caso de negocio peculiar, los payloads genéricos no van a detectar todos los caminos. Necesitas un humano experto que escriba payloads específicos a lo tuyo. El agente automatiza lo conocido, no lo creativo.

La interpretación de resultados sigue requiriendo expertise. Reporte que te dice “12 ataques pasaron, 88 bloqueados”. OK. ¿Cuáles son los 12? ¿Cuáles importan más? Eso lo tienes que entender tú o alguien con criterio.

Falsos positivos pasan. A veces el agente clasifica un comportamiento como problemático cuando es esperado en tu caso. La triangulación con un humano es necesaria.

 

Cómo lo uso

Para regresiones: parte del pipeline. Cada cambio de prompt, cada nuevo conector, cada update del modelo, batería completa. Si la baseline empeora, alerta antes de promover a producción.

Para baseline en agentes nuevos: antes de meter un agente nuevo a producción, ejercicio completo. Si pasa los ataques conocidos, listo el primer filtro. Después le sigo con red team manual sobre lo específico de mi dominio.

Para auditoría: el reporte automatizado es excelente evidencia para auditores externos. “Aquí está el resultado de la batería de pruebas adversarias contra cada agente, ejecutada cada N días”. Antes esto era difícil de producir. Ahora es un export.

Lo que me gustaría que tuviera

Más payloads en español. La librería está fuerte en inglés y los modelos modernos transfieren razonablemente, pero los ataques en español tienen sutilezas. Espero que la librería se siga internacionalizando.

Soporte mejor para agentes multi-step complejos. Los ataques que se desarrollan a lo largo de varios turnos, con planificación, son más difíciles de automatizar. Hoy detecta lo turn-by-turn bien, lo multi-turno con menos profundidad.

Integración nativa con MCP. La capacidad de probar agentes que usan MCP servers externos. Esto es un gap. Hoy si tu agente usa MCP, la cobertura del red team baja porque no entiende del todo las superficies extra. Espero ver mejoras en los próximos meses.

 

¿Es suficiente? No. Es parte del programa de seguridad, no el programa entero. Pero es un avance gigante respecto a hace dos años, donde literalmente no existía esta categoría de herramienta.

Si tienes agentes en producción y no estás haciendo red teaming sistemático sobre ellos, es la pieza que más rápido te baja el riesgo. Hazlo ahora.

Sensitivity labels: la taxonomía que sí funciona con Copilot

 

Tres veces en mi carrera he tenido que rehacer el esquema de sensitivity labels de una organización. La tercera fue después de meter Copilot. Voy a explicar por qué.

Los esquemas que se diseñaron antes de Copilot tienen un sesgo: están pensados para humanos clasificando documentos. Cinco niveles, descripciones largas, instrucciones que el usuario teóricamente lee al elegir el label. En la práctica, el usuario clica el primero que ve y sigue. Cuando Copilot empieza a actuar sobre esas etiquetas, los problemas afloran.

Mi taxonomía actual, después de tres iteraciones

Cuatro niveles, no más. Más de cuatro y la gente se confunde. Public, Internal, Confidential, Restricted. Cada nivel con un sub-marcador opcional (“External-Allowed” o “External-Blocked”). El sub-marcador ataca el problema de “es confidencial pero el partner X sí lo puede ver”.

Reglas claras de procesamiento por Copilot. Cada label tiene una regla explícita: ¿Copilot puede leer? ¿Puede generar contenido derivado? ¿Puede compartir en la respuesta a un usuario externo invitado? La matriz cabe en una página.

Auto-labeling agresivo en lo trivial. SSN, números de tarjeta, IBANs, datos de RRHH conocidos — auto-label sin pedirle al usuario. La auto-classification de Purview es buena. Confío en ella para el 70% del corpus. El 30% restante lo etiqueta el usuario.

Defaults razonables. Si un sitio nuevo se crea sin label, hereda “Internal” por política. Antes era “Public” por descuido. Eso solo bajó mi superficie de exposición en un 12%.

Lo que aprendí en el camino

Que un label complicado se ignora. La gente no quiere leer. La gente quiere clicar.

Que los labels por sí solos no protegen. Un label sin DLP detrás es un papel en la pared. Yo combino label más DLP más Conditional Access. Las tres capas o ninguna.

Que migrar es doloroso. Tuve documentos con label viejo, documentos con label nuevo, documentos sin label. Tomó cuatro meses migrar el corpus crítico. Los demás documentos los seguimos limpiando. La perfección es enemiga del progreso.

Que Copilot acelera la limpieza. Cuando un usuario pregunta a Copilot por algo y la respuesta se bloquea por DLP, el usuario reporta. Cada bloqueo es feedback. Cada feedback me dice qué documentos tienen el label mal puesto. La operación de Copilot se vuelve auditoría continua del esquema de labels.

¿Lo recomendaría? Sí, pero con expectativas reales. Diseñar bien lleva semanas. Implementar lleva meses. Madurar lleva un año. Si tienes Copilot en piloto y sensitivity labels todavía sin definir, no demores. La complejidad solo crece.

Customer Lockbox y Copilot: ¿realmente aplica?

 Pregunta que me hicieron en una llamada con un cliente: “¿Customer Lockbox aplica a Copilot?”. Pregunta razonable. Respuesta corta: parcialmente. Respuesta larga: lee esto.

Customer Lockbox de Microsoft es el mecanismo por el cual, si un ingeniero de Microsoft necesita acceso a tus datos para soporte técnico, tú apruebas o rechazas la solicitud. Tu dato no se toca sin tu OK. Es una de las garantías que más vendí en los últimos años a clientes nerviosos por privacidad.

Qué pasa con Copilot

Para datos almacenados en Microsoft 365 (correo, archivos en SharePoint y OneDrive, mensajes de Teams), Customer Lockbox aplica como siempre. Si un ingeniero de Microsoft necesita revisar uno de esos datos para resolver un problema de Copilot, requiere tu aprobación.

Para los datos en tránsito en el procesamiento de Copilot — el prompt que el usuario manda, la respuesta generada — la situación es distinta. Esos datos viven en el plano de inferencia. Customer Lockbox no aplica de la misma forma. Microsoft documenta que prompts y respuestas no se usan para entrenar y se eliminan según retención. Pero el modelo de Customer Lockbox tradicional no se extiende todavía con el mismo rigor.

Para los logs de Copilot (qué pidió cada usuario, qué respondió el modelo) que se almacenan en Purview con tu retención — eso vuelve a ser dato tuyo y Customer Lockbox aplica.

Esto no es un gap de seguridad. Es un gap de garantía formal de control de acceso operativo.

¿Importa?

Depende de tu industria. Para banca o salud altamente regulado, el modelo “Microsoft no toca mis datos sin que yo apruebe” es importante. Si Customer Lockbox no cubre prompts en tránsito, tienes que documentar el gap y mitigarlo de otra forma — confidential compute, o aceptar el control compensatorio del acuerdo contractual con Microsoft.

Para la mayoría de empresas, no es un blocker. Microsoft tiene controles internos robustos, attestations independientes, y el modelo de procesamiento de Copilot no es de “ingenieros viendo prompts”. Es automatizado.

Qué hago yo

Primero, no vendo Customer Lockbox como garantía total para Copilot. Sería deshonesto. Vendo lo que aplica y soy claro sobre lo que no.

Segundo, para clientes muy regulados, busco alternativas: Confidential Compute donde está disponible, in-country processing donde aplique, contratos específicos donde el riesgo lo justifica.

Tercero, monitoreo. Microsoft mejora estas garantías con el tiempo. Customer Lockbox para AI services es área activa. Espero updates en los próximos 6 a 12 meses.

Resumen para no técnicos: Customer Lockbox es real para tus datos almacenados. Para el procesamiento de IA en sí, hay garantías distintas pero no Customer Lockbox como tal. Léelo en el contrato, no en el marketing.

SharePoint Advanced Management: el primer paso, no el último

 

Una de las cosas que cambió silenciosamente cuando Microsoft empezó a incluir SharePoint Advanced Management con Copilot fue que de repente todo el mundo tenía la herramienta para hacer un assessment serio. Antes era licencia aparte, costaba dinero adicional, y muchos equipos se la saltaban.

SAM no es nuevo. Lo que es nuevo es que ya no tienes excusa para no usarlo si tienes Copilot.

Para quien no lo conozca: SAM (SharePoint Advanced Management) es un paquete de capacidades de governance para SharePoint. Inactive sites detection, oversharing reports, data access governance reports, conditional access policies a nivel de site, restricted access control. Una colección de cosas que viven en distintos rincones del admin center pero apuntan al mismo problema: tu SharePoint creció sin gobierno y ahora hay que ordenarlo.

El primer reporte

Cuando lo activé por primera vez en mi tenant, el reporte inicial fue, cómo decirlo, humillante.

Sitios inactivos con datos sensibles: 1,247. Sitios con permisos rotos (heredados pero el padre se borró): 89. Sitios con “Everyone except external users” en el grupo de Members: 312. Sitios sin propietario asignado válido (el dueño ya no estaba en la empresa): 56.

Y eso solo en la primera pasada. La segunda, con filtros más finos, sacó otra capa.

 

Lo que hice con esos datos

Para sitios inactivos: política nueva. Si no se accede en 90 días, archive workflow. Si nadie reclama en 30 días más, archivado. Si nadie reclama en 180 días desde el archive, candidato a eliminación. SAM permite automatizar buena parte de eso con políticas. La parte humana — confirmar con dueños — la tienes que orquestar tú.

Para “Everyone except external users”: más doloroso. Cada uno requería un revisor. Lo que ayudó fue una matriz de criticidad de datos: qué tipo de contenido tiene cada sitio. Los críticos (legal, finanzas, RRHH) los atacamos primero, manualmente. Los menos críticos los atacamos en cohortes.

Para permisos rotos: SAM los identifica pero no los arregla. Hay que entrar uno por uno o usar PowerShell. Lo más eficiente para nosotros fue agruparlos por área y mandar un ticket por área al dueño funcional con la lista. Que ellos se hagan cargo. Y si en X días no se responde, escalado.

Lo que SAM no hace

No es DLP. SAM te dice quién tiene acceso. Purview DLP te dice qué se puede hacer con el contenido. Son complementarios.

No es scanning de contenido. SAM mira permisos y metadata. Si tienes un PDF con SSN dentro pero el archivo está en un sitio “limpio” en cuanto a permisos, SAM no te lo dice. Para eso, sensitivity labels más auto-labeling de Purview.

No es un sustituto de governance proactivo. SAM te ayuda a limpiar lo viejo. Si no cambias cómo se crean nuevos sitios — templates con permisos sensatos, dueños obligatorios, lifecycle defaults — vas a estar limpiando para siempre.

 

Mi flujo actual

Al inicio de cada quarter, corro reporte completo. Diff contra el quarter pasado. Métrica clave: ¿bajaron sitios con problemas, o subieron? Si subieron, política nueva no funcionó. Si bajaron, mantengo curso.

Mensualmente, alerta de nuevos sitios sin propietario. Estos son la fuente principal de problemas futuros. Reasignar al crear, no al limpiar.

Trimestralmente, review con cada área de sus sitios críticos. SAM da el dato, el área toma la decisión. La governance funciona si los dueños se sienten dueños.

Lo último que diría: SAM no resuelve nada por ti. Es luz, no acción. Si no asignas el tiempo a actuar sobre lo que la luz revela, mejor no la enciendas — porque entonces es solo evidencia documentada de que sabías y no hiciste nada. Y eso, en una auditoría, es peor que la ignorancia.

El pecado original que Copilot hizo evidente

 

Antes de Copilot, el oversharing en SharePoint era ese problema que todos sabíamos que teníamos pero que nadie quería abrir. “Le pongo Everyone al sitio mientras lo configuro y luego lo limpio”. Y nadie lo limpiaba. Pasaban tres años.

 

Copilot llegó y rompió la complicidad colectiva.

Los datos que más he citado este año vienen de un reporte de Concentric: 16% de los datos críticos de negocio están sobre-compartidos, con un promedio de 802 mil archivos en riesgo por organización. Yo en mi tenant medí algo parecido: 14% en una primera pasada. Ese 14% incluía nóminas, contratos con clientes, una carpeta entera de la junta directiva accesible a “Everyone except external users”. Que es básicamente “todo el mundo de la empresa”.

 

¿Por qué Copilot lo hace evidente? Porque acelera el descubrimiento. Antes, esos archivos solo aparecían si alguien sabía buscar el nombre exacto. Copilot, con prompt y contexto, los superficie. “Resúmeme lo que sepamos de la compensación del C-suite”. Y boom, te aparece un PDF de la junta que estaba mal compartido desde 2022.

Microsoft ha intentado dar herramientas. La principal es Restricted SharePoint Search, que ayuda a limitar qué sitios entran al pool de búsqueda de Copilot. Pero hay que leer la letra chica: Microsoft mismo dice que no es un control de seguridad. Es un control de visibilidad temporal. No cambia permisos. Y si un usuario entró al sitio recientemente o le compartieron un enlace por Teams, el sitio aparece igual. Restringir la búsqueda es ganar tiempo, no resolver el problema.

 

La solución de fondo es arreglar permisos. Lo cual nadie quiere oír.

 

Lo que me funcionó

Empecé por las “joyas de la corona” — conté con el dueño de cada función qué cinco repositorios le quitarían el sueño si se filtraran. Quince personas, setenta y cinco repositorios. Ahí concentré el primer esfuerzo. No traté de arreglar todo SharePoint en un trimestre porque no se puede.

Después usé SharePoint Advanced Management (SAM, viene incluido con Copilot) para la evaluación masiva. El reporte inicial es brutalmente honesto. Te enseña sitios inactivos con miembros que ya no están. Sitios con permisos heredados rotos. Sitios donde “Everyone” tiene Edit. Para varios equipos, esa visibilidad fue suficiente para que se pusieran a limpiar sin pelearse conmigo.

Después puse políticas defensivas: nada nuevo se crea con “Everyone except external” como permiso por defecto. Forzamos labels de sensibilidad en plantillas. Auditamos creaciones nuevas semanalmente.

 

Lo que no funcionó: tratar de “limpiar todo” con un script. Cada sitio tiene un dueño y una historia. Los scripts son útiles para encontrar problemas, no para resolverlos.

Lo que tampoco funcionó: meterle miedo a la gente con ejemplos hipotéticos. Lo que sí funcionó fue mostrar a un VP, en su pantalla, que su asistente podía hacer un prompt en Copilot y obtener información de su salario que no debería ver. Diez minutos. Esa demo aceleró tres meses de cleanup.

Mi conclusión a estas alturas: Copilot no creó el problema de oversharing. Lo aireó. Y eso es bueno, aunque duela.

Si yo te diera un solo consejo para tu siguiente reunión interna sobre este tema, sería este: deja de hablar de “permisos” y empieza a hablar de “dueño accountable de cada repositorio”. Cuando hay un nombre y apellido al lado de cada sitio, las cosas se mueven. Cuando es “el equipo de IT”, se quedan dormidas.

 

Restricted SharePoint Search no es lo que crees

 

Hay una pequeña batalla que doy cada mes con alguien nuevo que llega al equipo: “ya activamos Restricted SharePoint Search, así que el tema de oversharing está controlado”. No.

Tengo que escribir esto porque me pasa con demasiada frecuencia.

Restricted SharePoint Search hace una cosa muy concreta: limita qué sitios entran al pool que Copilot consulta y que aparece en búsqueda corporativa. Es un control de discoverability. Útil. No discuto que sea útil. Lo uso. Lo recomiendo.

 

Lo que no es

No es un control de seguridad. Microsoft mismo lo dice en la documentación oficial, en negritas. No cambia permisos. Si el archivo existía y el usuario tenía acceso antes, sigue teniendo acceso después.

No garantiza que un sitio fuera del allowed list no aparezca. Si el usuario tocó el sitio en los últimos N días, si se lo compartieron por Teams, si se lo enviaron por Outlook, ese sitio puede entrar al contexto igual. Microsoft lo documenta también, pero con menos negritas.

No es solución permanente. Microsoft lo presenta explícitamente como un parche temporal mientras arreglas permisos. La traducción del marketing al ingeniero es: úsalo mientras limpias, no como sustituto del cleanup.

Cómo lo usé en el rollout

Cuando hice el rollout de Copilot el año pasado, lo activé en día uno. Eso me dio algo de aire mientras montábamos el programa de remediación. Le metí 200 sitios al allowed list — los que sabíamos que estaban limpios y eran útiles. El resto quedaba excluido del pool por defecto.

Resultado bueno: la calidad de las respuestas de Copilot bajó al inicio. Era predecible — limitaste su contexto. Algunos usuarios protestaron. “Copilot ya no encuentra mis documentos”. Tuvimos que explicar que era temporal. Gestión del cambio que no se puede saltar.

Resultado malo: los falsos positivos de seguridad de algunos managers explotaron. “Yo le pregunté X y me sacó un PDF de un sitio que pensaba que estaba bloqueado”. Investigamos. Sí, el sitio estaba bloqueado en el allowed list. Pero el manager lo había abierto la semana anterior porque alguien le compartió un link. Copilot lo trajo del cache de actividad reciente del usuario.

Microsoft no está mintiendo cuando documenta esa limitación. Pero la mayoría de equipos no la entienden hasta que la viven.

Después de seis meses de cleanup serio (con SAM, Purview, y mucho café), pude empezar a quitar sitios del exclude. Hoy uso Restricted SharePoint Search con una lista mucho más permisiva, porque ya no necesito el dique. Tengo permisos correctos.

La trampa para nuevos usuarios

Se ve fácil de configurar. Lo activas, metes una lista, y parece que terminaste. Y por seis meses, todo parece estar bien. Hasta que un auditor te pregunta cómo garantizas el control. Y le tienes que decir, mirando al suelo, que no es un control de seguridad. Es un freno suave.

Mi recomendación práctica: trátalo como herramienta táctica de transición. Día 1 lo activas con allowed list pequeña. A medida que limpias permisos, expandes la lista. A los 12 meses, idealmente, ya no la necesitas, o la usas solo para áreas con compliance específico. Es un puente, no la torre.

Y, por favor, no le digas a tu C-suite que “tienes oversharing controlado” si tu única defensa es Restricted SharePoint Search. Porque cuando alguien encuentre el archivo equivocado y suba la queja, el reporte forense va a doler.