In Short: Agents Are Identities Now
The moment an AI agent can query a database, call an API or send a message, it stops being a feature and becomes an actor in your estate - something that authenticates, holds permissions and leaves an audit trail, or dangerously does not. Microsoft's answer is Entra Agent ID: AI agents receive real directory identities, visible and governable in the same plane as users and service principals.
This is the least glamorous corner of the AI stack and, for anyone accountable for security or compliance, the most consequential. Organisations learned over two decades what ungoverned service accounts cost. Agents are that story again, at a faster growth rate and with the ability to write emails.
Why the Old Workarounds Break
Before first-class agent identity, agents ran on borrowed credentials: the maker's own account, a shared service principal, an API key in a config. Every one of those patterns fails a familiar way.
- The maker leaves; the agent keeps their access, or silently dies
- The shared principal accumulates permissions across ten agents; nobody can say which agent needs what
- The audit log attributes agent actions to a human who never took them
- Offboarding processes see no agents at all, because agents were never in the directory
Entra Agent ID exists to end that: each agent an identity, with an owner, a lifecycle, permissions of its own and an audit trail that names it. Conditional access and identity protection extend to the agent population, so the controls your security team already runs gain coverage rather than a parallel system.
The Layered Model Worth Understanding
Agent governance in the Microsoft stack works in layers, and confusion between them causes most of the arguments.
Identity - the agent exists in the directory, owned, lifecycle-managed (Entra Agent ID).
Data access - what the agent may reach when it runs. In Fabric, agent queries honour workspace permissions, row-level security and Purview policies exactly as human access does; a data agent cannot see what its consumer could not. Sensitivity labels and DLP travel with the data through Purview's AI controls.
Capability - what the agent may do: which tools, which connectors, which actions. Copilot Studio governs this through Power Platform admin policies; Foundry through Azure policy and the tools you register.
Observability - what the agent did: logs, traces, evaluation. Without this layer the other three are assertions.
The practical insight: most incidents are failures of the second and third layers configured casually, discovered through the fourth layer configured never.
A Governance Baseline You Can Actually Run
- Inventory first. Enumerate agents across Copilot Studio, Foundry and Fabric; assign a named owner to each; retire the orphans. Expect surprises
- Least privilege as default. An agent gets the data access its task requires, never its maker's access. Scope one subject area at a time
- Identity per agent. No shared principals across agents; one identity, one purpose, one audit trail
- Review on a schedule. Quarterly access reviews for agents, like service accounts; alert on permission growth
- Test the security model under agent access. RLS and label enforcement should be verified with the agent asking, not assumed, before rollout - the same discipline as preparing models for AI
- Log and read the logs. Agent actions belong in the same monitoring the SOC already watches
None of this is new philosophy; it is identity hygiene applied to a new population. The organisations that struggle are not short of tooling, they are short of inventory and ownership. Start there, this quarter, while the agent count is still small enough to enumerate over coffee.
Sources and Further Reading
Frequently asked
Microsoft's extension of Entra identity management to AI agents: agents built in Copilot Studio, Foundry and across the Microsoft stack receive directory identities, so administrators can see them, control what they access, and apply governance the way they do for human and service accounts.
Because they act: querying data, calling APIs, triggering workflows. Anything that acts needs to be authenticated, authorised and auditable. Without first-class identities, agents run under borrowed credentials - the maker's account, a shared service principal - which is exactly how shadow access accumulates.
Over-permissioning. Agents are frequently granted the access of the person who built them, which usually exceeds what the agent's task requires. The discipline is the old one, least privilege, applied to a new population that grows faster than service accounts ever did.
Yes: in the Microsoft stack, agent queries against governed data honour workspace permissions, row-level security and Purview policies. Identity governance sits a layer above: knowing which agents exist, who owns them, what they may reach, and switching them off when they are orphaned.
Inventory. Most organisations cannot list their agents, let alone their permissions. Enumerate what exists across Copilot Studio, Foundry and Fabric, assign owners, remove the orphans, then set least-privilege standards and review access on a schedule, exactly as you would for service accounts.
