Whose identity is it? An architecture question for any agent

In Copilot Studio the identity part isn't a choice anymore.
Since July 2026, every new Copilot Studio agent gets a Microsoft Entra Agent ID at creation, automatically, no opt-out. It exists whether you plan it or not.
The architecture decision is no longer whether an agent should have an identity, it's what that identity does.
The decision depends on what kind of system you are designing:
Delegated access: the agent borrows the user's rights. The agent acts on behalf of the signed-in person and can only reach what that person can reach. Ask it about your customers, and it sees your customers, not your colleague's. The user's existing permissions are the security boundary, and every action still traces back to a human context.
Autonomous access: the agent owns its rights. Permissions are granted directly to the agent's identity: security roles in Dataverse (via the agent-user preview that shipped in August 2026), Graph application permissions, whatever its task needs. It can act with nobody signed in, and the audit trail names the agent itself.
Delegated when the agent assists a person. Autonomous when the agent is the actor. A simple concept that can easily turn messy when ignored.
Where an agent should have its own access
Nobody is signed in. An agent that processes invoices overnight, watches a queue, or reacts to events has no user to borrow rights from. Before agent identities, admins covered this with shared service accounts and app registrations, both designed for stable, long-lived integrations rather than agents that multiply and change. Background work needs its own principal, and now there's a purpose-built one.
The audit trail must name the agent. In regulated work, "who changed this record?" needs a specific answer. A Dataverse agent user makes changes attributable to the agent, distinguishable from users and from conventional application accounts. If your compliance story currently contains a service account that half the department's automations share, you already know why this matters: that account's audit trail is impossible to trace back to one responsible actor.
The agent needs access no single user should hold. An agent that aggregates across departments for a report would otherwise run under some power user's over-privileged account, coupling a business process to one person's employment and giving malicious actors a great target. Its own identity with a purpose-built role decouples that, and the role can be reviewed on its own terms.
Where it adds nothing (or makes things worse)
The agent answers questions in the user's context. A help-desk agent, a "summarise my cases" agent, a knowledge assistant. Delegated access already gives you the right boundary for free: the user's permissions. Granting that agent standalone data access adds a bypass, not new capability. Content the user is not allowed to see can flow through the agent's broader access into the user's chat window. You'd be re-creating the oversharing problem — content technically reachable by too many people, now actively surfaced by AI.
Personal and experimental agents. Setting up an agent user, designing a security role, and wiring up access reviews for something that may not survive the month is governance theatre. Save the ceremony for agents that touch shared data or run without supervision.
What an identity cannot do for you
An agent with a perfectly scoped security role can still misread a prompt and act confidently on garbage, and the audit log will attribute the garbage. Authentication, authorisation, and verified action are three different questions. "Should this specific action happen?" is still answered by approval steps and human checkpoints, not identity.
It also doesn't replace your data governance. Sensitivity labels, data loss prevention, connector policies all still do their jobs; the agent identity gives them a better subject to act on, nothing more.
What it costs
Nothing here is free. The bill has four lines:
Role design work. Least privilege for a nonhuman is real effort. Someone has to work out what "narrowest role that covers the task" means for each autonomous agent, build that role, and maintain it as the agent's job evolves. Multiply by the number of agents your makers are about to create.
Lifecycle ownership. Every agent identity requires a human sponsor accountable for its purpose and access reviews. Sponsors should attest every 6 to 12 months that the agent is still needed, plus a recurring check for orphaned agents. That's a standing operational commitment, not just a one-time setup task. If your organisation already struggles to review human access, be realistic about adding a second population.
Licensing. The identity platform itself is included for all Entra customers. The security features that make identities enforceable are not: Conditional Access for agents needs Entra ID P1 plus an Agent 365 licence per user; risk detection needs P2 plus Agent 365; it's all bundled in Microsoft 365 E7. If the business case for an autonomous agent assumes Conditional Access policies around it, the case needs to carry that licensing line.
Preview risk. Dataverse agent users are public preview as of August 2026: not for production, functionality may be restricted, details may change. Architect for it now, pilot it in dev, but don't depend on it in production.
The five questions to design around
Put these in your design template and most agent-identity decisions answer themselves:
- Does the agent act when no user is present? Yes → autonomous access, own permissions.
- When it changes data, whose name belongs in the audit log? "The agent's" → agent user with its own security role.
- Does it need reach that no single user should have? Yes → own identity with a purpose-built role.
- Is it only assisting a signed-in person with their own data? Yes → delegated access.
- Who sponsors it, and who reviews its access next year? No answer → not ready for autonomous access, no matter how cool the demo looked.
An agent identity buys you accountability, but the judgement is still yours. Spend accordingly.

0 comments