Agent 365 ya está GA: lo que pagas con esos 15 dólares al mes

 

 

El 1 de mayo arranca la disponibilidad general de Agent 365. Quince dólares por usuario al mes. He visto comentarios mixtos en LinkedIn — unos dicen que es un robo, otros que es regalado. Como casi siempre, depende.

Voy a tratar de ser concreto sobre qué te dan por ese precio. Lo escribo aprovechando que estuve dos semanas haciendo el piloto en uno de los tenants donde tengo manos.

Lo primero: Agent 365 no es un producto, es un control plane. Esa distinción importa. No te da más capacidad de Copilot. Te da más visibilidad y control sobre los agentes que ya existen y los que vienen. Si tu organización no tiene aún muchos agentes desplegados, el ROI es difícil de defender el primer trimestre. Si tienes Copilot Studio en uso o gente experimentando con agentes locales, la cosa cambia.

Lo que viene en la caja a mayo 2026

Runtime Protection (preview). Esto es lo que más me interesa. Monitorea al agente en tiempo de ejecución. Si el agente hace algo raro — accede a un origen no esperado, llama un API que no debería, mueve un archivo a un lugar improbable — lo flaggea. Y, si tú lo configuras así, le revoca permisos automáticamente. Es la primera vez que veo a Microsoft tratar a un agente como tratan a un endpoint con Defender. Misma filosofía: comportamiento, no firma.

Network-Layer monitoring. Extiende los controles de Entra Internet Access a los agentes. Esto significa que las conexiones del agente pasan por la misma inspección que ya tienes para los usuarios. Lo más valioso es restringir destinos web aprobados. Si tu agente solo puede hablar con APIs de tu lista, los exfil exploits a la EchoLeak pierden el destino.

Shadow AI discovery. La pieza que más me sorprendió en el piloto. Defender + Intune detectan agentes locales corriendo en endpoints Windows. Empezó con OpenClaw. La hoja de ruta menciona explícitamente GitHub Copilot CLI y Claude Code. Es decir, Microsoft está poniendo en su radar a los agentes que corren fuera de su stack. Pragmático. Honesto. Necesario.

Centralización en una consola. Registro de agentes, permisos, propietarios, telemetría, alertas. Antes esto vivía repartido entre Entra, Defender, Purview y la consola de Copilot Studio. Ahora hay un sitio único. Que funciona razonablemente bien — algunos paneles aún cargan lentos, pero mejor que pelearse con cuatro pestañas.

¿15 dólares por usuario al mes vale la pena?

Mi cálculo. Si tienes más de 500 usuarios con Copilot Studio activo y agentes en producción, el incidente que evitas con Runtime Protection paga el año completo. Si tienes menos de 100 y solo agentes “experimentales”, probablemente puedas esperar al refresh de cuatro o seis meses. El upside del precio es que escala sin que pagues por agente — pagas por usuario humano. Para una empresa donde un humano tendrá pronto seis o siete agentes ejecutándose en su nombre, es un modelo razonable.

Lo que me incomoda del precio: te obliga a pagar por usuarios que ni tocan agentes. No hay tier para “solo licenciar a quienes los usan activamente”. Microsoft sabe que la curva de adopción va hacia arriba, así que apuesta por cobrar todo el rebaño. Aceptable, pero opaco.

¿Qué hago si fuera tú? Lo que hice yo: piloto de 90 días con un grupo controlado, métricas claras antes de empezar (cuántos agentes registrados, cuántas anomalías detectadas, cuántos shadow agents encontrados), y decisión basada en datos. Si el shadow AI discovery te encuentra en el primer mes diez agentes que no sabías que existían, el precio se justifica solo. Si te encuentra cero, igual te dice algo importante: o estás muy maduro o no estás mirando bien.

Ya veremos cómo evoluciona. Por ahora, prefiero tenerlo activo a no tenerlo.

La ventana de chat de Security Copilot dentro de Defender XDR

 

En el update de abril, Microsoft metió una ventana de chat de Security Copilot dentro de Defender XDR. Suena a feature pequeña. No lo es.

Antes, cuando un analista del SOC tenía un incidente abierto, vivía con dos pestañas: la del incidente y la de Security Copilot. Copiaba contexto entre ambas. Pegaba IDs, hashes, IPs, nombres de host. La fricción era constante. Yo medí un día cuántos clicks gastaba un analista L2 en una hora de triage cruzando Defender con Copilot. 437 clicks. Cuatrocientos treinta y siete.

Ahora el chat vive dentro del incidente. Le preguntas al modelo sobre el incidente abierto, sin copiar nada. El contexto ya está cargado.

Las preguntas que más se hacen mis analistas

“Qué dispositivos están afectados”. Te lo da con confidencias por dispositivo.

“Cuáles son las identidades comprometidas”. Lista, con riesgo asignado.

“Compárame este incidente con los tres últimos parecidos”. Aquí brilla. Antes esto era un script de búsqueda ad-hoc en KQL. Ahora una pregunta.

“Qué acciones recomendarías en orden”. Te las prioriza con justificación. No siempre acierta. Pero la lista te ahorra el primer borrador.

Lo que está mejor de lo que esperaba

La calidad de las respuestas con contextos largos. Defender tiene incidentes con cientos de eventos. La ventana de chat los resume bien. No vi alucinaciones graves en mis tres semanas. Vi imprecisiones — un par de veces dijo “endpoint X” cuando era “endpoint Y” — pero detecto bien con un segundo de revisión.

Lo que está peor de lo que esperaba

La latencia. Para incidentes grandes, la primera respuesta tarda 8 a 12 segundos. Después es más rápido. Los analistas se quejan del primer paso. Microsoft sabe, está prometido bajar.

Lo que cambió en mi operación

Bajé el tier 1 a la mitad. No despedí a nadie — los moví a tier 2. El modelo hace el triage inicial de muchos incidentes. Los analistas humanos validan y deciden las acciones complejas. Mi MTTD bajó algo. Mi MTTR bajó más.

Subí los criterios de las cosas que Security Copilot puede ejecutar autónomamente. Antes era todo “sugerir, humano ejecuta”. Ahora hay un puñado de acciones (aislar dispositivo confirmado, bloquear IP en blocklist conocida, deshabilitar cuenta en lista de acciones aprobadas) que el modelo ejecuta solo, con notificación. La auditoría duerme tranquila porque cada acción tiene log y razón.

Subió mi consumo de SCUs. Esto es importante. La ventana de chat es seductora. Los analistas la usan más. Y cada query gasta. Si no metes cost caps por usuario, el final del mes te va a sorprender. Yo los puse en la segunda semana después de que un analista corrió 600 queries en un turno. Útil. Caro.

¿Lo recomendaría? Sí. Es de las cosas que justifican Security Copilot por sí solas, si tu SOC tiene volumen. Si tu SOC trabaja 5 incidents por día, no se nota. Si trabaja 50, cambia tu vida.

Una cosa que pediría a Microsoft: poner el chat también en Sentinel con el mismo nivel de integración. Hoy la experiencia entre ambos es desigual. Mismo motor, distinta integración. Espero que en próximos updates lo cierren.

Al final, esto es lo que compras con Security Copilot incluido en E5: que esté ahí donde el analista ya está mirando. La integración es la mitad del valor del modelo.

Copilot ya está en el risk register: lo que cambia para mí como CISO

 

Hace dieciocho meses, cuando alguien hablaba de poner Copilot en el risk register corporativo, te miraban como si exageraras. Hoy, no puedes presentarte ante el comité de auditoría sin tener Copilot ahí. Es una de esas transiciones que pasaron rápido y silenciosamente.

Voy a contar cómo lo manejo, porque sé que hay otros CISOs leyendo esto que están en la misma encrucijada.

Lo primero: el comité de auditoría no quiere oír “Copilot está bien gestionado porque tenemos sensitivity labels”. El comité quiere oír qué riesgo específico estás controlando, cómo lo mides, cómo lo monitoreas, quién es accountable, qué evidencia tienes.

Mi entry en el risk register de Copilot tiene seis ítems separados. Lo aprendí a fuerza de iteraciones.

Riesgo 1 — Filtración de datos por respuestas inapropiadas

Causa: oversharing de permisos más grounding amplio. Control primario: SAM más Purview DLP más sensitivity labels. KRI: porcentaje de prompts bloqueados por DLP por mes, tendencia. Evidencia: dashboard de Purview con histórico.

Riesgo 2 — Prompt injection y exfiltración asistida

Causa: contenido externo procesado por el modelo. Control: Prompt Shields más Spotlighting más URL allowlist más confirmación de acciones con efecto lateral. KRI: número de incidents de Prompt Shield triage por mes, severidades. Evidencia: tickets de SOC.

Riesgo 3 — Identidades de agente sin governance

Causa: agentes desplegados sin sponsor o sin scope claro. Control: Entra Agent ID más sponsor tasks más access reviews. KRI: porcentaje de agentes registrados sobre total detectado, agentes huérfanos. Evidencia: reporte trimestral de Entra Agent ID más Agent 365.

Riesgo 4 — Shadow AI en endpoints

Causa: agentes locales no inventariados. Control: Defender más Intune discovery más política de allowlist. KRI: número de agentes detectados fuera de lista, evolución mensual. Evidencia: dashboard de Defender.

Riesgo 5 — Dependencia de proveedor y continuidad

Causa: dependencia crítica de Microsoft 365 más servicios de IA. Control: planes de continuidad, BCP/DR del proveedor revisado, alternativas evaluadas. KRI: SLA cumplido, incidents reportados por Microsoft. Evidencia: reportes contractuales.

Riesgo 6 — Cumplimiento regulatorio

Causa: requisitos cambiantes (EU AI Act, regulaciones locales). Control: legal más compliance reviews trimestrales, in-country processing donde aplique. KRI: gaps identificados en último review. Evidencia: actas de los reviews.

Cada riesgo tiene dueño nombrado. Cada control tiene evidencia. Cada KRI tiene umbrales.

Lo que aprendí presentando esto

El comité no premia complejidad. Premia claridad. Mi primera presentación tenía 20 ítems. Bajó a 6. Cada uno entendible en 30 segundos. Si tu entry no se lee en 30 segundos, no se lee.

El comité quiere ver evolución. Una foto del riesgo hoy es menos útil que la tendencia. ¿Estamos mejor o peor que hace 6 meses? ¿Por qué? Esa narrativa es lo que te da credibilidad o te la quita.

El comité quiere oír qué pasaría si fallara el control. No solo “tenemos control X”. También “si X falla, qué tenemos”. Defensa en profundidad explicada con palabras, no jerga.

 

 

Lo que más me costó

Convencer a operación de que cada control necesita evidencia documentada. “Lo hacemos pero no lo escribimos en ningún lado”. Ese es el peor estado posible. La evidencia que no existe, en una auditoría, es un control que no existe. Tomó meses cambiar el hábito.

Convencer a finanzas de que el budget de seguridad de Copilot no es opcional ni puntual. Es operativo, recurrente. Si quieres mantener los controles, financia la operación, no solo el setup.

Convencer al equipo de IA de que governance no es enemigo de innovación. Es lo que le permite a innovación durar. Esto fue cultural y tomó un año entero.

 

Mi consejo

No copies mi lista. Tu contexto es distinto. Pero usa la estructura: causa, control, KRI, evidencia, dueño. Eso es transversal.

Empieza pequeño y honesto. Mejor 3 riesgos bien gestionados que 15 mal documentados. El comité huele el bullshit a kilómetros.

Habla con tu auditor antes de la primera presentación. Pregúntale qué quiere ver. Te ahorras un trimestre de reescritura.

 

Y la última: este risk register no es estático. Cada quarter cambia. Hace seis meses no tenía la categoría de shadow AI. Hace tres no tenía in-country processing. La velocidad del espacio te obliga a actualizar. Si tu entry de Copilot se ve igual hace un año, probablemente no estás mirando.

Conditional Access con agentes de Security Copilot: lo que cambió de mi configuración

 

Conditional Access en Entra siempre fue donde se decidían los detalles. Quién entra, en qué condiciones, con qué autenticación. Cuando llegó el agente de Conditional Access en Security Copilot, tenía expectativas mixtas. Pasados varios meses con él en producción, voy a contar la experiencia.

Qué hace el agente

Tres cosas principales. Analiza tus políticas de Conditional Access existentes para encontrar contradicciones, redundancias, gaps. Sugiere optimizaciones — consolidar, simplificar, fortalecer. Y, opcionalmente con tu aprobación, las aplica.

Mi tenant tenía 47 políticas de Conditional Access. Acumuladas a lo largo de tres años, con dueños distintos, criterios distintos, niveles de comprensión distintos. El estándar de muchos tenants medianos.

El agente, primer scan: marcó 4 contradicciones, 11 redundancias, 6 gaps. Total 21 hallazgos de los 47 policies.

Los hallazgos

Las contradicciones eran graves. Una política bloqueaba acceso desde geografía X. Otra, más reciente, lo permitía con condición Y. La interacción entre ambas dejaba un escenario donde acceso desde X con Y pasaba sin la fricción que la política original quería. Yo no había detectado esa interacción.

Las redundancias eran ruido. Tres políticas hacían lo mismo con criterios ligeramente distintos. Consolidamos en una con criterios bien definidos.

Los gaps eran lo más útil. Casos donde “esperarías” tener una política y no había. Por ejemplo: ningún policy bloqueaba tokens de OAuth obtenidos desde aplicaciones de tercer país no aprobado. Lo cubrimos.

Lo que el agente hace bien

Volumen de análisis. Yo no tengo el tiempo de revisar 47 policies con detalle cada quarter. El agente sí.

Patrones conocidos. Microsoft ha visto millones de configuraciones. El agente conoce los antipatterns. Los marca.

Sugerencias razonadas. No solo dice “cambia X por Y”. Dice “X tiene problema A, te sugiero Y porque resuelve A sin abrir gap B”.

Lo que el agente no hace bien

Lo específico de tu negocio. El agente no sabe que tu sucursal en X tiene una excepción legítima por razones que no están documentadas. Las sugerencias en esos casos pueden empujar hacia una simplicidad que rompe operación. Hay que filtrar.

Lo político. “Reducir esta política afecta al departamento de Y, que va a quejarse”. El agente no ve esa dinámica. Tú sí.

Cómo lo opero

Reviso al agente quincenalmente. No diariamente — me satura. No mensualmente — me pierdo cosas. Quincenal funciona.

Apruebo cambios solo si los entiendo. La tentación de “auto-aprobar todo lo que sugiera” es real. La resisto. Cada cambio que aprueba, lo entiendo. Si no lo entiendo, no lo apruebo. Eso me ha bajado la velocidad pero subido la confianza.

Roto el dueño de las revisiones. Antes era yo siempre. Ahora roto entre dos personas del equipo. Eso me da double-check humano sobre el agente.

Mi métrica: número de incidents de identidad relacionados con misconfiguration de CA. Bajó 40% el primer trimestre con el agente activo. Suficiente para justificar el costo de SCUs.

 

¿Recomendación? Si tu tenant tiene más de 20 policies de CA, el agente vale la pena. Si tienes menos, probablemente no necesitas la herramienta. La complejidad escala el valor.

ISO 42001 y Copilot: lo que aprendí intentando certificarme

 

Mi organización decidió ir por ISO 42001 en Q3 del año pasado. Estamos en proceso. Voy a contar lo que aprendí intentando alinear nuestro uso de Copilot con el estándar.

ISO 42001 es el primer estándar internacional de Sistema de Gestión de IA. Annex A tiene 38 controles agrupados. La estructura es similar a ISO 27001 pero el enfoque es distinto: gobernar el ciclo de vida de sistemas de IA.

El alcance importa más de lo que parece

Si declaras “todos los sistemas de IA de la empresa” en tu alcance, te metes en un berenjenal. Yo declaré “sistemas de IA con impacto en clientes externos y procesos críticos internos”. Eso me dejó fuera del scope pilotos experimentales y herramientas internas de bajo riesgo. La auditora aceptó.

Copilot 365 es complicado de encajar

Es un sistema de IA, está dentro del alcance de cualquier organización con uso empresarial. Pero el control no es solo tuyo. Es de Microsoft. ¿Cómo justificas controles sobre algo que no controlas tú?

Lo que hice. Documenté el contrato con Microsoft como evidencia primaria de controles compartidos. DPA, EDP, attestations. Cada control de Annex A donde Microsoft es responsable principal, lo apoyé con documentación contractual.

Para los controles donde la responsabilidad es mía (configuración, supervisión, uso adecuado), construí mi documentación. Políticas internas de uso, capacitaciones, monitoreo, incident response.

Para los controles donde es responsabilidad compartida, documenté el split: qué hace Microsoft, qué hago yo, dónde está la frontera. Esto fue lo más laborioso.

El AI System Impact Assessment de cada caso de uso significativo de Copilot. Cada agente custom tiene su AIAS. Plantilla común, contenido específico.

Lo que me sorprendió

Que la auditoría no exigió evidencia técnica profunda de Copilot — Microsoft ya tiene certificaciones que la auditora aceptó como base. Mi trabajo fue probar mi gobierno encima de eso, no replicar la auditoría de Microsoft.

Que la madurez del programa importa más que la cantidad de documentos. La auditora preguntó cómo decido aprobar un nuevo caso de uso de Copilot. Le mostré el comité, las plantillas, las decisiones recientes con sus rationales. Eso convenció más que mil páginas estáticas.

Lo que está mal en muchos programas que vi después

Sobredocumentación. Mil páginas de políticas que nadie ha leído. Nadie aprueba un programa con políticas estáticas que no se aplican.

Subimplementación. Mucha política, poca evidencia operativa. La política dice “revisamos riesgos trimestralmente” pero no hay actas trimestrales. La auditora lo huele.

Si te pones a esto: empieza por el alcance honesto, después los AIAs de tus casos de uso principales, después la política. La política sin casos no protege a nadie.

Cómo le explico Copilot al board sin tecnicismos

 

Esta es de las cosas que más he refinado el último año. Presentar Copilot al board, sin que se duerman ni se asusten. Cuesta más de lo que parece.

El error clásico, que cometí mis primeras dos veces: empezar por la tecnología. “Copilot es un sistema basado en LLMs que…”. Tres minutos después, el chair está mirando su teléfono. Cinco minutos después, el CFO pregunta qué tiene que ver esto con el budget.

El acercamiento que sí funciona: empezar por el riesgo de negocio.

Estructura que uso

Diapositiva 1. “Copilot está siendo usado por X% de nuestros empleados. En el último Q realizó N millones de operaciones”. Foto del estado, sin opinión. Datos.

Diapositiva 2. “El uso productivo está acelerando estos workflows: A, B, C. Estimamos un valor anualizado de Y”. Beneficio, en términos que el board entiende. Ahorro de tiempo, ingreso accelerado, costo evitado.

Diapositiva 3. “Los riesgos que estamos gestionando son tres: filtración de datos, decisiones automáticas mal supervisadas, dependencia operativa de proveedor”. Tres, no quince. Cada uno con un control primario y un KRI.

Diapositiva 4. “Estos controles tienen este performance en los últimos 6 meses”. Tendencia, con verde/amarillo/rojo. Sin números detallados.

Diapositiva 5. “Lo que vamos a hacer en los próximos 6 meses”. Tres iniciativas, con dueños y fechas.

Diapositiva 6. “Pregunta y respuesta”. Espacio para el board.

Total: 6 diapositivas. 12 minutos. Quedan 18 para Q&A.

Las preguntas reales del board

El board pregunta por dependencia. “¿Qué pasa si Microsoft tiene un outage de cuatro días?”. Es una pregunta legítima y hay que tener respuesta. La mía: BCP documentado, alternativas evaluadas, procesos críticos no enteramente dependientes de Copilot. El board duerme tranquilo si la respuesta es honesta.

El board pregunta por decisiones automáticas. “¿Tomamos decisiones que afectan a clientes con IA?”. La respuesta debe ser clara: dónde sí, dónde no, con qué supervisión. No alarmes, no minimices.

El board pregunta por reputación. “¿Qué pasa si Copilot dice algo público que nos dañe?”. Tiene que haber plan: detección, respuesta, comunicación. Un incidente reputacional sin plan es noticia.

Lo que evito decir

Jerga. “Prompt injection” no es palabra para el board. “Manipulación maliciosa de instrucciones a la IA” sí.

Falsa certeza. “Estamos completamente protegidos” miente. “Tenemos defensa en profundidad y los riesgos identificados están bajo control compensatorio” es honesto.

Detalles técnicos que no pidieron. Si me piden detalle técnico, lo doy. Pero no lo regalo sin pedir.

¿Funciona? La medida que uso: ¿el board hace mejores preguntas la siguiente vez? Si sí, está funcionando. Si la pregunta es la misma de hace seis meses, no entendieron. Hay que cambiar la presentación.

Mi métrica favorita: las preguntas del board sobre Copilot pasaron de “¿qué es esto?” hace 18 meses a “¿cómo evolucionamos nuestra postura ante el EU AI Act?” en la última. Esa es la curva de madurez del board, y es lo que más vale el ejercicio.

AI Security Posture Management: el secure score que necesitabas

 

Tenía claro hace un año que Defender for Cloud iba a evolucionar a cubrir cargas de IA. Lo que no esperaba era lo bien que iba a integrarse el AI-SPM (AI Security Posture Management) cuando llegara.

Antes de AI-SPM, gobernar la postura de IA en una organización mediana era un trabajo de patchwork. Tenía que sumar señales de Azure OpenAI (qué deployments, con qué configs, con qué key management), Copilot Studio (qué agentes, con qué connectors), Foundry (qué modelos custom, con qué evaluaciones), agentes locales (qué corre, con qué permisos) y frameworks custom (lo que tu equipo de dev haya montado). Cada uno con su consola, su lógica, su nomenclatura. Cinco fuentes, cinco hojas de Excel, una visión turbia.

AI-SPM lo unifica. Un dashboard. Un secure score. Una vista por workload de IA con severidades, recomendaciones, owners.

 

Lo que más me ayudó al activarlo

La visualización de dependencias. AI-SPM dibuja qué workloads de IA dependen de qué identidades, qué datos, qué APIs externas. Cuando vi por primera vez el grafo, encontré dos workloads que dependían de una API externa que el equipo había puesto sin pasar por el proceso de aprobación de proveedores. Conversación incómoda con el dev, pero corregido en la semana.

La detección de configuraciones débiles. Modelos sin rate limiting, deployments con keys que llevaban meses sin rotar, conectores con permisos sobredimensionados. El secure score no es solo número — es una lista accionable de cosas que arreglar.

La integración con incidents en Defender XDR. Cuando un ataque toca la superficie de un workload de IA, ya no es solo “alerta del modelo” en una consola y “alerta de identidad” en otra. Es un incidente único correlacionado.

 

Lo que me sorprendió en mal

El cobertura todavía es desigual entre workloads. Azure OpenAI lo cubre bien. Copilot Studio aceptable. Frameworks custom — depende mucho de cómo los hayas instrumentado. Si no instrumentas, AI-SPM no ve. Esto es razonable técnicamente, pero genera ilusión de cobertura cuando el dashboard se ve “verde”. Verde en lo que ve. No verde en lo que no ve.

Los benchmarks de “secure score” son a veces optimistas. Un workload con score 85% puede tener gaps que importan en tu contexto pero que no se ven en el score. El score es punto de partida, no la métrica final.

La latencia de los signals: algunos hits tardan minutos en aparecer en el dashboard. Para detección casi tiempo-real, todavía hay que ir a Defender XDR directo.

Mi rutina con AI-SPM

Semanalmente: review del secure score y de los hallazgos abiertos. Asignación a dueños. Tracking de cierre.

Al onboarding de un workload de IA nuevo: chequeo previo de cobertura. Si no aparece en AI-SPM, lo instrumento antes de promover. La instrumentación a posteriori siempre se queda a medias.

Trimestralmente: presentación al board. AI-SPM da las gráficas que necesito. Score por workload, evolución temporal, top 5 hallazgos críticos. Antes preparar esto era media semana de trabajo. Ahora son veinte minutos.

 

 

 

Para quién es

Si tienes 10 o más workloads de IA distribuidos, AI-SPM cambia tu vida. Si tienes 2 o 3, probablemente con dashboards de Azure OpenAI normales te bastaba. La inversión en gobernanza unificada se justifica con escala.

¿Sustituye al programa de seguridad? No. Es la consola, no el programa. Las decisiones, los procesos, las personas — eso no lo da AI-SPM. Lo que da es la vista para tomar mejores decisiones.

Mi métrica favorita después de seis meses con AI-SPM activo: tiempo medio entre el deploy de un workload nuevo y la primera revisión de seguridad sobre él. Bajó de 23 días a 4. Eso es lo que me dice que la herramienta vale.

Security Copilot incluido en E5: ¿regalo o cambio de modelo?

 

Cuando Microsoft anunció en Ignite 2025 que Security Copilot venía incluido para clientes de Microsoft 365 E5, mi primera reacción fue cinismo. La segunda, después de hacer cuentas, fue otra cosa.

La cínica primero. Microsoft estaba teniendo dificultades para vender Security Copilot como SKU separado. El precio por unidad de capacidad era alto, los pilotos tardaban en convertir, los CISOs miraban los números y dudaban. Incluirlo en E5 baja la barrera de entrada a cero — ya pagaste, úsalo.

Hasta ahí, marketing clásico.

Lo que cambia mi opinión es lo que viene con eso.

Security Copilot incluido no es la versión completa. Es un derecho de uso con un cupo de SCUs (Security Compute Units) razonable para casos de uso medianos. Si tu SOC corre operaciones grandes, te quedas corto rápido y vuelves al modelo de pago. Pero para muchas organizaciones — especialmente las que aún no tenían Security Copilot — el cupo incluido alcanza para empezar.

Y empezar es lo importante. Microsoft está apostando a que, una vez que pruebes los Security Copilot agents en Defender, Entra, Intune y Purview, no quieras volver atrás. Los agentes nuevos — los doce que anunciaron — atacan dolores reales del SOC.

Los que más he probado

El agente de phishing triage en Defender. Antes tenías a un analista de tier 1 dedicado a clasificar correos reportados. Ahora el agente preclasifica, y el analista mira los casos no triviales. En el equipo donde lo metí, el tiempo medio de resolución bajó del orden del 60%. No es magia. El agente comete errores. Pero la mayoría de su trabajo es bueno y los humanos pueden enfocarse arriba.

El agente de optimización de Conditional Access en Entra. Mira tus políticas, encuentra duplicaciones, sugiere consolidaciones. La primera vez que lo corrí en mi tenant, identificó cuatro políticas que se contradecían entre sí. Llevábamos meses con esa contradicción y nadie la había visto.

Si no tienes E5 todavía

Esta es la conversación interesante. Antes de Ignite 2025, justificar el upgrade a E5 era difícil para muchas empresas — el delta de funcionalidades sobre E3 más addons no siempre era claro. Con Security Copilot incluido, el balance cambia. Es una pieza más en la columna del “vale la pena”.

Mi cálculo aproximado para una empresa de 1,000 empleados: el ahorro en SCUs gratuitas más el valor de los agentes en SOC, si los usas, suele cubrir el delta de E5 contra E3. No siempre. Depende de tu uso. Pero ya no es claramente negativo, como sí lo era antes.

Si ya tienes E5 pero no habías tocado Security Copilot

Empezar con un piloto enfocado, no con toda la suite. Mi recomendación: arranca con dos agentes, no con doce. Phishing triage en Defender más uno relevante para tu mayor dolor (Conditional Access en Entra, Identity Risk en Entra, o el que sea). Mide. Después expande.

No prendas todos los agentes de un golpe. Te van a saturar con alertas y configuraciones. Y tu cupo de SCUs se gasta más rápido de lo que te imaginas si dejas todo corriendo.

Lo que no me gusta del cambio

Que Microsoft no fue claro sobre el cupo exacto incluido al principio. Costó leer la letra chica. Hoy está mejor documentado, pero al inicio había confusión sobre qué era “incluido” y qué era “consumido” en SCUs.

Que el reporting unificado de uso entre los distintos agentes todavía no es perfecto. Cuando llega final de mes, ver quién consumió qué requiere paciencia.

Que el modelo crea dependencia. Una vez que el SOC se acostumbra a tener agentes ayudando, sacarlos es doloroso. Microsoft sabe esto. Apuesta a que tu uso crezca y termines pagando SCUs adicionales. Es un negocio bien diseñado.

¿Recomendación final? Si tienes E5 y no has tocado Security Copilot, pruébalo este mes. No mañana. La curva de aprendizaje del equipo es lo más caro, y cuanto antes empieces, antes capitalizas.

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.