El paisaje del phishing en Q1 2026: AI contra AI

 Microsoft publicó su reporte de Q1 2026 sobre el threat landscape de email a finales de abril. Lo recomiendo leer entero, pero voy a contar lo que más me marcó.

Los volúmenes de phishing siguen subiendo. Eso era predecible. Lo nuevo es la calidad. Microsoft reporta crecimiento sustancial en correos generados con LLMs. La gramática perfecta, el tono profesional, la personalización por información pública del target — todo lo que antes era pista para detectar phishing, hoy es nivel base.

El problema con eso: los entrenamientos de awareness de hace tres años están obsoletos. “Busca errores ortográficos” ya no es señal. El correo phishing de hoy no tiene errores. “Busca tono extraño” ya no es señal. El correo phishing está bien escrito.

Lo que sí sigue funcionando como señal

Análisis de origen. Headers, dominios sutilmente alterados, infraestructura de envío. Defender for Office hace este trabajo bien. La pieza humana se reduce a “verifica antes de actuar en cosas inusuales”.

Análisis de contexto. ¿El CEO realmente te pide a ti, en este formato, en este momento, por este canal? Si rompe patrón, sospecha. La regla “si rompe patrón, valida por canal alterno” sigue válida.

Análisis de intent. Defender XDR ahora marca correos por intent — financial fraud attempt, credential theft, etc. La clasificación por intent es más útil que por superficie.

Lo que cambió en mi operación

Bajé las expectativas de que el usuario detecte el phishing. La línea de defensa principal ya no es “el usuario que duda”. Es la pila de detección automatizada: anti-spoofing, sandboxing, intent analysis, link rewriting con análisis dinámico. Si llega al inbox un phishing decente, asumo que un porcentaje de usuarios va a caer.

Subí la inversión en respuesta rápida post-click. Cuando un usuario hace click en un link malicioso, ¿qué pasa? La velocidad entre click y contención es lo que marca la diferencia. Defender XDR más Security Copilot reduce esto.

Capacitación distinta. Ya no enseño a “detectar phishing por errores”. Enseño a “validar por canal alterno cualquier solicitud financiera o de credenciales no esperada”. Es regla simple. La gente la sigue.

Para dónde va esto

La carrera entre phishing generado por IA y detección por IA va a definir el panorama de email security los próximos años. Es asimétrica — el atacante necesita pasar uno, el defensor necesita parar todos. Pero las herramientas defensivas están mejorando rápido también.

Mi predicción: en 2027 el email puro como vector va a perder relevancia frente a vectores multi-canal (email más SMS más voz, con IA orquestando los tres). La defensa va a tener que cubrir el customer journey completo, no solo el inbox.

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.

Identity Risk Scoring en Defender XDR para identidades de agentes

 

Defender XDR estrenó en abril identity risk scoring extendido a identidades de agentes. Antes el risk scoring se aplicaba solo a humanos. Lo de los agentes era un patch. Ahora es ciudadano de primera clase del modelo.

Voy a explicar qué cambia.

El risk scoring funciona como en humanos. Defender mira señales: ubicación geográfica anormal, accesos fuera de horario, acciones desviadas del patrón histórico, conexiones a destinos sospechosos. Combina señales en un score. Te alerta cuando un agente se comporta raro.

Diferencias con humanos

Los patrones son distintos. Un humano tiene ritmos circadianos. Un agente puede estar activo 24/7. La ausencia de ritmo circadiano no es señal sospechosa para un agente. Defender lo aprende.

La velocidad es distinta. Un agente puede legítimamente hacer 1000 acciones por minuto. La señal “muchas acciones rápidas” no aplica igual. Lo que sí aplica: cambio brusco respecto a la baseline del propio agente.

El contexto es distinto. Un humano tiene “manager”, “departamento”, “rol”. Un agente tiene “sponsor”, “scope autorizado”, “tipo de tarea”. El risk scoring de Defender ahora incorpora estos atributos en su modelo.

Lo que se ve en mi tenant

Detectó tres anomalías en el primer mes. Una era benigna — un agente cambió de comportamiento porque cambió su tarea, no estaba mal. Dos eran problemáticas — un agente que empezó a tocar datos fuera de su scope (mala configuración después de un update), y otro que empezó a fallar en patrones que sugerían que su modelo subyacente había sido cambiado sin aviso.

Ese segundo caso me marcó. Era un agente custom de Copilot Studio. Alguien del equipo de IA cambió el modelo subyacente sin avisar a seguridad. Defender lo detectó por el cambio en el patrón de respuestas. Me dio visibilidad sobre algo que estaba mal gobernado. Pude presentarle al equipo de IA evidencia técnica de por qué el cambio sin aviso no es OK.

Lo que ajusté en operación

Subí los thresholds para alertas críticas. Por defecto, Defender es ruidoso para agentes nuevos hasta que aprende la baseline. Las primeras dos semanas tuve más alertas que las que mi equipo podía triagear. Microsoft documenta esto, hay que esperar.

Conecté las alertas con tickets automáticos al sponsor del agente. Si un agente de María entra en risk alto, María recibe ticket. La accountability es del sponsor.

Empecé a usar el risk score en políticas de Conditional Access. “Si un agente está en risk alto, requiere re-autenticación de su sponsor humano antes de continuar acciones críticas”. Esto añade fricción a un agente comprometido, sin parar a los buenos.

Lo que me gustaría que mejoraran

Más explicabilidad en las alertas. A veces Defender dice “risk alto” sin explicar qué señales pesaron. Para investigación, necesito saber el por qué.

Integración con Entra Agent ID más profunda. Hoy hay puente, pero algunos atributos del agente no se reflejan en el modelo de risk. Espero que cierren ese gap.

Mi conclusión: risk scoring para identidades de agentes era el control que faltaba. Lo tienes activo, vas mucho más tranquilo. Si tienes agentes en producción y no estás monitoreando con risk scoring, es la pieza que más rápido te baja el riesgo de identidad de agente.

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.

OWASP Top 10 para agentic AI: cómo lo aterrizo en Copilot Studio

 

OWASP sacó el Top 10 para agentic AI en marzo. Microsoft, fiel a su estilo, publicó casi al mismo tiempo cómo se mapea a Copilot Studio. He pasado las últimas semanas intentando hacer que el mapeo le hable a mi equipo.

El Top 10 no es un descubrimiento — la mayoría de las categorías ya las veníamos manejando. Lo valioso es que da nomenclatura común. Cuando hablo con un auditor, con un cliente, con un nuevo miembro del equipo, podemos decir “AAI:01 - Memory Poisoning” y los dos sabemos a qué nos referimos. Antes era cada uno con su jerga.

 

Voy a recorrer rápido cómo lo aterrizo en Copilot Studio. No es una guía exhaustiva, es lo que hago yo.

Recorrido por los 10

AAI:01 Memory Poisoning — el agente acumula contexto, alguien lo contamina, el agente actúa sobre datos envenenados. En Copilot Studio: limito el scope de la memoria del agente, no le doy acceso a memorias persistentes salvo necesidad clara, audito qué entra a la memoria del agente. Si el agente consume documentos compartidos, los pasamos por sensitivity labels y DLP antes de que entren a su corpus.

AAI:02 Tool Misuse — el agente usa una herramienta para algo distinto a su propósito. En Copilot Studio: cada conector con scope mínimo necesario. Si el agente solo necesita leer del CRM, no le des escritura. Si solo en una tabla, no en todas. Esto requiere paciencia con el setup pero paga después.

 

AAI:03 Privilege Compromise — el agente termina con más permisos de los que debería. En Copilot Studio: revisión periódica de permisos del agente. Entra Agent ID más access reviews. Esto es lo que hablé en otro post — meter al agente al ciclo de governance estándar.

AAI:04 Resource Overload — el agente consume tantos recursos que se vuelve indisponible o caro. En Copilot Studio: rate limits, cost caps por agente, monitoring de consumo. Si un agente sube su consumo súbitamente, alerta.

 

AAI:05 Cascading Hallucinations — un agente alucina, otro toma esa salida como verdad, y la cadena de errores crece. En Copilot Studio multi-agente: validación entre nodos, no encadenar agentes sin un punto de verificación. Costoso pero necesario en flujos críticos.

AAI:06 Intent Breaking and Goal Manipulation — esto es prompt injection con vocabulario más fancy. En Copilot Studio: Prompt Shields activo, Spotlighting cuando hay inputs de fuera, system prompts robustos, validation de outputs.

AAI:07 Misaligned and Deceptive Behaviors — el agente hace algo que parece OK pero no es lo que el usuario quería. En Copilot Studio: confirmación explícita de acciones con efecto lateral. Si el agente va a mandar correo, modificar archivo, ejecutar transacción — confirma con el humano. Esto, aunque agrega fricción, es no-negociable.

 

 

AAI:08 Repudiation — el usuario o el agente niega haber hecho una acción y no hay forma de probarlo. En Copilot Studio: logging completo activado en Purview, identidad de agente clara (Entra Agent ID), trazabilidad end-to-end. Auditable es no-negociable.

 

AAI:09 Identity Spoofing and Impersonation — alguien se hace pasar por el agente o el agente se hace pasar por alguien. En Copilot Studio: identidad robusta del agente, autenticación mutua donde aplica, MFA en quien crea o modifica agentes.

 

AAI:10 Overwhelming HITL — el humano en el loop recibe tanto input que deja de validar. En Copilot Studio: diseño de aprobaciones que no satura. Si tu agente genera 1000 acciones al día y todas requieren aprobación humana, la aprobación deja de ser real. Hay que pensar el HITL como recurso escaso.

Cómo lo opero

He empezado a documentar cada agente en una matriz: para cada uno de los 10 ítems, ¿cuál es nuestro control, cuál es la evidencia, quién es el dueño? Cuando el auditor llega — y va a llegar — el documento ya existe. No lo armas la semana antes.

¿Es todo? No. Hay categorías que el Top 10 cubre superficialmente. Por ejemplo, supply chain de modelos: si tu agente usa un modelo custom, ¿cómo lo verificaste? Eso está implícito en varios ítems pero no es categoría propia. Lo cubro aparte.

¿Lo recomendaría como base para tu programa? Sí. Tener el Top 10 como vocabulario y línea base, y construir tu programa por encima, te ahorra inventar la rueda. Que es lo que más tiempo nos hace perder en seguridad: discutir taxonomía cuando deberíamos estar implementando controles.

La pieza que faltaba: DLP de Purview para Copilot

 

Llevaba meses esperando que Microsoft sacara DLP de Purview específicamente para Copilot. En Ignite 2025 anunciaron la GA de la versión que actúa sobre archivos y correos con etiquetas de sensibilidad. En diciembre 2025 entró en preview la versión que actúa sobre prompts. La GA de prompts está prevista para finales de marzo de 2026 — y a la fecha en que escribo, ya está accesible para la mayoría de tenants empresariales.

Voy a contar para qué sirve esto en los términos en que se lo expliqué a mi gerente, que no es técnico pero firma los presupuestos.

Una cosa es proteger los archivos en reposo. Si tienes un PDF con contratos confidenciales, le pones un sensitivity label “Confidencial - Externo Restringido”, y Copilot ya no lo procesa para usuarios fuera del scope autorizado. Esa parte estaba.

Otra cosa, y aquí es donde estábamos cojos, es proteger lo que el usuario teclea en el prompt. Imagínate que el usuario está pidiendo a Copilot que le ayude a redactar un correo y, sin pensar, copia y pega un número de tarjeta de crédito de un cliente. O un número de seguridad social. O un fragmento entero de un contrato bajo NDA. Eso no es un archivo etiquetado. Es texto plano que el usuario metió a la fuerza. Antes de la nueva DLP, ese contenido se procesaba sin más.

Ahora, Purview escanea el prompt en tiempo real buscando Sensitive Information Types (SITs). Hay built-in para datos como SSN, tarjetas, IBANs. Y puedes definir custom — por ejemplo, “código de proyecto interno X-confidential” o el nombre clave de tu producto que no se debe filtrar. Si lo detecta, bloquea la respuesta. Copilot no responde. El usuario ve un mensaje de policy.

Qué tan bien funciona

Razonablemente. He hecho pruebas con tres SITs custom y dos built-in. Falsos positivos: pocos pero existen, sobre todo cuando los SITs custom tienen patrones genéricos. Falsos negativos: encontré un par cuando el usuario partía el dato sensible en dos prompts seguidos. La DLP no correlaciona conversación; mira prompt por prompt. Eso es un gap real.

La latencia agregada es mínima. En mis pruebas, menos de 200ms. No la sienten los usuarios.

 

Mi orden recomendado

Primero, defines el corpus de SITs que tienen sentido para tu negocio. No metas todo lo que se te ocurra — cada SIT activo es coste de inferencia y potencial fricción. Yo arranqué con seis: tarjetas, SSN/CURP local, IBAN, dos nombres de proyecto críticos, y un patrón regex para códigos internos. Suficiente para empezar.

Segundo, lo pones primero en modo audit, no block. Una semana en audit te dice si tu corpus es razonable. Si en una semana se dispararían 5,000 bloqueos al día, algo está mal.

Tercero, comunicas a los usuarios antes de cambiar a block. Un correo simple. “A partir del lunes, si pegas datos sensibles en Copilot, no responderá. Aquí los tipos de datos. Si tienes que trabajar con esto, usa este canal alternativo”. Sin esa comunicación, los tickets te entierran.

Cuarto, mides. ¿Cuántos prompts bloqueados por semana? ¿De qué usuarios y áreas? ¿Hay patrones que sugieran necesidad de capacitación? La DLP es solo el dique. La cultura es el río.

Lo que me sigue molestando es que la correlación cross-prompt no existe todavía. Si el usuario es astuto, puede partir un dato sensible y meterlo en pedazos. La DLP de prompts no lo va a pillar. Para eso, necesitas combinar con Insider Risk en Purview. Microsoft sabe que es un gap y dicen que están trabajando.

 

Para mí, esta es la pieza del 2026 que más rápido cambia el riesgo real de Copilot. Si solo puedes hacer una cosa este trimestre, hazla esta.

Por qué a cada agente le tengo que poner nombre y apellido

 

Una de las cosas que me costó más vender internamente este año fue la idea de tratar a cada agente como una identidad de primera clase. La cara del CFO cuando le dije “oye, vamos a tener miles de identidades nuevas, y todas van a costarnos gobernarlas” no fue de las mejores reuniones del trimestre.

Pero es lo que toca.

Microsoft Entra Agent ID, todavía en preview a mayo de 2026, es la pieza estructural. La idea es simple: el agente no es un script anónimo que corre con el token de un humano. El agente tiene su propia identidad, sus propios permisos, su propio dueño accountable, y entra al ciclo de vida de IGA igual que un empleado.

 

Lo que cambia en la práctica

Antes, si el agente “robot-X” hacía algo raro, el log decía “user: maria.gonzalez”. Tenías que preguntarle a María si era ella o su agente. Ahora el log dice “agent: robot-x | sponsor: maria.gonzalez”. Forensia más limpia, accountability sin ambigüedad.

Antes, cuando María se iba de la empresa, el agente seguía corriendo con su identidad heredada hasta que alguien se acordara. Ahora hay sponsor tasks en Lifecycle Workflows: si el sponsor humano sale, hay un workflow que pide reasignar o suspender al agente. No es perfecto — la implementación a veces requiere intervención manual — pero existe el carril.

Antes, no podías hacer access reviews sobre lo que un agente puede ver. Ahora sí. Y aquí va lo importante: la primera vez que corrí un access review sobre un agente de Copilot Studio que llevaba ocho meses corriendo, encontré que tenía acceso a SharePoint sites que ya nadie usaba. Permisos que se habían heredado de la cuenta de servicio que el agente reemplazó. Limpiamos casi 200 permisos huérfanos en una tarde.

 

Lo que no me gusta

Que sigue siendo preview. Quiero esto en GA ya. Las features de governance de identidades de máquina nunca van rápido en el roadmap, y entiendo por qué (es complicado hacerlo bien), pero el problema ya está aquí.

Que la integración con Copilot Studio aún tiene gaps. No todos los agentes legacy se migran solos. Tienes que ir uno por uno reasignando, lo cual con una empresa con cientos de agentes pequeños es trabajo manual.

Que el billing de las identidades de agente no está claro todavía. Microsoft dice que se factura como parte de Agent 365, pero la documentación todavía es ambigua sobre cuándo cuenta como identidad facturable y cuándo no. He visto facturas con sorpresas.

Para empezar

Define la política primero, antes de tocar el portal. ¿Qué agentes requieren sponsor? ¿Cuántos sponsors mínimos necesita un agente crítico, uno o dos? ¿Cómo defines “crítico” para empezar? ¿Qué pasa si el sponsor está de vacaciones, sigue corriendo el agente o se pausa? Sin estas definiciones, te vas a meter en un lío político con managers que se sienten responsables de algo que no entienden.

Inventario antes que governance. Si no sabes cuántos agentes corren ya en tu tenant, el primer ejercicio es contarlos. Yo hice un script básico de exportar todo lo que Copilot Studio reporta y crucé contra lo que Defender ya estaba viendo. Aparecieron varios que no estaban en mi lista. Eso solo ya valió el ejercicio.

Y por último — y esto es opinión personal — no esperes a que GA salga para empezar a pensar en esto. La gobernanza de identidades de agente va a ser el control compensatorio más importante del 2026 y 2027. Si llegas tarde, no hay forma de retro-encajarlo limpiamente.

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.

Shadow AI: los agentes que ya están en tu casa

 

Una mañana hace un par de meses, encendí el dashboard nuevo de Defender que muestra agentes locales detectados en endpoints. Esperaba ver dos o tres.

Vi treinta y siete.

OpenClaw en máquinas de marketing. Claude Code en máquinas de desarrollo. GitHub Copilot CLI en varias laptops de ingeniería. Algún agente custom que ni siquiera pude identificar al primer intento — resultó ser un script con un MCP server montado por alguien del equipo de data science.

Esto es shadow AI. Y a febrero 2026, es probablemente el riesgo más subestimado de las organizaciones medianas y grandes.

Defino shadow AI como cualquier agente o herramienta de IA que opera en endpoints o en la nube de la empresa sin estar registrada, gobernada o auditada por el equipo de seguridad. La parte “sin gobierno” es la importante. No es que sea malicioso — la mayoría no lo es. Es que está fuera del radar.

Por qué importa

Primera razón: estos agentes operan con permisos del usuario que los corre. Si el usuario tiene acceso a tu CRM, el agente local también. Y el agente no sigue las mismas reglas que tú aplicas a Copilot empresarial. No tiene Prompt Shields, no tiene DLP de Purview, no tiene logging unificado. Lo que filtre, ya está filtrado.

Segunda: muchos de estos agentes mandan datos a APIs de terceros. Cada query hecha a un agente local que se conecta a la API de Anthropic, OpenAI, o cualquier otro proveedor, manda contexto fuera. Si ese contexto incluye texto sensible — y casi siempre incluye algo — tienes flujo de datos no inventariado.

Tercera: al ser locales, sobreviven a apagones de servicios cloud y a controles de red. Si tu firewall corporativo bloquea el dominio del proveedor, el agente local que ya tenía credenciales y caché puede operar offline parcialmente. Hay menos puntos de control que con servicios SaaS.

 

 

Lo que está dando Microsoft

Microsoft empezó a atacar esto en serio con Defender más Intune. La capacidad de descubrir agentes locales — empezó con OpenClaw y se expandió a GitHub Copilot CLI y Claude Code — es el primer paso. Te dice qué tienes. Después tú decides qué hacer.

Las opciones

Bloquear todo. Política dura: ningún agente local en endpoints corporativos. Ventaja: simple. Desventaja: matas productividad real, y la gente buscará caminos. Le pasó a una empresa amiga: bloquearon Claude Code, los devs lo siguieron usando desde laptops personales conectadas a recursos de la empresa por VPN. Empeoraron el problema.

Permitir todo. Política blanda: la gente usa lo que quiera. Ventaja: nadie protesta. Desventaja: no sabes qué pasa. No me parece responsable.

Permitir con governance. Lo que yo hago. Lista permitida de agentes locales aprobados (Claude Code y GitHub Copilot CLI están en mi lista hoy). Configuración obligatoria que registra el agente con identidad de Entra Agent ID. Logging activado. Restricciones por destinos web y por tipos de datos.

Esto último es lo que hace posible la combinación de Agent 365 más Defender más Intune. Hace doce meses, ni siquiera tenía la capacidad técnica de hacer governance sobre estos agentes. Ahora sí.

 

 

Lo que aprendí en el camino

No subestimes el número. Vas a encontrar más de lo que esperas. Si tu primer escaneo te encuentra dos, mira mejor — probablemente hay diez.

No subestimes el valor que la gente le saca. Hay quien usa Claude Code seriamente para trabajo crítico. Bloquearlo sin alternativa es romper el flujo de alguien que está aportando. Habla con los usuarios antes de cortarles.

Sí subestima la conciencia que tienen sobre los riesgos. Mucha gente buena, talentosa, técnica, no tiene la menor idea de que su prompt se manda a un servidor externo. Lo da por hecho. Las charlas de awareness siguen siendo importantes.

 

¿Hacia dónde va esto? A mi juicio, hacia un modelo de “AI runtime” empresarial donde los agentes locales son ciudadanos de primera clase pero con governance. Microsoft está apostando a que sea su control plane (Agent 365) el que orquesta. Otros proveedores tienen visiones distintas. La pelea por el control plane de los agentes va a ser una de las grandes en el 2027.

Por ahora, escanea. Inventariа. Decide. No mires hacia otro lado.