Copilot Studio Entra Agent ID 迁移：趁 Microsoft 动手前先做

Microsoft Copilot Studio Microsoft Copilot Agentic Ai AI Microsoft 365 Copilot Studio Entra Agent ID Migration: Do It Before Microsoft Does It For You Manoj Annavajjala 9 min read · Sep 19, 2026 -- Listen Share Press enter or click to view image in full size An Advisor card appeared in my Power Platform admin center this week with a number on it: forty nine Copilot Studio agents missing Microsoft Entra Agent IDs. Severity medium, status preview, and a Migrate button sitting right there in the action bar. It is the kind of recommendation that looks like a chore and is actually a governance decision. The short version is this. Microsoft is going to migrate those agents whether you act or not. The only thing you control is whether the migration happens on your schedule with your validation window, or on Microsoft’s schedule with whatever Conditional Access surprises your estate has been quietly accumulating. That is the whole argument for doing this now. What actually changed in May 2026 Before May 2026, every agent you created in Copilot Studio got an Azure app registration provisioned automatically in your tenant. That app registration carried no API scopes, and Copilot Studio documentation was explicit that tokens generated from those identities had no access to customer data or resources. It was an authentication artifact, not a governance object. After May 2026, Copilot Studio creates a Microsoft Entra Agent ID for each new agent instead. An Entra Agent ID is a service principal with an Agent subtype. The underlying OAuth flow is unchanged. What changed is that the identity became something you can see, audit, and attach policy to. There is no opt out. Environment level opt out existed previously and was removed. Every new agent gets an agent identity. Press enter or click to view image in full size The part that matters more than the identity swap If you read the migration recommendation as an identity housekeeping task you will miss the interesting change. When a maker publishes an agent, Copilot Studio now attaches API permissions to that agent’s Entra Agent ID representing every Power Platform connector the agent is configured to use. Read that again from an admin’s chair. Your Entra and Microsoft 365 administrators can now see what an agent is wired up to call without ever opening Power Platform admin center. For organizations where the identity team and the Power Platform team have historically had no shared view of anything, that is a genuinely new capability. The permissions are not raw resource scopes. You will not see Mail.Read or Files.Read.All on an agent identity. Each connector has its own service principal in your tenant, and it grants one of three shapes of permission to the agent: Operations.Execute.All is granted when the maker added the connector at the agent level. The agent can invoke any operation that connector exposes. Individual operation scopes are granted when the maker added specific connector actions rather than the whole connector. Only the operations the agent actually uses are permitted. Azure API Connections Runtime.All is the generic fallback for connectors that do not define granular scopes. That first bullet is a maker education point waiting to happen. A maker who adds a connector at agent level instead of adding the two actions they need has just produced a broader permission footprint that is now visible to your identity team. Scopes are evaluated and applied at publish time, so adding or removing a connector and republishing updates them. Press enter or click to view image in full size The caveat almost everyone will miss There is a note buried in the agent identities FAQ that carries more weight than anything else in this topic for teams planning Conditional Access work. Compressed to its essentials: Visibility is tenant wide. Enforcement is not. Conditional Access on the agent identity is evaluated only when the agent is running in Microsoft Teams. Teams is the only channel today that performs end to end authentication using the Entra Agent ID token. Every other channel still calls connectors through the existing Power Platform connector authentication flow. Your admins can see the scopes, but Conditional Access on the agent identity is not evaluated for those calls. So if a security architect in your organization writes a control that says agent access to a sensitive connector requires a compliant device, and the agent is published to a custom website rather than Teams, that control is currently descriptive rather than enforcing. Document that assumption now, before someone builds an audit narrative on top of it. What does not change is the governance line underneath all of this. The Power Platform connector runtime is the only component that honors these scopes, and it revalidates them at runtime against your advanced connector policies and data policies. Scopes describe what an agent is configured to do. Your policies decide what it is allowed to do at the moment of execution. An attacker holding an agent identity cannot use these scopes to call Microsoft Graph or Outlook directly, because the connector platform mediates every call. Migration is opt in now and automatic later Existing agents created before May 2026 continue to run on app registrations. Governance capabilities work for both identity types during the transition period, so nothing is broken today. Microsoft has stated that these agents will be automatically migrated in a future update. The manual migration path exists so you can validate ahead of that. The documented migration characteristics are reassuring: the GUID is preserved, there is no downtime, and channel compatibility is maintained. The Advisor card is considerably more blunt about it, and I think the Advisor card is right. Migrating agent identities affects live production agents and can break authentication, connectors, and integrations if it is not carefully planned. Migration converts the app registration identity in place. The agent keeps its application client ID, so channel registrations and connectors continue to resolve to the same identifier. It is reversible per agent. You can revert an individual agent to its legacy identity if it fails validation. Running the migration from Power Platform admin center Two prerequisites will stop you cold if you skip them. You need the Power Platform Administrator, Dynamics 365 Administrator, or Global Administrator role. And Power Platform inventory must be enabled for your tenant, because that is how Advisor identifies eligible agents in the first place. If the agent inventory returns nothing, check inventory before you check anything else. The path is Actions, then Recommendations, then the Active tab, then search for the recommendation named Migrate Copilot Studio agents to Microsoft Entra Agent ID for enhanced agent governance. The agent table is the useful part. Alongside agent name and Entra app ID it gives you a suggested migration order and migration notes, plus environment, environment type, owner, recent activity, and authentication method. That is enough to build a defensible pilot batch without exporting anything, although the Download as CSV action is there if you want to share the list with agent owners before you touch anything. Press enter or click to view image in full size One operational detail worth knowing before you panic: Advisor recommendations can stay visible for up to a week after you act on them while the recommendation data refreshes. A card that still shows forty nine agents the morning after you migrated ten is not a failed migration. The API path, if you want to automate it Both migrate and revert are HTTP POST requests against the Power Platform API, authorized with a bearer token for the Power Platform service. No request body is required. You need the botID and environmentID for each agent, both of which appear in the agent inventory under Manage, then Copilot Studio. The migrate endpoint returns a status of Migrated or AlreadyMigrated. The rollback endpoint returns NotMigrated or RolledBack. Both return the identity details, including the agent identity ID, application ID, service principal object ID, and managed identity ID, which is useful if you are writing migration results back to a tracking table. Get Manoj Annavajjala’s stories in your inbox Join Medium for free to get updates from this writer. Subscribe Subscribe Remember me for faster sign in My recommendation for most tenants is to use Advisor for the pilot and the first few batches, and only move to the API once you have a validated pattern and a real volume problem. The Advisor experience is the recommended manual method, and it gives you the suggested migration order that the API does not. What validation actually means Validation is the step teams skip, and it is the only step that makes incremental migration worth the effort. Before you migrate another batch, confirm with each agent’s maker that the migrated agent: Responds correctly in every channel where it is published, not just the one the maker tests by habit. Runs its actions, connectors, flows, and integrations successfully. Authenticates as expected, including any custom authentication configuration. Behaves correctly under applicable agent access policies and Conditional Access policies. Then go read the sign in logs for the migrated agents in the Microsoft Entra admin center. Confirm successful authentication and investigate failures and unexpected Conditional Access results. If an agent does not pass, stop the batch rollout and revert that agent before continuing. One failure in a batch of five is a signal about the next fifty. The tenant limit nobody budgets for Every Entra Agent ID that Copilot Studio creates is a directory object in your tenant and counts against your Microsoft Entra resource quota. The identity is provisioned when the agent is created, not when it is published, which means a quota problem surfaces as agent creation failures rather than runtime failures. Tenant resource quota 50,000 directory objects by default, 300,000 with a verified domain Tenants created through self service signup stay at 50,000 even after a domain is verified Usable share of quota 95 percent Agent identities and all other Entra resources together cannot exceed this New tenant restriction 600 directory objects for the first two days Bites demo, training, and proof of concept tenants specifically Per blueprint cap Does not apply The 250 identity per blueprint cap is waived because the Copilot Studio blueprint is Microsoft owned If you run a large estate with heavy agent sprawl in a default environment, this is worth checking before it becomes a support ticket from a maker who cannot figure out why agent creation failed. Who can actually use these identities This one deserves more attention than it gets, because it is a straightforward security improvement over the legacy model. With app registrations, anyone holding Global Administrator, Application Administrator, or Cloud Application Administrator could create client secrets or certificates for any app registration in the tenant without needing ownership. With Entra Agent IDs, a Microsoft owned blueprint principal creates and manages the identities using federated identity credentials, and nobody in your tenant can generate tokens using the agent identity. That includes your tenant administrators. When the first agent identity is created in an environment, Copilot Studio adds a blueprint to your tenant named Microsoft Copilot Studio agent identity blueprint, with blueprint ID 25664c89-cea5–4ab6-b924-a54fd8a19ae0. Every agent identity is created as a child of that blueprint. If you see that object appear in your tenant and do not recognize it, now you do. Ownership also changed shape. For Entra Agent IDs the agent owner is added as a sponsor with limited permissions rather than as a full owner, which reduces the blast radius around permission modification. Some preexisting agents may not have sponsors yet. What I would do this week Confirm Power Platform inventory is enabled. Nothing else works without it. Open the Advisor recommendation and download the CSV. Sort by environment type and recent activity, not by the suggested order alone. Pick a pilot of three to five agents that between them cover your real surface area: at least one Teams published agent, at least one non Teams channel, at least one agent with custom authentication, and at least one with a connector heavy action set. Email the owners of those agents with a specific validation window, not a general heads up. Migrate the pilot, validate end to end, and read the Entra sign in logs before you touch batch two. Separately, audit how your makers are adding connectors. Agent level connector configuration produces Operations.Execute.All, and that is now visible to your identity team. The migration itself is not the hard part. Microsoft built a reversible, incremental path with a rollback endpoint, which is more than we usually get. The hard part is that this is the first time many organizations will have to reconcile what their agents are configured to do with what their governance policies claim they are allowed to do. Better to find that gap in a pilot batch of five than in an automatic migration of four hundred. Sources The manual migration experience is in preview at the time of writing and is subject to change. Verify current behavior against Microsoft Learn before applying this guidance in production. Originally published at https://powerplatformengineer.com on September 19, 2026.