Entra Agent ID auditado: blueprints, fmi_path y el claim marcador de agente

Una agent identity en Microsoft Entra no tiene credenciales propias. Su blueprint guarda la credencial, impersona al agente mediante un intercambio de tokens de dos saltos, y el token que sale lleva un claim marcador que dice qué blueprint lo produjo. Leímos la spec completa para saber qué impone realmente ese modelo.

Microsoft Entra Agent ID es la capa de identidad que Microsoft ofrece para agentes de IA dentro de un tenant corporativo. Se anunció como preview en Build el 19 de mayo de 2025, se amplió en Ignite en noviembre de 2025, y las release notes de Entra listan "General Availability - Microsoft Entra Agent ID platform" bajo abril de 2026. Desde entonces la superficie no ha dejado de moverse: los blades del agent registry en Entra se retiraron el 1 de mayo de 2026 a favor de Microsoft Agent 365, la referencia de Graph para los nuevos tipos de objeto se actualizó el 3 de septiembre, y ese mismo día se mergeó en el repositorio público de docs un how-to titulado "Secure a Model Context Protocol (MCP) server with Microsoft Entra ID".

No tomamos las páginas de producto al pie de la letra. Descargamos los 58 archivos Markdown que forman docs/agent-id en el repositorio público MicrosoftDocs/entra-docs, los resource types beta de Microsoft Graph para agentIdentityBlueprint y agentIdentity, el documento OpenAPI del sidecar del Auth SDK en el repositorio microsoft-identity-web, la lista de tags de la imagen del sidecar en el Microsoft Container Registry, la referencia de claims del token y el repositorio de samples. Todo lo que sigue sale de esas fuentes, leídas el 13 de septiembre de 2026. Donde los documentos se contradicen entre sí, lo decimos.

Tres objetos, una credencial

La página de conceptos clave define la jerarquía en tres frases que contienen casi todo el diseño. Una agent identity "es la identidad primaria que un agente de IA usa para autenticarse ante sistemas y acceder a recursos. A diferencia de las cuentas de usuario, las agent identities no tienen credenciales propias. Se autentican usando tokens emitidos por su agent identity blueprint." Un blueprint "guarda credenciales y las usa para adquirir tokens en nombre de todas las agent identities creadas a partir de él." Y cuando un blueprint se agrega a un tenant, Entra crea un blueprint principal, el objeto que aparece en los audit logs y adquiere tokens por él.

En términos de Graph no son primitivas nuevas sino subtipos. El recurso agentIdentityBlueprint "hereda de application" y se serializa como #microsoft.graph.agentIdentityBlueprint. El recurso agentIdentity "hereda de servicePrincipal", se serializa como #microsoft.graph.agentIdentity, lleva un agentIdentityBlueprintId con el appId del padre y tiene servicePrincipalType fijo en ServiceIdentity. La página de service principals es explícita en que ese es el punto: "Las agent identities se modelan como service principals single-tenant con una nueva clasificación de subtipo 'agent'." Un cuarto objeto opcional, la cuenta de usuario del agente, se empareja 1:1 con una agent identity para los casos en que hace falta un buzón o presencia en Teams.

Las reglas que cuelgan de esa jerarquía son las que un operador necesita conocer, y están repartidas en varias páginas. Las juntamos.

Vale la pena registrar dos límites del schema. El requiredResourceAccess de un blueprint no puede nombrar más de 50 APIs de recurso ni más de 400 permisos en total. La colección managerApplications, que permite a otra aplicación crear principals e identidades para un blueprint sin AgentIdentityBlueprintPrincipal.ReadWrite.All, está limitada a 10 valores y "actualmente, solo se pueden establecer IDs de aplicaciones first-party de Microsoft."

El intercambio de dos saltos indexado por fmi_path

El mecanismo central es un intercambio de tokens que los docs llaman impersonación. La página del flujo autónomo publica los dos saltos. En el primero, el blueprint presenta su propia credencial y pide un exchange token con scope en el recurso de token exchange, nombrando a la hija en la que pretende convertirse:

# Salto 1: blueprint -> exchange token T1
POST /oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id=AgentBlueprint
&scope=api://AzureADTokenExchange/.default
&fmi_path=AgentIdentity
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=TUAMI
&grant_type=client_credentials

El parámetro fmi_path es la única pieza no estándar. Los docs lo definen como "el client ID (app ID) de la agent identity. Este parámetro le dice a Microsoft Entra ID qué agent identity hija está impersonando el blueprint durante el intercambio de tokens." TUAMI en el ejemplo es un token de managed identity usado como federated identity credential; el mismo lugar acepta un client secret o un certificado, con una advertencia en cada página de flujo de que los secrets "no deberían usarse como client credentials en entornos de producción para agent identity blueprints."

En el segundo salto la hija presenta T1 como su client assertion y pide el token de recurso:

# Salto 2: agent identity -> resource token TR
POST /oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id=AgentIdentity
&scope=https://resource.example.com/.default
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion={T1}
&grant_type=client_credentials

La regla de validación, citada de la página: "Microsoft Entra ID valida que T1 (aud) == app padre de la agent identity == agent identity blueprint." La página de on-behalf-of agrega la versión fina: el azp de T1 debe ser el blueprint, y el sub de T1, "el FMI path", debe resolver a la hija que realiza el intercambio. En otras palabras, la hija nunca tiene una credencial de larga duración. Tiene una assertion de corta duración que el directorio acuñó para exactamente un par blueprint-hija.

El flujo on-behalf-of es el mismo esqueleto con un token de usuario adjunto. El salto 2 pasa a ser un grant jwt-bearer con assertion={Tc}, client_assertion={T1} y requested_token_use=on_behalf_of. Dos restricciones importan para quien conecte un cliente. Primero, el token de usuario "debe tener como audiencia el blueprint; un token con audiencia en otro recurso (por ejemplo, Microsoft Graph) se rechaza con AADSTS50013." Segundo, ni blueprints ni agent identities "pueden iniciar flujos interactivos /authorize", e intentar consentir sobre una hija "devuelve el error AADSTS82014". El consentimiento tiene que otorgarse en el blueprint como permiso heredable. Los grant types soportados son client_credentials, jwt-bearer y refresh_token. No hay public clients; toda entidad de agente es un confidential client.

El tercer flujo, la impersonación de la cuenta de usuario del agente, agrega un salto y un grant type que no habíamos visto documentado en ningún otro lado. El blueprint obtiene T1 para la agent identity, la agent identity obtiene un segundo exchange token T2 para sí misma, y luego llama al token endpoint con grant_type=user_fic, user_federated_identity_credential={T2}, [email protected] y requested_token_use=on_behalf_of. La página señala que "debe usarse el mismo client ID en ambas fases para prevenir ataques de escalada de privilegios."

Qué dice el token

La referencia de claims del token publica un access token de ejemplo completo para un agente autónomo. Las partes que difieren de un token app-only ordinario:

{
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "appid": "11112222-bbbb-3333-cccc-4444dddd5555",
  "idtyp": "app",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "sub": "bbbbbbbb-1111-2222-3333-cccccccccccc",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "xms_act_fct": "3 9 11",
  "xms_sub_fct": "9 3 11",
  "xms_tnt_fct": "3 9",
  "xms_idrel": "7 10",
  "xms_par_app_azp": "30cf4c22-9985-4ef7-8756-91cc888176bd"
}

Cuatro claims hacen el trabajo. xms_par_app_azp es "la aplicación padre de la authorized party", es decir el app ID del blueprint. xms_act_fct y xms_sub_fct son listas de enteros separadas por espacios que describen al actor y al sujeto; los dos valores que importan a un resource server son 11 para "AgentIdentity" y 13 para "AgentIDUser". xms_idrel describe la relación entre el sujeto y el tenant; 7 es un service principal y 33 es "Federated managed identity". La referencia advierte que son multivaluados, sin orden, y que "debes ignorar cualquier valor que no sea relevante."

Los tres escenarios difieren de un modo que idtyp por sí solo no puede expresar. Un agente actuando en nombre de un humano produce idtyp=user, el oid del humano y xms_act_fct conteniendo 11. Un agente autónomo produce idtyp=app, xms_idrel 7, ambos facet claims con 11 y scp "vacío o / (sin scope)". Un agente corriendo como su propia cuenta de usuario produce idtyp=user de nuevo, pero xms_sub_fct conteniendo 13. La referencia lo dice sin rodeos: "El valor de idtyp por sí solo no distingue a un usuario humano de la cuenta de usuario de un agente."

Aquí los documentos se contradicen, o al menos hablan sin escucharse. El how-to de validación en una API downstream lista cuatro checks y dice del cuarto: "El claim xms_par_app_azp está presente en tokens de agent identity y ausente en tokens app-only estándar." La referencia de claims lista xms_par_app_azp y los facet claims bajo "los siguientes claims opcionales también se soportan para identificar que los tokens son de agent identities." Quien siga el how-to dará la presencia por sentada. Quien siga la referencia se preguntará si el claim debe configurarse a través del optionalClaims del blueprint. El token de ejemplo lo incluye y la weather API de ejemplo se apoya en él, así que la lectura práctica es que viene por defecto, pero es algo a confirmar contra tu propio tenant antes de que una decisión de autorización dependa de ello. La propia referencia lo desaconseja: "No se recomienda usar el ID de la aplicación padre para decisiones de autorización, ya que resultaría en acceso generalizado por muchos agentes." Regístralo en logs, no filtres por él.

El sidecar como lo único que habla con login.microsoftonline.com

La respuesta de Microsoft a "quién ejecuta los dos saltos" es un contenedor. El sidecar del Auth SDK corre junto al agente, guarda la credencial del blueprint y expone endpoints HTTP "en la red local del pod". La frontera de seguridad declarada es que "el sidecar no tiene puerto en el host. Solo los servicios dentro de la misma red, como tu contenedor de agente, pueden pedir tokens." La imagen vive en mcr.microsoft.com/entra-sdk/auth-sidecar. Listamos sus tags mediante la API del registry el 13 de septiembre: 1.0.0-rc.1, 1.0.0-rc.2, 1.0.0, 1.1.0 y 1.1.1, cada uno en variante azurelinux3.0-distroless y windows.

El contrato HTTP es pequeño. Leímos el documento OpenAPI en el repositorio microsoft-identity-web; declara versión 1.0.0 y cinco rutas: GET /Validate, GET /AuthorizationHeader/{apiName}, GET /AuthorizationHeaderUnauthenticated/{apiName}, y /DownstreamApi/{apiName} más su gemelo no autenticado, que hacen proxy de la llamada y devuelven status, headers y body. La referencia de endpoints publicada agrega /healthz y las reglas para los tres parámetros de agente:

# Agente autónomo: AgentIdentity solo
GET /AuthorizationHeaderUnauthenticated/graph-app?AgentIdentity={agentAppId}

# Agente delegado: AgentIdentity + token de usuario entrante (OBO)
GET /AuthorizationHeader/graph?AgentIdentity={agentAppId}
Authorization: Bearer {Tc}

# Cuenta de usuario del agente: AgentIdentity + uno de
&AgentUsername=[email protected]   # o
&AgentUserId={objectId}           # mutuamente excluyentes

# Respuesta
{ "authorizationHeader": "Bearer eyJ0eXAiOiJKV1QiLCJhbGc..." }

La fuente de la credencial es un switch de configuración, no código: ClientSecret para desarrollo local, SignedAssertionFromManagedIdentity para Azure, KeyVault para un certificado en Key Vault, StoreWithThumbprint para un almacén de certificados local. El walkthrough de desarrollo local levanta cuatro contenedores con Docker Compose, incluido un contenedor de Ollama que descarga qwen2.5:1.5b, y advierte que este modelo "es demasiado pequeño para tool calling confiable". El sidecar también soporta proof-of-possession: pasa optionsOverride.AcquireTokenOptions.PopPublicKey y el header vuelve como PoP en lugar de Bearer. El repositorio de samples que respalda todo esto se creó el 9 de abril de 2026, tiene licencia MIT y el día que lo revisamos tenía 12 estrellas, 8 forks, 20 issues abiertas y un último push del 5 de agosto. Es material de referencia, no un ecosistema.

Agentes que no corren en Azure

La parte más relevante para quien opera agentes en su propia infraestructura es que la credencial del blueprint no tiene que ser un secret ni una managed identity de Azure. La página de agentes de terceros documenta dos patrones de integración. El patrón sidecar funciona "con cualquier agente en contenedor" y nombra AWS Bedrock, Ollama con LangChain y n8n. El patrón de federación "usa Workload Identity Federation para intercambiar credenciales de proveedores de identidad externos como AWS Security Token Service (STS) directamente por tokens de Microsoft Entra" y lista "GCP Workload Identity → Microsoft Entra Agent ID" y "AWS STS → Microsoft Entra Agent ID" como caminos soportados. El requisito es "una plataforma de agentes que soporte OIDC o STS" y una federated identity credential preconfigurada en el blueprint.

La federated credential en sí es el objeto estándar de Entra. De la página de workload identity federation: el issuer y el subject de la credencial se comparan con el iss y el sub del token externo, la audiencia debe ser api://AzureADTokenExchange para la nube global, "se pueden agregar como máximo 20 federated identity credentials a una aplicación", y una credencial mal configurada "se crea exitosamente sin error. El error no se hace evidente hasta que falla el intercambio de tokens." El recurso agentIdentityBlueprint expone el CRUD completo para estas credenciales, incluido un upsert.

Leído en conjunto, esto significa que un agente que ya lleva una identidad de workload al estilo SPIFFE, o cualquier token OIDC de su runtime, puede intercambiarlo por un exchange token de Entra y luego recorrer los dos saltos de arriba. Cubrimos la versión de estándares abiertos de ese intercambio en nuestra auditoría de WIMSE y SPIFFE; la versión de Entra es propietaria en el salto de fmi_path y RFC 7523 estándar en todo lo demás.

Las barreras que Microsoft deja fijas

Dos listas en la documentación dicen más sobre el modelo de amenazas de Microsoft que cualquier página de overview. La primera es el conjunto de permisos de Microsoft Graph que "están explícitamente bloqueados para agentes para prevenir mal uso o acceso no intencionado a datos sensibles" y "no pueden otorgarse a agent identities a través de Microsoft Graph ni del Microsoft Entra admin center." Contamos 59 entradas en la tabla del overview de Graph. Los esperables están: Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, Application.ReadWrite.All, User.ReadWrite.All, y todo permiso que dejaría a un agente acuñar más agentes, desde AgentIdentity.Create hasta AgentIdentityBlueprint.ReadWrite.All. Menos esperables son los bloqueos del data plane en permisos de aplicación: Files.Read.All, Files.ReadWrite.All, Sites.Read.All, Calendars.Read, Chat.Read.All y ChannelMessage.Read.All. A una agent identity autónoma no se le puede otorgar lectura a nivel de tenant sobre archivos, sitios, calendarios o chat. Tiene que pasar por el grant delegado de un usuario o por una cuenta de usuario de agente licenciada y acotada como una persona. Pedir un permiso bloqueado en requiredResourceAccess "se rechaza con una respuesta HTTP 400 Bad Request."

La segunda lista es la sección "patrones a evitar" de la página de patrones de diseño, que se lee como un conjunto de límites de escala enunciados como consejos. "Las réplicas de scale-out no necesitan agent identities separadas": múltiples instancias del mismo código "pueden correr todas bajo la misma identidad simultáneamente." "La gestión de memoria y contexto no requiere agent identities separadas." Y la que importa para sistemas de alta cardinalidad: "Crear una agent identity por reunión, por documento o por objeto efímero a alto volumen no es práctico con identidades a nivel de directorio hoy." La página sí ofrece una variante de identidad efímera, donde un orquestador crea una hija en runtime y la borra al terminar la sesión, pero señala que "la creación de agent identities efímeras ocurre en runtime, lo que introduce latencia no determinista." Las agent identities son objetos de directorio. Son baratas comparadas con app registrations, no comparadas con una firma.

Un MCP server detrás de Entra, a septiembre de 2026

El documento más nuevo del conjunto es el que más probablemente se use. El how-to Secure a Model Context Protocol (MCP) server with Microsoft Entra ID lleva un ms.date del 1 de septiembre de 2026 y se mergeó el 3 de septiembre en el commit 2506cb0. Mapea el modelo de autorización de MCP sobre Entra tal como lo describimos en nuestro deep dive de autorización MCP: el MCP server es el protected resource, Entra es el authorization server, el agente es el cliente, y el cliente nombra el recurso con el parámetro resource del RFC 8707.

El contenido operativo es una única regla de coincidencia exacta y sus consecuencias. "Microsoft Entra ID compara ese valor de resource con el Application ID URI (también llamado identifier URI) configurado en el app registration de tu MCP server. Si coinciden, Microsoft Entra ID emite un token cuyo claim de audiencia (aud) es tu MCP server. Si no coinciden, la petición de token falla." Para registrar un Application ID URI HTTPS igual a la URL del servidor, la app debe primero poner requestedAccessTokenVersion en 2; el how-to lo llama "el paso que la mayoría se salta." El error para una falta de coincidencia es AADSTS9010010, y la primera causa listada es una barra final: "como un Application ID URI no puede terminar en barra, un cliente que envía resource=https://mcp.contoso.com/ nunca coincide con el https://mcp.contoso.com registrado."

El documento de protected resource metadata también está detallado, y debe apuntar al issuer v2.0:

# https://mcp.contoso.com/.well-known/oauth-protected-resource
{
  "resource": "https://mcp.contoso.com",
  "authorization_servers": [
    "https://login.microsoftonline.com/<tenant-id>/v2.0"
  ],
  "scopes_supported": ["tools.read", "tools.execute"],
  "bearer_methods_supported": ["header"]
}

# y ante una petición no autenticada
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.contoso.com/.well-known/oauth-protected-resource", scope="tools.execute"

Para agentes, el how-to indica definir app roles con tipo de miembro permitido Applications, asignarlos a la agent identity y hacer que el cliente envíe una petición client-credentials con scope=https://mcp.contoso.com/.default; los roles vuelven en el claim roles. Para servidores que no pueden abandonar tokens v1, documenta el claim opcional aud con use_guid, que fuerza una audiencia GUID y relaja la restricción del identifier URI. Notablemente, el documento no menciona Client ID Metadata Documents ni dynamic client registration en absoluto: en Entra, el cliente MCP es un app registration o una agent identity que ya existe en el tenant. Es la premisa opuesta a la que examinamos en nuestra auditoría de CIMD, donde el cliente se identifica por URL y el servidor nunca lo ha visto antes. La otra respuesta MCP de Entra, el perfil de enterprise-managed authorization que reemplaza pantallas de consentimiento por assertions ID-JAG, es el tema de un post anterior.

Qué cuesta y para quién es

El lenguaje de licenciamiento se repite en cuatro páginas y vale la pena citarlo exacto, porque la división no es obvia. "Agent ID está disponible para todos los clientes de Microsoft Entra." Pero "extender las funciones de seguridad de Microsoft Entra a agentes requiere Microsoft Agent 365", que "está incluido con Microsoft 365 E7 y disponible como add-on para Microsoft E5/A5/Business Premium." La página de Conditional Access es aún más estrecha: "Conditional Access para agentes requiere Microsoft Entra ID P1 o P2 y una licencia de Microsoft Agent 365 por cada usuario. La aplicación del licenciamiento de Agent 365 llegará pronto." El objeto de identidad es gratis; el motor de políticas a su alrededor es un SKU por usuario.

El modelo de gobernanza refleja al comprador. Cada blueprint e identidad tiene owners, que son administradores técnicos, y sponsors, que "proveen responsabilidad de negocio para los agentes, tomando decisiones de ciclo de vida sin acceso administrativo técnico." Los sponsors son "requeridos durante la operación de creación" de un blueprint, y existen plantillas de lifecycle workflow "para prevenir agentes huérfanos" cuando un sponsor se va. Access packages, access reviews y detecciones de riesgo se extienden a agent identities. Es un sistema de identidad diseñado para que un auditor pregunte "quién es responsable de este agente" y reciba un nombre humano.

Qué significa para LLM4Agents

LLM4Agents da a los agentes una wallet y una key del gateway, y luego les permite pagar por request en stablecoins sobre x402. Entra Agent ID da a los agentes un objeto de directorio y un token, y luego les permite actuar dentro de un tenant bajo políticas. Los dos sistemas responden preguntas distintas, y lo interesante es dónde se encuentran.

El primer punto de encuentro es de entrada. Un agente corporativo con identidad Entra que llama a LLM4Agents hoy presenta una key del gateway, que es exactamente el caso "la API key evita Conditional Access" que describen los docs de Microsoft. Si el gateway aceptara un bearer token emitido por Entra para un recurso registrado, la política de Conditional Access del cliente filtraría las llamadas a modelos igual que filtra las llamadas a Graph, y nuestros sign-in logs heredarían su linaje xms_par_app_azp. La forma del token está completamente especificada: RS256 contra el JWKS del tenant, issuer, audiencia, y luego el marcador y los facet claims. La lista de permisos bloqueados no aplica a recursos de terceros, así que un app role de LLM4Agents sobre una agent identity está permitido. Lo que gana la plataforma es un kill switch controlado por el cliente: deshabilita el blueprint, y todo agente debajo de él deja de poder acuñar un token para nosotros.

El segundo punto de encuentro es de salida y encaja peor. Nada en este conjunto de documentos toca el pago. Las agent identities están atadas al tenant; la referencia dice que "las agent identities no pueden acceder a recursos fuera de su tenant de cliente asignado." Un token que no puede salir del tenant no puede servir como identidad machine-to-machine en la web abierta, y no lleva autoridad de gasto. El modelo de costos a nivel de directorio del blueprint también choca con identidades por tarea. Para la contraparte abierta, identidad de agente que un desconocido pueda verificar y que se ate a una wallet, las specs relevantes siguen siendo las de nuestra auditoría de ERC-8004 y Web Bot Auth, y las categorías de amenaza de nuestro modelo de amenazas 2026 no cambian por la existencia de Entra.

El tercer punto de encuentro es la superficie MCP. LLM4Agents expone tools sobre MCP. El how-to de septiembre le dice a cada tenant de Entra exactamente cómo exigir un token v2 con coincidencia exacta de resource y un documento PRM en la ruta well-known. Si los agentes de un cliente corren con identidades Entra, los endpoints MCP en los que confiarán son los que hablen ese dialecto.

Cómo mantenerse en la frontera

Los pasos siguientes están ordenados por cuánto desbloquean en relación a lo que cuestan.

Primero, aceptar tokens de agente de Entra en el gateway como segundo tipo de credencial. Registrar LLM4Agents como recurso multitenant con un Application ID URI HTTPS, pedir tokens v2 y validar los cuatro checks que prescribe el how-to de API downstream. Registrar en logs xms_par_app_azp, xms_act_fct y xms_sub_fct en cada request pero no autorizar por el padre, según la propia guía de Microsoft. Mapear una agent identity validada a un registro de agente existente en LLM4Agents para que el billing siga siendo por agente.

Segundo, publicar protected resource metadata para el MCP server con Entra listado como uno de varios authorization servers, y agregar un test con sabor a Entra a la suite de conformidad MCP: valores de resource con barra final, audiencia v1 versus v2, claim roles de app role para callers client-credentials. El how-to da los códigos de fallo exactos sobre los que hacer asserts.

Tercero, documentar el camino de federación en la otra dirección. A un agente alojado en LLM4Agents que necesite llegar al Graph o a los MCP servers de un cliente se le puede dar un blueprint de Entra cuya federated identity credential confíe en un token OIDC que nosotros emitimos, con audiencia api://AzureADTokenExchange. Es el patrón que Microsoft documenta para AWS y GCP, y no hay razón para que un tercer runtime no pueda ser el issuer. La imagen del sidecar puede correr en el sandbox del agente como contenedor hermano, ya que no necesita puerto en el host.

Cuarto, mantener la wallet separada del directorio. El diseño correcto es una identidad Entra que autoriza al agente a actuar dentro de un tenant y una wallet atada a x402 que permite al mismo agente pagar fuera de él, vinculadas por nuestro propio registro y no por ningún claim que emita Entra. Los límites de gasto, tema de nuestra auditoría de spend controls, quedan del lado del pago.

Quinto, vigilar tres piezas en movimiento. La Graph API del registry está siendo reemplazada por una API de Agent 365 con requisito de re-registro, y el reemplazo no tenía fecha publicada cuando leímos la página. La aplicación del licenciamiento de Conditional Access "llegará pronto". Y la discrepancia entre la redacción de claims opcionales y la de presencia garantizada para xms_par_app_azp debería resolverse probando contra un tenant real antes de que cualquier código dependa de ella.