Aunque la página «Novedades» de Microsoft Entra todavía no se ha actualizado con una sección de julio de 2026, el blog de Microsoft Entra en Tech Community ha estado activo con tres anuncios importantes este mes. Cada uno aborda una faceta distinta del panorama moderno de identidad y seguridad: la gobernanza de agentes de IA, el control del acceso privilegiado y la protección de datos en la era de la IA.
Esto es lo que se ha lanzado, por qué importa y qué debería hacer tu organización al respecto.
1. Gobernar las identidades de agentes de IA con Entra Agent ID
Publicado: 7 de julio de 2026 Estado: Disponibilidad general (plataforma Agent ID) con mejoras de gobernanza progresivas
Microsoft Entra Agent ID, que alcanzó la disponibilidad general en abril de 2026, es la plataforma de identidad y acceso de Microsoft para agentes de IA. La entrada de julio de chiragdayani se centra en un tema que se está volviendo central para la seguridad empresarial: tratar a los agentes de IA con el mismo rigor de gobernanza de identidades que a los empleados humanos.
El problema que resuelve
Los agentes de IA proliferan en los entornos empresariales a un ritmo sin precedentes. Creados en plataformas como Microsoft Copilot Studio, Azure AI Foundry y Security Copilot, por no hablar de soluciones de terceros y personalizadas, estos agentes pueden acceder a datos, llamar a API y realizar acciones en nombre de los usuarios. Sin controles de identidad coherentes, se convierten en «IA en la sombra» (shadow AI): operan sin supervisión, sin rendición de cuentas y sin posibilidad de auditoría.
Capacidades clave
Agent Registry proporciona un directorio unificado y extensible de todas las identidades de agentes de tu inquilino (tenant). Obtienes un inventario completo de tu flota de agentes, visible en el centro de administración de Entra e integrado con el centro de administración de Microsoft 365.
Agent Identity Blueprints son plantillas reutilizables que definen permisos, roles y políticas de gobernanza para clases de agentes. Apruebas un blueprint una vez y todos los agentes creados a partir de él heredan esa configuración. Si algo sale mal, deshabilitar el blueprint desactiva al instante todos los agentes asociados, una capacidad de contención crítica.
Lifecycle Management garantiza que las identidades de agentes tengan siempre un patrocinador humano delegado que responda de su acceso y su ciclo de vida. Cuando un patrocinador deja la organización, el patrocinio se transfiere automáticamente a su responsable mediante Lifecycle Workflows. Los copatrocinadores y los responsables reciben notificaciones, lo que reduce la carga de supervisión manual.
Conditional Access para agentes extiende las protecciones de Zero Trust a las cuentas de usuario de agentes. Los administradores pueden dirigirse a los agentes con Custom Security Attributes, aplicar políticas basadas en Agent Risk, exigir dispositivos conformes (incluido Windows 365 for Agents) e imponer condiciones de plataforma de dispositivo y de red.
Access Governance mediante Entitlement Management proporciona paquetes de acceso que garantizan que el acceso de los agentes sea intencionado, auditable y limitado en el tiempo: el mismo modelo de gobernanza que se usa para las identidades humanas.
Por qué importa
El mensaje es sencillo: los agentes de IA de tu entorno necesitan la misma disciplina de identidad que tu plantilla humana. Agent ID lo hace posible con las herramientas que tu equipo de identidad ya conoce: Conditional Access, gobernanza de identidades, lifecycle workflows y PIM. Si ya gestionas identidades en Entra, tienes las habilidades para gestionar agentes.
Primeros pasos
- Ve a Agent ID en el centro de administración de Entra (debajo de Usuarios, Grupos y Dispositivos en la navegación izquierda)
- Revisa el inventario de agentes de tu tenant
- Define blueprints de identidad de agentes para los tipos de agentes habituales
- Configura políticas de Conditional Access dirigidas a identidades de agentes
- Configura Lifecycle Workflows para la gestión de patrocinadores
2. Extensiones personalizadas de PIM: lógica de negocio en los flujos de activación de roles
Publicado: 1 de julio de 2026 Autora: Kaitlin Murphy Estado: Versión preliminar pública
Privileged Identity Management (PIM) en Microsoft Entra ID ahora admite extensiones personalizadas (custom extensions), una capacidad que permite a las organizaciones integrar lógica de negocio externa directamente en los flujos de activación de roles. Es una de esas funciones que los equipos de seguridad y de TI venían pidiendo desde que se presentó PIM.
El problema que resuelve
Las decisiones de acceso privilegiado suelen depender de un contexto que está fuera de PIM. Un ticket de cambio tiene que ser válido. El estado de RR. HH. de un empleado tiene que estar activo. El usuario tiene que figurar en el calendario de guardias. Las comprobaciones de cumplimiento tienen que superarse. Antes, estas comprobaciones se hacían manualmente, si es que se hacían, lo que creaba brechas que los atacantes podían aprovechar y hallazgos de auditoría difíciles de resolver.
Cómo funciona
Con las extensiones personalizadas, PIM llama a la API REST de tu organización durante el proceso de activación del rol:
- El usuario solicita la activación del rol en PIM
- PIM envía una solicitud estructurada a la API de tu extensión personalizada, que incluye principalId, roleDefinitionId, justification, ticketInfo y scheduleInfo
- Tu API evalúa las reglas de negocio: valida el ticket de cambio, comprueba el estado en RR. HH., verifica los calendarios de guardia y ejecuta comprobaciones de cumplimiento
- Tu API devuelve una decisión (Approved, AutoApproved o Denied) junto con un motivo
- PIM aplica la decisión automáticamente y registra toda la interacción para auditoría
La extensión se invoca de forma síncrona durante el flujo de activación (fase de preaprobación), lo que significa que las decisiones se toman en tiempo real y sin retrasos.
Ámbito admitido
En esta versión preliminar, las extensiones personalizadas admiten:
- PIM para grupos
- PIM para roles de Microsoft Entra
- PIM para recursos de Azure
Pasos de configuración
- Crea una API de extensión personalizada: una API REST (HTTP POST) que implemente tu lógica de negocio
- Protege la API con Microsoft Entra ID: registra una aplicación e implementa la validación de tokens
- Incorpora la extensión en PIM: usa la API de Microsoft Graph para crear el objeto de extensión personalizada
- Vincula la extensión a la configuración del rol: habilita «Require pre-approval custom extension» en la configuración de roles de PIM
- Activa y valida: prueba el flujo de extremo a extremo activando un rol
Por qué importa
Esta función cierra la brecha entre los controles basados en identidad de PIM y el contexto de negocio que determina si se debe conceder el acceso privilegiado. Para las organizaciones con procesos ITSM maduros (ServiceNow, Jira, etc.), esto significa que las activaciones de PIM ya pueden validarse en tiempo real contra los sistemas de gestión de cambios.
Para los auditores, el valor está claro: en lugar de ver «el usuario X activó el rol Y», los registros de auditoría muestran «el usuario X activó el rol Y en las condiciones de negocio Z, validado contra el ticket T, con la aprobación del responsable M». Cada interacción incluye un evaluationId, un evaluationOutcome y un motivo para una trazabilidad de extremo a extremo.
Licencias
- Microsoft Entra ID Premium P2 (necesario para PIM)
- Power Automate o Azure Logic Apps para la integración de flujos de trabajo
- Licencias del sistema ITSM para las integraciones externas
3. Proteger los datos confidenciales en movimiento con Purview y Entra
Publicado: 1 de julio de 2026 Autor: SuleTatar Estado: Versión preliminar pública
Microsoft anunció la versión preliminar pública de la seguridad de datos en la capa de red, impulsada por la integración de Microsoft Purview y Microsoft Entra. Esto extiende la detección de datos y la aplicación de controles basada en la identidad a la capa de red, lo que ayuda a proteger los datos confidenciales en tiempo real mientras se mueven entre aplicaciones SaaS y plataformas de IA.
El problema que resuelve
Los datos ya no se quedan quietos. Se mueven por sesiones de navegador, aplicaciones SaaS, prompts de IA generativa y repositorios en la nube, a menudo fuera de la visibilidad de los controles tradicionales de endpoint y de datos en reposo. Los empleados pegan datos confidenciales en herramientas de IA de consumo. Suben archivos confidenciales a almacenamiento en la nube no administrado. Comparten información propietaria a través de aplicaciones SaaS que TI no ha autorizado.
La prevención de pérdida de datos (DLP) tradicional opera en los endpoints y dentro de las aplicaciones administradas. Pero cuando los datos viajan por la red hacia aplicaciones SaaS y de IA no administradas, esos controles no pueden verlos, y mucho menos bloquearlos.
Capacidades clave
La detección en la capa de red identifica cómo se comparten datos confidenciales con:
- Herramientas de IA en la sombra (aplicaciones de IA de consumo no administradas como ChatGPT, Claude, Gemini)
- Aplicaciones SaaS no administradas
- Repositorios personales en la nube
La aplicación en tiempo real bloquea o limita la exposición de datos en función de tres dimensiones:
- Confidencialidad de los datos: las etiquetas de confidencialidad y las políticas DLP de Purview clasifican los datos
- Identidad del usuario: el contexto de identidad de Entra determina quién accede a qué
- Comportamiento del usuario: las señales de Insider Risk Management siguen cómo interactúan los usuarios con los datos confidenciales a lo largo del tiempo
La investigación unificada correlaciona señales de:
- Microsoft Purview (clasificación de datos, DLP, riesgo interno)
- Microsoft Entra (identidad, acceso, Conditional Access)
- Microsoft Defender (detección de amenazas, investigación, respuesta)
Las áreas de cobertura incluyen sesiones de navegador, uso de aplicaciones SaaS, interacciones con IA (incluidos prompts y respuestas) y datos en movimiento por la red.
Cómo funciona
La integración combina:
- Microsoft Purview: clasificación de datos, políticas DLP y detección de riesgo interno
- Microsoft Entra: aplicación de controles basada en la identidad en la capa de red mediante Global Secure Access (GSA)
- Microsoft Defender: correlación e investigación de amenazas
Cuando un usuario intenta compartir datos confidenciales con una aplicación SaaS o de IA no administrada, el sistema evalúa la solicitud frente a las políticas DLP, las etiquetas de confidencialidad, el contexto de identidad del usuario y las señales de comportamiento. Si los datos están clasificados como confidenciales y el destino es de riesgo, la solicitud puede bloquearse o registrarse con todo el contexto.
Por qué importa
Esta es la respuesta de Microsoft a uno de los retos de seguridad más acuciantes de la era de la IA: ¿cómo permites que los empleados usen herramientas de IA de forma productiva y, al mismo tiempo, evitas que se filtren datos confidenciales a través de prompts y subidas de archivos?
El enfoque es relevante porque sigue a los datos en lugar de bloquear aplicaciones concretas. En vez de mantener una lista de bloqueo cada vez más larga de herramientas de IA (que cambia a diario), el sistema evalúa en tiempo real la confidencialidad de los datos y el contexto del usuario. Si los datos son confidenciales, se bloquean sea cual sea el destino. Si no lo son, el usuario puede trabajar sin fricción.
Licencias
- Microsoft 365 E7: incluye las capacidades de seguridad de datos en red
- Alternativa: licencias de Microsoft Purview ME5 (o equivalente) Y de Microsoft Entra Internet Access (o equivalente)
- Microsoft Purview Information Protection / DLP para la clasificación de datos
- Microsoft Entra ID Premium P1 para Conditional Access
También conviene destacar: hitos de aplicación de julio de 2026
Varios cambios anunciados previamente alcanzaron hitos de aplicación en julio de 2026:
Campaña de registro de SSPR (6 de julio de 2026)
Microsoft lanzó automáticamente una campaña de registro que pide a los administradores y usuarios finales afectados que registren métodos de autenticación antes de la fecha de aplicación del 7 de septiembre de 2026. A partir del 7 de septiembre, el autoservicio de restablecimiento de contraseña (SSPR) solo aceptará métodos de autenticación registrados explícitamente: los números de teléfono y las direcciones de correo electrónico procedentes del directorio que nunca se registraron formalmente dejarán de aceptarse.
Acción necesaria: asegúrate de que los usuarios tengan al menos un método de autenticación registrado antes del 7 de septiembre para evitar interrupciones.
Conditional Access durante el registro de credenciales (6-13 de julio de 2026)
Las políticas de Conditional Access de Entra ID con ámbito en la acción de usuario «Registrar información de seguridad» ahora se evalúan durante el registro de credenciales de Windows Hello for Business y macOS Platform SSO. Así, las políticas de registro se aplican de forma coherente en todos los flujos de registro. Los usuarios deben cumplir los controles de la política (MFA, restricciones de red, cumplimiento del dispositivo) antes de completar el registro.
Acción necesaria: si tienes políticas de CA dirigidas al registro de información de seguridad, pruébalas en modo de solo informe para verificar que funcionan como esperas en todos los flujos de registro.
Los valores predeterminados de seguridad bloquean el flujo de código de dispositivo (1 de julio de 2026)
Todos los nuevos tenants de Microsoft Entra bloquean ahora el flujo de código de dispositivo (device code flow) como parte de los valores predeterminados de seguridad. Es una medida de refuerzo de la seguridad: el flujo de código de dispositivo es un objetivo habitual de los ataques de phishing.
Acción necesaria: si tienes aplicaciones o dispositivos que dependen del flujo de código de dispositivo, tendrás que migrarlos a un método de autenticación más seguro o configurar Conditional Access para permitir explícitamente el flujo de código de dispositivo donde sea necesario.
Cambios de precios de Entra ID (1 de julio de 2026)
Los precios comerciales de los SKU de Microsoft 365 se ajustaron con efecto a partir del 1 de julio de 2026. Entra ID P1 subió de $6.00 a $7.00 por usuario y mes. Forma parte de una actualización más amplia de los precios comerciales de toda la cartera de Microsoft 365, que coincide con la incorporación de nuevas capacidades de IA (incluido Copilot) a muchos SKU.
El panorama general: proteger la era de la IA
Estos anuncios de julio de 2026 reflejan una dirección estratégica clara de Microsoft: los controles de identidad, acceso y protección de datos que las organizaciones han creado para las identidades humanas y las aplicaciones administradas deben extenderse a los agentes de IA, al SaaS no administrado y a los flujos de datos en la capa de red.
La gobernanza de Agent ID responde a la pregunta: «¿Cómo controlamos los agentes de IA de nuestro entorno?» Las extensiones personalizadas de PIM responden: «¿Cómo aplicamos el contexto de negocio al acceso privilegiado?» La protección de red de Purview + Entra responde: «¿Cómo evitamos que se filtren datos confidenciales a través de la IA y el SaaS?»
En conjunto, forman un modelo de seguridad más completo para la era de la IA agéntica, en el que la identidad, el acceso y la protección de datos están unificados en lugar de fragmentados entre distintas herramientas y equipos.
Microsoft también organiza una serie de seminarios web en tres partes a partir del 21 de julio de 2026, «Securing Data and Access in the Era of AI», que trata estos temas en profundidad. La sesión del 23 de julio aborda específicamente la seguridad de los agentes de IA, incluidos los agentes locales desarrollados con herramientas como GitHub Copilot CLI, Claude Code y OpenAI Codex.
Qué deberías hacer ahora
Audita tu inventario de agentes de IA: revisa la sección Agent ID del centro de administración de Entra para ver qué agentes hay ya en tu tenant. Puede que te sorprenda.
Evalúa las extensiones personalizadas de PIM: si tienes un sistema ITSM (ServiceNow, Jira, etc.), merece la pena probar esta versión preliminar. Empieza con un rol que no sea de producción para validar la integración.
Revisa tu estrategia de DLP: si la protección de datos confidenciales es una prioridad (y debería serlo), evalúa la integración en la capa de red de Purview + Entra. La versión preliminar ya está disponible.
Prepárate para la aplicación de SSPR: la fecha límite del 7 de septiembre de 2026 es firme. Genera un informe de los métodos de autenticación registrados y dirígete a los usuarios que aún no se han registrado.
Actualiza tu documentación de seguridad: estos cambios suponen cambios importantes en el funcionamiento de la identidad y la protección de datos en la nube de Microsoft. Asegúrate de que la documentación de tu equipo los refleje.
Kevin Kaminski es el propietario de Big Hat Group Inc., un partner de Microsoft centrado en tecnologías de IA y de nube. Síguelo en https://x.com/kkaminsk para conocer más novedades sobre Microsoft Entra.