🔐 Copilot Studio ya crea una identidad Entra obligatoria por agente
🔐 Copilot Studio ya crea una identidad Entra obligatoria por agente
Desde julio de 2026, cada agente nuevo creado en Microsoft Copilot Studio recibe automáticamente un Microsoft Entra Agent ID. Ya no existe la opción de desactivar esta creación a nivel de entorno.
Puede parecer un cambio administrativo, pero técnicamente modifica el modelo de gobierno: el agente pasa a tener una identidad de carga de trabajo propia, visible en Entra, con ciclo de vida, trazabilidad y permisos de conectores asociados. Esto permite responder preguntas que antes obligaban a cruzar Power Platform y Entra: ¿qué agente es este?, ¿quién responde por él?, ¿qué conectores puede invocar? y ¿qué políticas condicionan su ejecución?
En este artículo veremos qué crea Copilot Studio, cómo se relaciona con el agente de Dataverse, cuándo aparecen los permisos, qué protege realmente Conditional Access y cómo preparar una revisión operativa.
Estado a 21 de agosto de 2026: la creación automática es obligatoria para agentes nuevos de Copilot Studio. Los agentes anteriores a julio de 2026 continúan temporalmente con sus app registrations y Microsoft anuncia una migración futura.
Qué cambia exactamente
Un Entra Agent ID es un service principal con subtipo Agent. El flujo de autenticación sigue siendo OAuth; la novedad no consiste en sustituir OAuth, sino en representar cada agente como una identidad gobernable y reconocible dentro del directorio.
| Antes de julio de 2026 | Agentes nuevos desde julio de 2026 |
|---|---|
| App registration tradicional | Entra Agent ID |
| El maker figuraba como owner | El maker figura como sponsor con permisos limitados |
| Sin permisos de conectores reflejados en la identidad | Los conectores compatibles aparecen como API permissions al publicar |
| Gobierno centrado en la aplicación y Power Platform | Inventario, auditoría y políticas por identidad de agente |
| Modelo heredado hasta su migración | Creación automática y sin opt-out |
Hay dos matices importantes:
- No es la autenticación del usuario final. El Agent ID identifica al agente cuando se comunica con canales y servicios. La opción de autenticación del agente —Microsoft Entra, OAuth genérico o sin autenticación— sigue determinando cómo se identifica el usuario.
- No aplica a los agentes de Microsoft 365 Copilot Agent Builder. La documentación actual delimita esta identidad a los agentes de Copilot Studio; Agent Builder no utiliza esos campos de identidad.
Arquitectura: blueprint, identidad y agente
Al crear el primer agente con esta capacidad, Copilot Studio añade al tenant un blueprint denominado Microsoft Copilot Studio agent identity blueprint y su blueprint principal correspondiente. Cada Agent ID se crea como hijo de ese blueprint global.
El identificador documentado para el blueprint de producción es:
25664c89-cea5-4ab6-b924-a54fd8a19ae0
El flujo lógico es el siguiente:
Maker
│ crea
▼
Agente de Copilot Studio (Dataverse)
│ solicita identidad administrada
▼
Blueprint principal de Microsoft
│ crea mediante credenciales federadas
▼
Entra Agent ID del tenant
│ publica permisos descriptivos
▼
Connectors + políticas ACP/DLP + Conditional Access
Microsoft controla el blueprint y el mecanismo de autenticación mediante Federated Identity Credentials. Según la documentación, nadie dentro del tenant —incluidos los administradores— puede generar tokens usando esa identidad. Tampoco se permite aportar una identidad o app registration propia: Copilot Studio crea y administra el objeto para mantener el vínculo con canales, servicios y ciclo de vida.
El maker no se convierte en propietario con capacidad plena sobre la identidad. Se añade como sponsor, lo que conserva trazabilidad y responsabilidad operativa reduciendo el riesgo de modificar permisos o credenciales.
Cómo se proyectan los conectores en Entra
El punto más interesante aparece al publicar el agente. Copilot Studio inspecciona los conectores configurados y añade permisos API al Agent ID para describir qué puede invocar.
La granularidad depende de cómo se haya añadido el conector:
Operations.Execute.All: el conector se añadió como herramienta completa y el agente puede seleccionar cualquiera de sus operaciones expuestas.- Scopes de operación individuales: solo se añadieron acciones concretas del conector.
Azure API Connections Runtime.All: fallback para conectores que todavía no definen scopes granulares.
Al añadir o quitar herramientas y volver a publicar, Copilot Studio vuelve a calcular esos permisos. Por tanto, una auditoría debe consultar la identidad correspondiente a la versión publicada, no limitarse al borrador del maker.
Lo que esos scopes significan —y lo que no
Estos permisos describen capacidades del runtime de conectores. No son permisos directos como Mail.Read o Files.Read.All y no convierten la identidad en una vía alternativa para llamar a Microsoft Graph.
En tiempo de ejecución, Power Platform vuelve a validar:
- las Advanced Connector Policies (ACP),
- las políticas de Data Loss Prevention (DLP),
- la conexión y los permisos reales del usuario o contexto configurado,
- y las restricciones del canal.
Una forma útil de entenderlo es:
Scopes del Agent ID = lo que el agente está configurado para intentar
ACP + DLP + runtime = lo que el agente puede ejecutar realmente
La visibilidad de scopes existe para todos los canales, pero a fecha de este artículo la evaluación end-to-end de Conditional Access sobre el Agent ID solo se aplica cuando el agente se ejecuta en Microsoft Teams. En otros canales, los conectores siguen usando el flujo de autenticación existente de Power Platform. Diseñar una política suponiendo cobertura idéntica en web, Teams y otros canales sería un error.
También hay una limitación de alcance: actualmente, los scopes se proyectan para conectores first-party y certificados. Custom connectors, MCP servers y herramientas REST no añaden permisos API al Agent ID. Esas integraciones necesitan su propio análisis de autenticación, secretos, autorización y red.
Cómo comprobar la identidad de un agente
1. Obtener el GUID en Copilot Studio
- Abre el agente.
- Ve a Settings.
- Selecciona Advanced.
- Expande Metadata.
- Copia el valor de Entra Agent ID.
En un agente heredado verás el Application ID de la app registration. Esa diferencia permite clasificar rápidamente el inventario durante la transición.
2. Localizarla en Entra
Usa el GUID para buscar el service principal en Microsoft Entra admin center. Comprueba como mínimo:
- subtipo de identidad
Agent, - blueprint principal asociado,
- sponsor del agente,
- API permissions de conectores,
- sign-in logs,
- políticas de Conditional Access aplicables.
3. Verificar tras cada publicación
La configuración de conectores se refleja cuando el agente se publica. Después de un cambio:
- publica una nueva versión;
- revisa los permisos API añadidos o eliminados;
- confirma que ACP y DLP permiten solo la combinación esperada;
- prueba el agente en cada canal relevante;
- conserva evidencia del resultado y de la versión publicada.
Inventario automatizado
El esquema de inventario de Copilot Studio expone campos específicos para relacionar Dataverse y Entra:
{
"properties": {
"name": "<CDS bot ID>",
"environmentId": "<Power Platform environment ID>",
"ownerId": "<Entra object ID del owner>",
"entraAppId": null,
"entraAgentId": "<Entra Agent ID>",
"entraAgentBlueprintId": "<Blueprint ID>",
"lastPublishedAt": "2026-08-21T08:00:00Z"
}
}
Los agentes legacy rellenan entraAppId; los nuevos usan entraAgentId y entraAgentBlueprintId. El inventario refleja la configuración de la versión publicada. Si hay cambios sin publicar, no aparecerán hasta la siguiente publicación.
Esto permite construir controles como:
- agentes publicados sin owner o sponsor válido,
- identidades sin publicación reciente,
- diferencias entre conectores declarados y aprobados,
- agentes compartidos con todo el tenant,
- identidades heredadas pendientes de migración,
- objetos huérfanos después de procesos de baja fallidos.
Migración de agentes existentes
Los agentes creados antes del despliegue de julio de 2026 continúan utilizando app registrations. Microsoft indica que la migración será:
- automática,
- sin downtime,
- conservando el GUID del agente,
- compatible con Teams, Omnichannel y skills.
No se ha publicado una fecha única de backfill para todos los tenants. Por eso conviene soportar ambos modelos en consultas, alertas y cuadros de mando. No marques automáticamente entraAppId != null como error: durante la transición es un estado válido.
Cuotas: el riesgo operativo menos visible
Cada Agent ID es un objeto del directorio y consume cuota de recursos de Entra. Si el tenant alcanza el límite, la creación del agente falla, porque Copilot Studio provisiona la identidad en el mismo proceso.
Los límites destacados por Microsoft son:
- 50.000 objetos de directorio por defecto;
- 300.000 con dominio verificado, salvo tenants creados mediante self-service signup;
- los Agent IDs y el resto de recursos no pueden superar el 95 % de la cuota;
- durante los dos primeros días de un tenant nuevo, el límite temporal es de 600 objetos.
El límite habitual de 250 identidades por blueprint no se aplica al blueprint de Copilot Studio porque es propiedad de Microsoft. Aun así, una organización que genera agentes automáticamente debe vigilar la cuota general y eliminar entornos y agentes de prueba que ya no sean necesarios.
Ciclo de vida y borrado
Cuando se elimina un agente desde Copilot Studio, la plataforma elimina también su Agent ID —o la app registration si es legacy—. Esta vinculación reduce objetos huérfanos, pero no sustituye la verificación operativa.
Una política mínima debería definir:
- owner funcional y sponsor técnico;
- revisión periódica de permisos y canales;
- caducidad para agentes de prueba;
- proceso de baja desde Copilot Studio, no borrando directamente en Entra;
- comprobación posterior de que la identidad desapareció;
- conservación de logs conforme a la política de auditoría.
Checklist de adopción
| Control | Acción recomendada |
|---|---|
| Inventario | Registrar CDS bot ID, Environment ID, Agent ID/App ID y blueprint |
| Ownership | Validar owner y sponsor; evitar cuentas personales sin relevo |
| Permisos | Revisar scopes después de publicar y limitar acciones del conector |
| DLP/ACP | Confirmar que los permisos visibles no contradicen las políticas runtime |
| Conditional Access | Probar en Teams y documentar la limitación actual del resto de canales |
| MCP/REST | Gobernar por separado; hoy no se proyectan como API permissions del Agent ID |
| Cuotas | Alertar antes del 95 % y controlar la creación masiva de agentes |
| Legacy | Admitir entraAppId hasta que Microsoft complete el backfill |
| Baja | Eliminar desde Copilot Studio y verificar la desaparición en Entra |
Conclusión
La obligatoriedad de Microsoft Entra Agent ID convierte la identidad en una pieza nativa del diseño de agentes, no en una tarea posterior de seguridad. La mejora principal es la correlación: un agente, una identidad, un sponsor, unos conectores visibles y un ciclo de vida trazable.
Pero la visibilidad no equivale por sí sola a autorización. DLP y ACP siguen gobernando el runtime; Conditional Access todavía tiene alcance de canal; y MCP, REST y custom connectors requieren controles complementarios. El patrón correcto consiste en combinar inventario, publicación controlada, mínimo privilegio y pruebas por canal.