Quick answer. Governing non-human identities in Microsoft Entra means inventorying every application, service principal, managed identity and AI agent identity, and naming a human accountable for each. Keep access least-privileged and reviewed, replace stored secrets with managed identities or federation where supported, and govern agents through Entra Agent ID.
If you arrived from Microsoft 365 Access Governance for AI Readiness already knowing that non-human actors are the factor that page calls the skipped one, the question here is the one that page hands off: who owns those identities, and what a program to govern them looks like. An access program built around people who sign in leaves these identities without a named owner unless someone assigns one, and an auditor can ask who that owner is.
What Counts as a Non-Human Identity in Entra
If you are building the inventory, start from Microsoft’s own terms. Microsoft’s What are workload identities? article, read on 2026-09-22, says: “In Microsoft Entra, workload identities are applications, service principals, and managed identities.” It places them in a wider group: “Workload identities and device identities together make up a group called machine (or non-human) identities.” And it defines the third kind directly: “A managed identity is a special type of service principal that eliminates the need for developers to manage credentials.”
The difference between an application and a service principal is where ownership gets lost, and the same What are workload identities? article draws it: “An application object is used as a template to create a service principal object in every tenant where the application is used.” Of the service principal, it says: “The service principal object defines what the app can actually do in a specific tenant, who can access the app, and what resources the app can access.” In plain terms, the app registration is the definition and the service principal is the instance in your tenant that holds the access. An application registered by another organization still has a service principal in your tenant, so the owner you name has to cover the service principal your tenant grants access to, whoever created the registration.
AI agents add a fourth kind. Microsoft’s Governing Agent Identities article, read on 2026-09-22, says: “Agent identities are accounts within Microsoft Entra ID that provide unique identification and authentication capabilities for AI agents.”
Why These Identities Fall Outside a Program Built for People
If your access reviews were designed around employees, Microsoft’s What are workload identities? article sets out the difference in the identity type itself: “Human users typically have a single identity used to access a broad range of resources. Unlike a human user, a software workload may deal with multiple credentials to access different resources and those credentials need to be stored securely. It’s also hard to track when a workload identity is created or when it should be revoked.” Nothing signs in as these identities in the way a person does, so a joiner, mover and leaver process keyed to people has no event that reaches a workload identity unless a person is tied to it as its owner, or, for an agent identity, its sponsor.
Five Governance Decisions, in Order
If you have to show an auditor that each non-human identity is accountable to someone, five decisions apply to every class of identity above: inventory, owner, access, credentials and retirement. Each is a decision your organization makes; none is a configuration step.
Inventory. Decide what the inventory covers and who keeps it current: applications and their registrations, service principals (including those for applications registered by other organizations), managed identities and agent identities. Count an agent built on a standard app registration as an application and service principal unless and until it moves to Agent ID.
Owner. Decide who the named, accountable human is for each identity, and what happens when that person leaves. For agents, Microsoft’s Governing Agent Identities article gives that role a name: “Sponsors of agent identities are human users accountable for making decisions about its lifecycle and access.” It also states: “If the sponsor is leaving the organization, sponsorship of the agent identities is automatically transferred to their manager.”
Access. Decide what least-privileged access looks like for each identity and who reviews it. Microsoft’s What are workload identities? article lists one review scenario: “Review service principals and applications that are assigned to privileged directory roles in Microsoft Entra ID using access reviews for service principals.” For agents, the Governing Agent Identities article describes access package assignments that carry an expiry date, and says: “If the sponsor takes no action, the access package assignment automatically expires on its end date, and the agent identity loses access to the target resources.”
Credentials. Decide which identities may still hold a stored secret or certificate, who holds it, and which move to credential-free access first. Microsoft’s What are workload identities? article names two routes: “Access Microsoft Entra protected resources without needing to manage secrets for workloads that run on Azure using managed identities.” For workloads outside Azure, it names workload identity federation “for supported scenarios such as GitHub Actions, workloads running on Kubernetes, or workloads running in compute platforms outside of Azure.”
Retirement. Decide who confirms that an identity is no longer needed, and on what trigger: the workload is decommissioned, the owner leaves, or the agent moves to a new identity. The cleanup sequence for stale service principals and application registrations is covered on Establish Identity as a Governed Enterprise Capability.
The owner decision takes precedence over the other four, because each later decision needs a named person to make it; an identity whose owner cannot be found goes to the retirement decision first.
AI Agents and Microsoft Entra Agent ID
If AI agents are already running in your tenant, Microsoft’s What is Microsoft Entra Agent ID? article, read on 2026-09-22, describes the product: “Microsoft Entra Agent ID is a product within Microsoft Entra that provides the platform for creating and managing agent identities and agent identity blueprints. Agent ID is available for all Microsoft Entra customers.” On licensing, the same article says: “Extending Microsoft Entra security features to agents requires Microsoft Agent 365. Agent 365 is included with Microsoft 365 E7 and is available as an add-on to Microsoft E5/A5/Business Premium (or Microsoft Defender Suite + Microsoft Purview Suite).”
On status, Microsoft’s What’s new in Microsoft Entra Agent ID page, read on 2026-09-22, states: “Microsoft Entra Agent ID is now generally available.” The same page labels one creation flow (Preview), in its entry “Create an agent identity blueprint and Create an agent identity (Preview)”, which describes a new wizard in the Microsoft Entra admin center for creating agent identity blueprints and agent identities.
Microsoft’s Governing Agent Identities article says agent identities can “be governed with Microsoft Entra features in the same style as you would govern human identities,” so that “the agents have a responsible person providing oversight throughout the agent lifecycle,” and its license section says that using Microsoft Entra ID Governance for agent identities “requires one of the following license plans”: Microsoft 365 E7, or a “Microsoft Agent 365 license paired with at least Microsoft Entra P1 or Microsoft 365 E3.” The human side of that program is covered in Microsoft Entra ID Governance for Regulated Enterprises: Product Scope, Licensing, and Audit-Defensible Implementation.
If agents were built on standard app registrations, Microsoft’s Migrate custom app registrations to Agent ID article, read on 2026-09-22, explains what they miss: “If you built AI agents by using standard Microsoft Entra app registrations or service principals, your agents authenticate like any other application. They don’t take advantage of agent-specific governance capabilities like Conditional Access policies, centralized audit logging, and lifecycle management that Agent ID provides.” For agents whose code and identity configuration you own, it summarizes the path: “You create Agent ID resources (a blueprint and agent identity), update your application code, and decommission the old identity.” Agents built in Microsoft Copilot Studio have a separate documented migration. The decision left to you is which agents move, in what order, and who is named as the sponsor of each agent identity once it exists.
When an Outside Architect Is Worth It
If ownership of these identities has to be settled and defended to an auditor before more agents are deployed, an outside identity architect can help your team set the five decisions and the owner model, while the identities and their owners stay inside your organization. i3solutions has deep experience implementing identity governance for enterprises in aerospace and defense manufacturing, financial services, and healthcare, including environments with CMMC and ITAR obligations. Delivery is senior and US-based.
Key Takeaways
- Inventory four kinds of non-human identity in Entra: applications and their registrations, service principals, managed identities and agent identities.
- Name an accountable human for each identity; on an agent identity, Microsoft’s term for that person is sponsor.
- Keep access least-privileged, and review the service principals and applications assigned to privileged directory roles.
- Prefer managed identities and workload identity federation over stored secrets wherever Microsoft supports them.
- Microsoft states that Entra Agent ID is generally available, marks its admin center creation wizard with (Preview), and documents a migration for agents built on custom app registrations.
Frequently Asked Questions
How do you govern non-human identities in Microsoft Entra?
If you are responsible for identities that no person signs in as, keep a current inventory of the applications, service principals, managed identities and agent identities in your tenant, and name a human accountable for each one; for agent identities, Microsoft calls that person a sponsor. Keep their access least-privileged, review those assigned to privileged directory roles, move from stored secrets to managed identities or workload identity federation where Microsoft supports it, and bring AI agents under the same program through Microsoft Entra Agent ID.
What is the difference between an app registration and a service principal?
If you are assigning owners, Microsoft describes the application object as the global representation of an application and the service principal as its local instance in a specific tenant, which defines what the application can do there and what it can access. An application used in several tenants has a service principal in each of them, and the access your tenant grants is held by the local one, which is why the owner question attaches to it, and, for an application your organization registered, to the registration as well.
Is Microsoft Entra Agent ID generally available?
If you are planning for AI agents, yes: according to Microsoft’s what’s-new page for Agent ID, read on 2026-09-22, Microsoft Entra Agent ID is generally available, while the admin center wizard for creating agent identity blueprints and agent identities is marked (Preview). Microsoft labels some related capabilities separately, such as automatic creation of agent identities for Copilot Studio agents, which its Governing Agent Identities page marks (preview). And according to Microsoft, agents need Microsoft Agent 365 before Entra security features extend to them. And according to Microsoft’s Governing Agent Identities page, using Microsoft Entra ID Governance for agent identities requires either Microsoft 365 E7 or a “Microsoft Agent 365 license paired with at least Microsoft Entra P1 or Microsoft 365 E3.”
How do agents built on app registrations move to Agent ID?
If your agents authenticate through standard app registrations or service principals, Microsoft documents a migration for agents whose code and identity configuration you own: you create Agent ID resources, a blueprint and an agent identity, update the application code, and decommission the old identity. Microsoft documents a separate migration for agents built in Microsoft Copilot Studio.
Working With i3solutions on Non-Human Identity Governance
If those five decisions have to be settled before more agents reach production, the next step is a conversation about which identities in your tenant have no named owner today.
