Microsoft’s public preview of Dataverse agent users gives AI agents a distinct security principal inside a Power Platform environment, so an agent can be assigned Dataverse roles and its work can be separated from that of employees and conventional app integrations. The practical benefit is straightforward: a sales or service agent no longer needs to operate under a shared application identity with permissions that are difficult to attribute after the fact.
But this is not a brand-new August 6 capability, despite Microsoft’s newly published Power Platform blog positioning it as “now in public preview.” Microsoft’s own Message Center announcement, archived as MC1300981, says rollout began May 4 and was expected to reach North America by May 22. Microsoft Learn’s preview documentation for creating Entra agent users was last updated May 2. The August post is best read as a renewed adoption push around an already-rolling preview, not as a fresh product launch.
For Power Platform administrators, the more important date is July 2026. Microsoft’s current Copilot Studio documentation says agents created after the Entra Agent ID rollout in July automatically receive an Entra Agent ID, while agents created before that rollout continue using ordinary app registrations until Microsoft migrates them in the future. That means the governance story differs sharply between a newly created Copilot Studio agent and an existing estate of production agents.
Microsoft Entra Agent ID is the directory-side identity framework for nonhuman software agents. In Microsoft’s implementation, an agent identity is a specialized service principal created from an agent identity blueprint—a reusable template that can represent a type of agent and apply consistent controls to its individual instances.
That architecture matters because an Agent ID does not work like a normal service account with a password, certificate, or secret attached directly to it. Microsoft’s Entra documentation says the blueprint holds the credentials and acquires tokens on behalf of individual agent identities. The individual agent identity holds the distinct permissions and audit identity. In effect, Microsoft is separating credential administration for a class of agents from the authorization and audit trail for each deployed agent.
Dataverse agent users are the second half of the arrangement. An Entra identity alone is not sufficient to access CRM tables, custom tables, or Dataverse APIs in a Power Platform environment. An administrator must add that Entra identity to the particular environment as an Entra agent user, then assign Dataverse security roles.
The consequence is useful but easy to miss in the marketing language: Entra Agent ID does not automatically make an agent least-privileged. It gives an organization a cleaner identity object to which least privilege can be applied. The real access boundary remains the Dataverse security role, including its table-level privileges, scope, and any field-security profile that applies to the data the agent will handle.
An agent that can update Leads, create Activities, and change Lead Status still needs those permissions designed deliberately. Giving it an existing broad sales role because it is convenient defeats the point of moving away from shared application identities.
Microsoft’s Copilot Studio documentation now makes the distinction explicit: agents created before the July 2026 Entra Agent ID rollout remain on app registrations, with migration promised for a future date. Microsoft also says governance capabilities continue to work for both Agent IDs and app registration IDs during this transition, but it has not published a migration schedule in the documentation reviewed for this article.
That means administrators should not assume that a new Entra-based policy, agent inventory process, or review workflow has automatically converted their existing fleet into per-agent identities. It has not. An organization could have a carefully governed new agent alongside an older agent using a standard app registration, with materially different identity metadata and lifecycle behavior.
This is especially relevant where teams have built agents outside Copilot Studio. Microsoft Entra Agent ID supports Microsoft and non-Microsoft agent platforms, but the method for giving an external agent a governed identity depends on the identity platform’s SDK, workload identity federation, or another supported integration path. The Dataverse preview announcement should therefore not be mistaken for an automatic identity upgrade for every application that calls Dataverse.
For administrators, the immediate inventory question is not simply “Which agents access Dataverse?” It is “Which ones have an Entra Agent ID, which still use app registrations, and which identity actually appears in each environment’s security configuration?”
That provides a better trail for identity administration and token activity: who created or changed an agent identity, which blueprint it belongs to, whether it was enabled or disabled, and when it authenticated. It gives security teams a named nonhuman actor to investigate rather than a generic integration account whose ownership may be unclear.
It does not mean Entra logs alone explain every business action an agent performed in Dataverse. Entra’s own logging documentation describes identity and sign-in events; Dataverse auditing and environment-level monitoring remain the place to establish what record was read or changed, what values moved, and whether an action complied with the business process. The two sources of evidence need to be correlated.
That distinction becomes material during an incident. If an agent changes hundreds of lead records, the Entra trail can identify the agent identity, its blueprint, and its authentication context. Dataverse audit records and application telemetry must supply the transaction-level evidence: which records changed, what was changed, whether a human approval step was bypassed, and whether the assigned role allowed more access than intended.
Microsoft’s sales-development example—researching prospects, preparing outreach, following up, and updating lead status—is a reasonable test case precisely because it exercises a narrow set of tables and operations. It is also a useful warning against assigning permission based on a job title. “Sales development” is not a security role. A secure design would isolate the agent’s eligible lead segment, forbid access to unrelated opportunities and account data, restrict creation rights to the few activity types it needs, and prevent updates to sensitive fields unless the workflow demonstrably requires them.
Those connector permissions are not an escape hatch around Power Platform governance. Microsoft’s Copilot Studio documentation says connector scopes are revalidated by the connector runtime against Advanced Connector Policies and data loss prevention policies. In practical terms, an agent identity can improve visibility and let administrators apply Entra conditions, but it should be treated as an additional enforcement and observability layer—not a replacement for connector controls, environment strategy, DLP, or Dataverse roles.
Licensing is another area where the announcement remains high-level. Microsoft says Entra Agent ID as a platform is available to Microsoft Entra customers, but its documentation lists licensing requirements for extending certain Entra protections to agents. Conditional Access for agents requires Entra ID P1, Identity Protection requires Entra ID P2, and broader Agent 365 scenarios carry separate licensing requirements. The Power Platform blog does not state the licensing, regional availability, or production-support boundaries for Dataverse agent users beyond its preview warning.
That omission matters for an IT team planning a pilot. The feature can be evaluated in a non-production environment, but an organization should validate the exact tenant licensing and whether the intended Entra protection features are available before presenting Agent ID as a completed compliance control.
A credible pilot should establish the following before the agent is allowed to act on live business data:
For Power Platform administrators, the more important date is July 2026. Microsoft’s current Copilot Studio documentation says agents created after the Entra Agent ID rollout in July automatically receive an Entra Agent ID, while agents created before that rollout continue using ordinary app registrations until Microsoft migrates them in the future. That means the governance story differs sharply between a newly created Copilot Studio agent and an existing estate of production agents.
An Agent ID Is an Identity Layer, Not a Dataverse Permission Set
Microsoft Entra Agent ID is the directory-side identity framework for nonhuman software agents. In Microsoft’s implementation, an agent identity is a specialized service principal created from an agent identity blueprint—a reusable template that can represent a type of agent and apply consistent controls to its individual instances.That architecture matters because an Agent ID does not work like a normal service account with a password, certificate, or secret attached directly to it. Microsoft’s Entra documentation says the blueprint holds the credentials and acquires tokens on behalf of individual agent identities. The individual agent identity holds the distinct permissions and audit identity. In effect, Microsoft is separating credential administration for a class of agents from the authorization and audit trail for each deployed agent.
Dataverse agent users are the second half of the arrangement. An Entra identity alone is not sufficient to access CRM tables, custom tables, or Dataverse APIs in a Power Platform environment. An administrator must add that Entra identity to the particular environment as an Entra agent user, then assign Dataverse security roles.
The consequence is useful but easy to miss in the marketing language: Entra Agent ID does not automatically make an agent least-privileged. It gives an organization a cleaner identity object to which least privilege can be applied. The real access boundary remains the Dataverse security role, including its table-level privileges, scope, and any field-security profile that applies to the data the agent will handle.
An agent that can update Leads, create Activities, and change Lead Status still needs those permissions designed deliberately. Giving it an existing broad sales role because it is convenient defeats the point of moving away from shared application identities.
The Existing-Agent Gap Is the Operational Catch
Microsoft’s August blog advises administrators to create or enable an agent identity, add it to the target Dataverse environment, and assign a dedicated security role. That is sound advice for a scoped proof of concept. It leaves out the transition problem facing organizations that already have Copilot Studio agents and Power Platform automations in service.Microsoft’s Copilot Studio documentation now makes the distinction explicit: agents created before the July 2026 Entra Agent ID rollout remain on app registrations, with migration promised for a future date. Microsoft also says governance capabilities continue to work for both Agent IDs and app registration IDs during this transition, but it has not published a migration schedule in the documentation reviewed for this article.
That means administrators should not assume that a new Entra-based policy, agent inventory process, or review workflow has automatically converted their existing fleet into per-agent identities. It has not. An organization could have a carefully governed new agent alongside an older agent using a standard app registration, with materially different identity metadata and lifecycle behavior.
This is especially relevant where teams have built agents outside Copilot Studio. Microsoft Entra Agent ID supports Microsoft and non-Microsoft agent platforms, but the method for giving an external agent a governed identity depends on the identity platform’s SDK, workload identity federation, or another supported integration path. The Dataverse preview announcement should therefore not be mistaken for an automatic identity upgrade for every application that calls Dataverse.
For administrators, the immediate inventory question is not simply “Which agents access Dataverse?” It is “Which ones have an Entra Agent ID, which still use app registrations, and which identity actually appears in each environment’s security configuration?”
Auditability Improves, but It Is Not a Complete Activity Ledger by Itself
Microsoft is right that the new model improves attribution. In Entra audit logs, agent identities are distinguished from ordinary identities through agent-specific metadata. Microsoft documents separate values for an agent identity blueprint, a running agent identity, and an optional agent user account. Entra sign-in logs also include anagentSignIn event type and filters for agent involvement.That provides a better trail for identity administration and token activity: who created or changed an agent identity, which blueprint it belongs to, whether it was enabled or disabled, and when it authenticated. It gives security teams a named nonhuman actor to investigate rather than a generic integration account whose ownership may be unclear.
It does not mean Entra logs alone explain every business action an agent performed in Dataverse. Entra’s own logging documentation describes identity and sign-in events; Dataverse auditing and environment-level monitoring remain the place to establish what record was read or changed, what values moved, and whether an action complied with the business process. The two sources of evidence need to be correlated.
That distinction becomes material during an incident. If an agent changes hundreds of lead records, the Entra trail can identify the agent identity, its blueprint, and its authentication context. Dataverse audit records and application telemetry must supply the transaction-level evidence: which records changed, what was changed, whether a human approval step was bypassed, and whether the assigned role allowed more access than intended.
Microsoft’s sales-development example—researching prospects, preparing outreach, following up, and updating lead status—is a reasonable test case precisely because it exercises a narrow set of tables and operations. It is also a useful warning against assigning permission based on a job title. “Sales development” is not a security role. A secure design would isolate the agent’s eligible lead segment, forbid access to unrelated opportunities and account data, restrict creation rights to the few activity types it needs, and prevent updates to sensitive fields unless the workflow demonstrably requires them.
Conditional Access and DLP Still Sit Outside the Role Design
The Dataverse agent user controls access inside the environment. Entra Agent ID adds controls above that layer, including Conditional Access targeting, sign-in logging, identity governance, sponsors, and lifecycle management. Microsoft says Copilot Studio also exposes connector permissions on the agent’s Entra identity so Entra and Microsoft 365 administrators can review which Power Platform connectors an agent is configured to call.Those connector permissions are not an escape hatch around Power Platform governance. Microsoft’s Copilot Studio documentation says connector scopes are revalidated by the connector runtime against Advanced Connector Policies and data loss prevention policies. In practical terms, an agent identity can improve visibility and let administrators apply Entra conditions, but it should be treated as an additional enforcement and observability layer—not a replacement for connector controls, environment strategy, DLP, or Dataverse roles.
Licensing is another area where the announcement remains high-level. Microsoft says Entra Agent ID as a platform is available to Microsoft Entra customers, but its documentation lists licensing requirements for extending certain Entra protections to agents. Conditional Access for agents requires Entra ID P1, Identity Protection requires Entra ID P2, and broader Agent 365 scenarios carry separate licensing requirements. The Power Platform blog does not state the licensing, regional availability, or production-support boundaries for Dataverse agent users beyond its preview warning.
That omission matters for an IT team planning a pilot. The feature can be evaluated in a non-production environment, but an organization should validate the exact tenant licensing and whether the intended Entra protection features are available before presenting Agent ID as a completed compliance control.
Treat the Preview as a Security-Role Exercise
The strongest use of the public preview is a contained agent that has a measurable task, limited data access, and a named human sponsor. Start with one environment and create one purpose-built Dataverse security role rather than cloning an existing user role.A credible pilot should establish the following before the agent is allowed to act on live business data:
- The agent should have a documented business owner and a separate security owner who can disable or re-scope it.
- The Dataverse role should permit only the tables, operations, and record scopes required for the test scenario.
- The team should test denied operations as aggressively as approved operations, including attempts to access unrelated tables and sensitive columns.
- Entra sign-in and audit logs should be reviewed alongside Dataverse auditing so that identity events can be matched to record changes.
- Existing agents using app registrations should be inventoried separately rather than presumed to have been migrated into the new model.
References
- Primary source: Microsoft
Published: 2026-08-06T14:00:00+00:00
Loading…
www.microsoft.com - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: learn.microsoft.com
Overview of agent identities in Microsoft Entra | Microsoft Learn
Learn about agent identities in Microsoft Entra ID, specialized identity constructs that enable secure authentication and authorization for AI agents in enterprise environments.learn.microsoft.com