Blueprints de agentes en Entra ID: por qué recomendamos desactivarlos ahora

PorSebastian
Configuración de usuario de Entra ID: el registro de aplicaciones está bloqueado, pero la opción para registrar blueprints de agentes sigue en Sí por defecto

Desde el 4 de noviembre de 2026, Microsoft comenzó a habilitar que cualquier usuario de su tenant de Microsoft 365, sin ningún rol administrativo, pueda crear blueprints de agentes en Entra ID: las plantillas de las que nacen las identidades de los agentes de IA. Microsoft lo anunció en el Centro de mensajes (MC1506733, publicado el 13 de octubre de 2026) y espera completar el despliegue mundial a finales de noviembre. Es decir: su tenant puede tenerlo ya activo o recibirlo en los próximos días. Si nadie tocó la configuración, el valor es Sí.

Varios especialistas reconocidos en Entra ID —Rudy Mens en LazyAdmin, Daniel Bradley en Our Cloud Network y el equipo de Office 365 for IT Pros— ya publicaron advertencias sobre este cambio. Coincidimos con su conclusión. En este artículo queremos ir un paso más allá: explicar qué gana realmente un atacante con esta configuración activa, en qué tenants el riesgo es mayor y qué conviene hacer hoy mismo.

Qué es un agent identity blueprint

Microsoft Entra Agent ID es la plataforma de Microsoft para dar a los agentes de IA una identidad propia en el directorio, distinta de la de un usuario o de una aplicación tradicional. Dentro de esa plataforma hay tres piezas que conviene distinguir:

  • Blueprint (agent identity blueprint): según la documentación de Microsoft, es el objeto de Entra ID que funciona como plantilla y base de autenticación de una o más identidades de agente. El blueprint guarda las credenciales y las usa para obtener tokens en nombre de todos los agentes creados a partir de él.
  • Blueprint principal: el objeto que registra la presencia del blueprint en el tenant y le permite obtener tokens y aparecer en los registros de auditoría.
  • Identidad de agente: la identidad con la que cada agente se autentica y accede a recursos. No tiene credenciales propias; depende de las del blueprint.

La analogía más útil para un administrador es la que propone LazyAdmin: un blueprint es, en la práctica, un registro de aplicación diseñado para agentes. Y desde hace años la recomendación de la industria ha sido no permitir que cualquier usuario registre aplicaciones.

Qué cambia exactamente

Microsoft agrega una nueva opción en Entra ID > Usuarios > Configuración de usuario, dentro de Permisos de rol de usuario predeterminados. La documentación oficial y el mensaje MC1506733 la llaman Users can create agent blueprints; en el portal puede aparecer como Users can register agent identity blueprints, justo debajo de “Users can register applications”. Es la misma configuración.

  • Con el valor Sí (predeterminado): cualquier usuario del tenant puede crear un blueprint y su blueprint principal.
  • Con el valor No: solo los administradores y los usuarios con los roles Agent ID Developer o Agent ID Administrator pueden crearlos.
  • Es independiente de “Users can register applications”. Si usted bloqueó el registro de aplicaciones hace años, eso no bloquea los blueprints.
  • No afecta lo que ya existe: los blueprints creados antes del cambio no se modifican ni se eliminan.
  • Si el despliegue aún no llegó a su tenant, el valor que guarde ahora se respeta cuando llegue. Si ya llegó, desactivarlo evita nuevos blueprints, pero no elimina los que se hayan creado desde el 4 de noviembre.

Hay un cambio relacionado, anunciado el mismo día (MC1506728), que juega a favor del administrador: con el mismo calendario de despliegue, Entra dejó de otorgar automáticamente a los blueprint principals el permiso AgentIdentity.CreateAsManager. Los agentes que crean sus propias identidades sin un usuario conectado ahora necesitan que un administrador otorgue ese permiso de forma explícita. Es una buena señal de la dirección que toma Microsoft (permisos visibles y revocables), pero no resuelve el punto de este artículo: quién puede crear blueprints en primer lugar.

Por qué es peligroso (y por qué no es el fin del mundo)

Seamos precisos, porque el tema se presta a exageraciones. Un blueprint, por sí solo, no da acceso a los datos de la empresa. Microsoft lo deja claro: los permisos sobre recursos y el consentimiento son requisitos separados. El problema no es que el blueprint sea una llave maestra; es que abre puertas que muchas organizaciones creían haber cerrado. Estas son las razones concretas.

1. El creador queda como dueño, y desactivar la opción después no se lo quita

Según Microsoft Learn, quien crea un blueprint queda automáticamente como propietario del blueprint y de su blueprint principal. Los propietarios pueden crear identidades de agente a partir de ese blueprint sin tener ningún rol de Agent ID, y la tabla de permisos predeterminados de Entra indica que los usuarios miembros pueden administrar las propiedades, asignaciones y credenciales de los blueprints que poseen.

Esto tiene una consecuencia práctica: si un usuario creó un blueprint el 5 de noviembre y usted desactiva la opción hoy, ese usuario sigue siendo dueño de lo que creó. Restringir tarde no limpia el tenant; solo evita que el problema crezca.

2. Deshace un hardening que muchas organizaciones ya hicieron

Aquí está, a nuestro juicio, el punto que más se ha pasado por alto. Para medir el riesgo real de una configuración hay que preguntarse qué capacidad concreta le da al atacante que no tuviera ya.

Pensemos en el escenario más común: una cuenta de usuario comprometida por phishing o robo de token. Si en su tenant “Users can register applications” sigue en Sí, ese atacante ya podía crear un registro de aplicación con sus propias credenciales; el blueprint le agrega poco. En ese caso el hallazgo de fondo no es el blueprint, sino que el registro de aplicaciones sigue abierto, y conviene corregir ambos.

Pero si su organización ya cerró el registro de aplicaciones —como recomiendan Microsoft y los marcos de referencia más usados—, este cambio reabre por otra puerta exactamente la capacidad que usted quitó: crear en su directorio un objeto no humano, propiedad del atacante, capaz de autenticarse con credenciales que no dependen de la contraseña ni del MFA del usuario comprometido. Restablecer la contraseña de esa cuenta o revocar sus sesiones no elimina un blueprint ni sus credenciales. Por eso el riesgo es mayor, paradójicamente, para quienes ya hicieron la tarea.

3. La configuración de consentimiento decide el impacto real

Lo que un agente puede alcanzar depende de los permisos que se le otorguen, y Microsoft distingue dos tipos:

  • Permisos delegados: el agente actúa en nombre del usuario que inició sesión y nunca llega más lejos que ese usuario. Si el usuario puede otorgarlos él mismo depende de su política de consentimiento.
  • Permisos de aplicación: el agente actúa con su propia identidad, a menudo con alcance de todo el tenant. Estos siempre requieren consentimiento de un administrador.

Para tenants nuevos, Microsoft aplica por defecto una política administrada por Microsoft que permite a los usuarios consentir permisos delegados, excepto una lista de permisos sensibles (lectura de correo, archivos, calendarios, chats, entre otros). Pero si su tenant todavía tiene la opción heredada “Allow user consent for apps”, cualquier usuario puede consentir cualquier permiso que no requiera aprobación administrativa, para cualquier aplicación. En ese escenario, un agente creado por un usuario puede acceder a sus datos sin que ningún administrador intervenga.

4. Gobernar agentes requiere licenciamiento adicional

Crear blueprints y agentes no exige licencias adicionales. Controlarlos, sí. La documentación de Microsoft indica que el Acceso Condicional para agentes requiere Microsoft 365 E7, o bien una licencia Microsoft Agent 365 combinada con al menos Microsoft Entra ID P1 o Microsoft 365 E3. Agent 365 se vende como complemento de planes como E5 o Business Premium. (Explicamos qué incluye en nuestro análisis de Microsoft Agent 365).

Para una organización mediana en Panamá o la región que opera con Business Premium, esto significa que, por defecto, sus usuarios podrán crear agentes que la organización no tiene cómo someter a políticas de Acceso Condicional sin invertir en licenciamiento adicional. La ecuación es incómoda: crear es gratis, gobernar no.

5. Ya hemos visto esta película

En la revisión de aplicaciones empresariales del tenant de un cliente, encontramos que una usuaria había consentido, en algún momento, una herramienta de transferencia masiva de archivos. Nadie en TI lo había aprobado ni sabía que estaba ahí. No hubo mala intención: el tenant simplemente lo permitía. Los blueprints de agentes repiten el mismo patrón con una pieza más poderosa: un objeto con credenciales propias y un dueño que no pertenece al área de TI.

Qué recomendamos hacer hoy

  1. Desactive la opción. En el centro de administración de Microsoft Entra, vaya a Entra ID > Usuarios > Configuración de usuario y, en Permisos de rol de usuario predeterminados, ponga Users can create agent blueprints (o Users can register agent identity blueprints) en No. Guarde. Microsoft documenta como mínimo el rol Cloud Application Administrator, pero al menos un MVP (Topedia) reportó que con ese rol el cambio no funcionó; si el interruptor no responde, hágalo con un Global Administrator. Si no ve la opción, refresque el navegador por completo.
  2. Revise, en la misma pantalla, “Users can register applications”. Si sigue en Sí, el blueprint es el menor de sus problemas.
  3. Revise el consentimiento de usuarios en Entra ID > Aplicaciones empresariales > Consentimiento y permisos. Como mínimo, elimine la opción heredada que permite consentir cualquier aplicación, y habilite el flujo de consentimiento del administrador para que los usuarios soliciten acceso en lugar de otorgarlo ellos mismos.
  4. Haga un inventario de los blueprints existentes y sus dueños, ahora mismo. Como el despliegue ya comenzó, puede haber blueprints creados por usuarios desde el 4 de noviembre. En el centro de administración de Microsoft 365, la sección Agentes > Todos los agentes muestra el inventario (basta el rol AI Reader). Para el detalle de propietarios, puede usar Microsoft Graph PowerShell con el script de abajo. Cualquier blueprint cuyo dueño sea un usuario común merece una conversación.
  5. Asigne el rol Agent ID Developer solo a quienes construyen agentes, idealmente como asignación elegible en PIM, para que lo activen cuando lo necesiten. Microsoft exige un patrocinador (sponsor) al crear un blueprint vía Graph: úselo como control de negocio, con un responsable con nombre y un propósito acordado.
  6. Valide la restricción (si el despliegue ya llegó a su tenant) con dos cuentas: una con el rol Agent ID Developer y otra sin roles. Solo la primera debe poder crear un blueprint.

Script de inventario (Microsoft Graph PowerShell)

Este script consulta únicamente objetos de tipo blueprint (no todos los registros de aplicación) y exporta nombre, fecha de creación y propietarios. Requiere el permiso de solo lectura AgentIdentityBlueprint.Read.All.

Connect-MgGraph -Scopes "AgentIdentityBlueprint.Read.All"

$base = "https://graph.microsoft.com/v1.0/applications"
$uri  = "$base/microsoft.graph.agentIdentityBlueprint" +
        "?`$select=id,appId,displayName,createdDateTime" +
        "&`$expand=owners"
$blueprints = @()
do {
    $resp = Invoke-MgGraphRequest -Method GET -Uri $uri
    $blueprints += $resp.value
    $uri = $resp.'@odata.nextLink'
} while ($uri)

$blueprints | ForEach-Object {
    [PSCustomObject]@{
        Nombre        = $_.displayName
        AppId         = $_.appId
        Creado        = $_.createdDateTime
        Propietarios  = ($_.owners.userPrincipalName -join ", ")
    }
} | Export-Csv .\BlueprintsAgentes.csv -NoTypeInformation -Encoding UTF8

Algunos autores también publican cómo cambiar la opción por PowerShell, mediante una propiedad de la política de autorización en el endpoint beta de Graph. Al momento de escribir este artículo esa propiedad no aparece documentada en Microsoft Learn, por lo que recomendamos hacer el cambio desde el portal hasta que Microsoft la documente.

Conclusión: los valores predeterminados no son una decisión de seguridad

Microsoft diseña los valores predeterminados para que la adopción sea lo más fluida posible. Es una decisión comercial razonable, pero no es una decisión de seguridad tomada para su organización. La configuración de blueprints de agentes es un buen ejemplo: no es una vulnerabilidad ni una emergencia, pero deja abierta, sin que nadie lo decida, una capacidad que la mayoría de las empresas no necesita en manos de todos sus usuarios.

Desactivarla toma dos minutos. Como el despliegue ya está en curso, súmele el inventario: cada día que la opción sigue en Sí es un día más de objetos que nadie aprobó y que alguien tendrá que revisar.

En GFS InfoSec revisamos este tipo de configuraciones de forma continua como parte de nuestro servicio de Administración Segura de Microsoft 365: valores predeterminados de Entra ID, consentimiento de aplicaciones, roles privilegiados y, ahora, la gobernanza de agentes de IA. Si quiere saber cómo está configurado su tenant y si ya hay blueprints que nadie aprobó, conversemos.

Fuentes

Publicaciones Similares