What it does
An agent touching Dataverse is a caller like any other, so governance comes down to three questions: which identity is on the request, what that identity is allowed to do, and what the trail looks like afterwards. Microsoft Entra Agent ID supplies the identity, Dataverse security roles supply the authorisation, and Dataverse auditing plus Purview supply the trail.
Key facts
- Every agent created in Copilot Studio gets an agent identity in Microsoft Entra — a service principal with an "Agent" subtype. The user who created it is recorded as its sponsor.
- Agent identities are created and managed by a Microsoft-owned blueprint principal using federated identity credentials. Nobody in the tenant, including tenant administrators, can mint tokens as an agent identity.
- Agents can act autonomously using rights granted directly to the agent identity, or with delegated access acting on behalf of a user with rights the user controls.
- Where a system needs an agent to look like a person, agent identities can be paired with an agent user account — a special Entra user account in a one-to-one relationship with the agent identity.
- The 2026 wave 1 Dataverse release plan describes native agent identities in Dataverse giving audit trails that distinguish agent actions from user actions. Treat that as in-flight for the April–September 2026 wave rather than a settled capability.
- Agent creation can't be disabled tenant-wide. Microsoft's documented guidance is to use data policies to stop people chatting with agents instead.
- Copilot Studio auditing surfaces through Purview — who built an agent, who co-owns it, who changed it, whether public endpoints are exposed.
- Extending Entra security features (Conditional Access, ID Protection, ID Governance, network controls) to agents needs a Microsoft Agent 365 licence, alongside Microsoft 365 E7, or E5 plus Agent 365, or the standalone Entra ID P1/P2 options Microsoft lists on the Agent ID documentation.
When to use / skip
This isn't optional once agents are writing to Dataverse — the question is only how much structure you put in place before or after the first incident. The proportionate version for most clients: agents live in named environments, each agent has a documented identity and a security role scoped to what it actually needs, writes go through a defined table set, and someone reviews the agent inventory monthly.
What you should resist is treating agent governance as a separate programme. It's the same environment strategy, the same security-role discipline and the same solution ALM the client should already have. If those are weak, agents don't create a new problem so much as make an existing one visible and fast.
Configuration decisions
- Autonomous agent identity versus delegated user context. Delegated is the safer default because the user's own row-level access still applies; autonomous is what you need for unattended work and it needs a real role design.
- Which security role each agent identity holds. Copying a broad role like System Customizer because it works is the mistake this whole area exists to prevent.
- Which environments agents may be created in, and how the default environment is handled given creation can't be blocked.
- Whether Managed Environments is in play, since several of the governance controls (MCP connector policies among them) depend on it.
- Who owns the agent inventory review, and what the decommissioning path is for an agent whose sponsor has left.
Gotchas
- You can't stop people creating agents. Governance plans built on prevention fail immediately; plans built on data policies, environment scoping and inventory hold up.
- The sponsor relationship is a record of who created the agent, not an operational owner. When that person changes role, nothing breaks and nothing prompts anyone — the agent just carries on.
- Maker-provided credentials are a live oversharing risk. Where an agent uses connections created by the maker, the agent's effective reach is the maker's reach, not the user's.
- Agent identities are designed to be created and destroyed in volume. Governance processes that assume a human reviews each one don't survive contact with the scale Entra is built for.
- Auditing an agent's Dataverse writes and auditing the agent's conversation are two different systems in two different portals. Nobody has one pane of glass here yet.
Consultant notes
- Start the conversation with the client's existing identity and privileged-access model. The security team usually has strong opinions about non-human identities already, and agents land squarely in that policy.
- Write down, per agent, the identity, the role, the tables it can write to and the owner. It's a boring artefact and it's the single most useful thing you'll produce in this area.
- Flag the licensing shape early. Applying Conditional Access and ID Governance to agents is a licensed capability, and clients assume it comes with the agent.
- Expect this to change under you. Native agent identities in Dataverse were still being delivered through the 2026 wave 1 window, so verify current behaviour before you commit design decisions to a document.
Re-verify what "native agent identities in Dataverse" actually does once wave 1 finishes shipping — the audit story depends on it