Governing AI agent identities in Entra: sponsors, access packages and expiry

Most tenants already have a graveyard of service principals: apps with secrets nobody rotates, permissions nobody remembers granting, and owners who left years ago. AI agents could make that much worse, because they're easy to create and they multiply. A team that builds one support agent this month may run fifty next quarter.

Microsoft Entra Agent ID gives each agent its own identity, and with it the governance hooks you'd want for any identity: a named person who's accountable, access that's requested and approved, assignments that expire, and automatic hand-over when people move on. None of it happens unless you set it up. This post walks through the pieces.

Owners, sponsors and managers are different jobs

Agent ID splits responsibility three ways. Getting this right first makes everything else simpler.

The sponsor is the important one for governance. Sponsors can disable an agent, soft-delete it and change its sponsors, and they get the expiry notices for its access. They can't change its settings, and they can't re-enable or restore an agent they've disabled or deleted. That has to go back to an owner or an administrator, which is a sensible brake on a business user switching things on and off.

Rules worth knowing about sponsors

• Someone is always set. If a person creates an agent identity and names no sponsor, they become its sponsor. If they name someone else, they aren't added. An app creating agents with app-only permissions must set at least one sponsor itself.
• Use groups, but the right kind. An agent identity or blueprint can have up to 100 sponsors, no more than 5 of them groups. Dynamic membership groups and assigned Microsoft 365 groups work. Role-assignable groups and assigned security groups don't. Every member of a sponsoring group gets sponsor rights.
• Match them up. If an agent has both an agent identity and an agent user account, Microsoft recommends the same user or group as sponsor on both, with the agent identity's sponsor treated as the primary one.
• These aren't admin roles. Owner and sponsor are set per agent, separately from Entra roles such as Agent ID Administrator. Being a sponsor of one agent gives you nothing over the others.

Give agents access through access packages

The quickest way to give an agent what it needs is to grant it directly: add it to a group, consent to a Graph permission. That's also how you end up with access nobody can explain a year later. Entitlement management access packages are the alternative. In Microsoft's words, they make sure "agent access assignments are intentional, auditable, and time-bound".

They also scale. If you run a fleet of customer support agents that all need the same groups and permissions, one access package covers all of them.

An access package for agents can include:

• Security group memberships
• Microsoft Entra roles, from the list of roles allowed for agents
• API permissions, application or delegated, for Microsoft Graph or your own apps (in preview)

Don't add application roles, SAP roles or SharePoint Online site roles. That also means you can't reuse an existing package that contains any of them, so create a new one for agents.

Set one up

You need at least Identity Governance Administrator. Adding API permissions or directory roles to a package needs Global Administrator, and doing so marks the catalog as privileged.

1. In the Entra admin centre, go to ID Governance › Entitlement management › Access packages › New access package, and pick a catalog.
2. Under Resource roles, add the groups, roles or API permissions.
3. Under Requests, choose For users, service principals, and agent identities in your directory, then All agents. If some of your agents still run as ordinary service principals, add a second policy for All Service principals.
4. Set up approval stages. A sensible default is one stage, approved by the resource owner.
5. On Lifecycle, set how long assignments last. This is the part that matters most.

Who asks, and what happens at expiry

There are three ways an agent gets assigned:

• The agent asks for itself, by creating an access package assignment request through Microsoft Graph.
• Its sponsor asks on its behalf, which keeps a person in the loop.
• An administrator assigns it directly.

As the end date approaches, the sponsor is notified. If the policy allows it, they can ask for an extension, which can send it back through approval. If nobody acts, the assignment expires on its end date and the agent loses the access. That's the behaviour you want: an abandoned agent quietly loses its permissions instead of keeping them for ever.

When a sponsor moves or leaves

A sponsor who leaves is how agents become orphans. Microsoft's documentation says Entra reassigns sponsorship to the departing sponsor's manager. Lifecycle Workflows has three tasks so you can control and announce that hand-over as part of your existing mover and leaver process:

All three are mover and leaver tasks, so they're only available in mover or leaver workflow templates. Add them to the leaver workflow you already run, under ID Governance › Lifecycle workflows › Workflows, with at least Lifecycle Workflows Administrator. Then the manager knows they've inherited a set of agents, and can keep them, hand them on or retire them.

Know what agents you have

Go to Entra ID › Agents › Agent identities. Add the Owners and Sponsors and Blueprint App ID columns and look for agents whose only sponsor is someone who's already left, or a group nobody manages. Viewing the list needs no admin role. Changing agents needs Agent ID Administrator or Cloud Application Administrator, unless you own the agent.

To see what agents are actually doing, filter the sign-in logs for agent identities. Microsoft documents this query against the Graph beta endpoint:

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and agent/agentType eq 'AgentIdentity'

For the wider picture of who holds which admin roles, including any you've given to agents, the Access Map shows Entra and Azure roles side by side.

Retiring an agent: disable first

Microsoft recommends disabling before deleting. Disabling stops the agent getting tokens straight away and leaves everything in place, so it's easy to undo. You can disable one agent, select several and disable them in a batch, or disable a whole blueprint, which also stops new agents being created from it.

Deleting is less forgiving:

• Deleting a blueprint cascades. Entra removes every agent identity and agent user account created from it. The clean-up runs in the background and can take hours or days.
• You have 30 days. Deleted objects can be restored for 30 days. Restore the blueprint principal before the clean-up runs and its agents are untouched. Restore it after, and you have to restore each agent one by one.
• Deleted agents still count. Soft-deleted agents count towards your directory quota, and towards the limit of 250 agent identities per blueprint for apps using app-only permissions, until they're permanently deleted.
• Expect odd audit entries. Cascade deletions show up as Delete service principal, initiated by an application called Delete Agent Identities Task, with no actor app ID. That's Entra's own background process.

Be careful with blanket disables. Microsoft warns that disabling agent identities across the board can break existing agents, degrade Microsoft product experiences, and push teams towards less transparent app or service principal identities. Check the impact first.

Licensing

Microsoft lists the governance features for agents (access packages, sponsor tasks in Lifecycle Workflows) as needing either:

• Microsoft 365 E7, which includes Agent 365 and the Microsoft Entra Suite, or
• Microsoft Agent 365 with at least Microsoft Entra ID P1 or Microsoft 365 E3.

Check the ID Governance licensing page against what you own before you build workflows around these features.

Checklist

• Every agent identity has a sponsor who still works here, ideally a dynamic or Microsoft 365 group rather than one person
• The same sponsor is set on an agent's identity and its user account
• New agent access comes through access packages with an end date, not direct grants
• The sponsor tasks are in your leaver (and mover) Lifecycle Workflows
• Someone reviews Entra ID › Agents › Agent identities every month
• Agents are disabled before they're deleted, and blueprints are deleted only when retiring every agent made from them