Introduction
Identity governance often fails for a simple reason: everybody can see guest accounts, but nobody is responsible for them.
Microsoft Entra ID addresses this problem with the sponsor relationship. A sponsor is a user or group that has business responsibility for another identity. For B2B guests, the sponsor should know why the guest needs access to the tenant and when this access is no longer required. Microsoft is extending the same idea to AI agents through Microsoft Entra Agent ID.
What is an Entra ID sponsor?
For a normal Entra user object, sponsors are mainly intended only for B2B guest users.
A sponsor:
- represents business responsibility for the guest
- helps keep the guest’s information and access up-to-date
- can participate in access-package approvals
- can be used by custom governance applications
Be aware that a sponsor does not automatically receive administrative permissions over the guest.
What is important to mention:
being listed as a sponsor does not allow you to edit, disable or delete the guest account.
The sponsor relationship stores accountability, while roles, API permissions and governance policies provide authorization.
A user can have up to five sponsors. Sponsors can be users or groups. When no sponsor is specified during a normal B2B invitation, the inviter becomes the sponsor automatically.
Sponsors in Microsoft Graph
Microsoft Graph exposes the relationship from both sides.
| Question | Endpoint |
|---|---|
| Who sponsors this user? | GET /users/{id}/sponsors |
| What users does this person sponsor? | GET /users/{id}/sponsorOf |
| Add a sponsor | POST /users/{id}/sponsors/$ref |
| Remove a sponsor | DELETE /users/{id}/sponsors/{sponsor-id}/$ref |
The difference becomes especially relevant when groups are used as sponsors.
/sponsors returns the directly assigned user or group. However, /sponsorOf includes objects that the user sponsors directly and through group membership. Consequently, adding somebody to a sponsor group can change their sponsorOf results without changing the sponsored user object.
Listing a user’s sponsors
The basic request is simple:
GET https://graph.microsoft.com/v1.0/users/{user-id}/sponsors
The response is a collection of directoryObject resources. In practice, each object is currently a user or group.
To get only users who sponsor the guest, you can filter data by casting them to the user type:
GET https://graph.microsoft.com/v1.0/users/{user-id}/sponsors/microsoft.graph.user
To get only groups who sponsor the guest:
GET https://graph.microsoft.com/v1.0/users/{user-id}/sponsors/microsoft.graph.group
Use $select to reduce the response:
GET https://graph.microsoft.com/v1.0/users/{user-id}/sponsors?$select=id,displayName
GET https://graph.microsoft.com/v1.0/users/{user-id}/sponsors/microsoft.graph.user?$select=id,userPrincipalName
GET https://graph.microsoft.com/v1.0/users/{user-id}/sponsors/microsoft.graph.group?$select=id,displayName,description
You can also retrieve the user and expand the relationship:
GET https://graph.microsoft.com/v1.0/users/{user-id}?$select=id,displayName,userType&$expand=sponsors($select=id,displayName)
If the application doesn't have permissions to read the groups, you might see only the id and @odata.type for those objects.
Other properties can be null. This does not mean the sponsor is missing; it means the application has insufficient permission to read the complete sponsor object.
You can expand the sponsors relationship on a list of users:
GET https://graph.microsoft.com/v1.0/users?$expand=sponsors
But you can't filter the users with/without a sponsor. The $filter operator is not supported on the sponsors relationship.
GET https://graph.microsoft.com/v1.0/users?$expand=sponsors
Filtering objects sponsored by a person
The reverse relationship is more powerful:
GET https://graph.microsoft.com/v1.0/users/{sponsor-id}/sponsorOf
It can return:
- users
- agent users
- agent identities
- agent identity blueprints
- agent identity blueprint principals
The casting works for:
- users:
GET https://graph.microsoft.com/v1.0/users/{sponsor-id}/sponsorOf/microsoft.graph.user - agent identities:
GET https://graph.microsoft.com/v1.0/users/{sponsor-id}/sponsorOf/microsoft.graph.agentIdentity - agent identity blueprints:
GET https://graph.microsoft.com/v1.0/users/{sponsor-id}/sponsorOf/microsoft.graph.agentIdentityBlueprint - agent identity blueprint principals:
GET https://graph.microsoft.com/v1.0/users/{sponsor-id}/sponsorOf/microsoft.graph.agentIdentityBlueprintPrincipal
But doesn't work for agent users: GET https://graph.microsoft.com/v1.0/users/{sponsor-id}/sponsorOf/microsoft.graph.agentUser
To return only sponsored B2B guests, use a derived-type filter:
GET https://graph.microsoft.com/v1.0/users/{sponsor-id}/sponsorOf?$filter=microsoft.graph.user/userType eq 'Guest'&$select=id,displayName,userPrincipalName,userType&$count=true
ConsistencyLevel: eventual
The endpoint supports $filter, $count, $select, $expand, $top and $skip.
Adding a sponsor
A sponsor is added by creating a reference to a user or group. When you invite a B2B guest, you are automatically assigned as the sponsor. For the guests that were added before this feature was available, you can assign a sponsor through the Graph API.
Add a user
POST https://graph.microsoft.com/v1.0/users/{guest-id}/sponsors/$ref
Content-Type: application/json
{
"@odata.id": "https://graph.microsoft.com/v1.0/users/{sponsor-id}"
}
What is strange, the guest user can be added as a sponsor of itself. Microsoft does not prevent this, but it is not a recommended practice.
Add a group
POST https://graph.microsoft.com/v1.0/users/{guest-id}/sponsors/$ref
Content-Type: application/json
{
"@odata.id": "https://graph.microsoft.com/v1.0/groups/{group-id}"
}
A successful request returns 204 No Content.
Using a group is often better than assigning one employee. Group ownership can be maintained separately, and a sponsor does not silently disappear when one person changes position.
Removing a sponsor
Use the following request:
DELETE https://graph.microsoft.com/v1.0/users/{guest-id}/sponsors/{sponsor-id}/$ref
The /$ref suffix is critical.
Be aware one thing...if you omit it, Graph might delete the sponsor directory object itself, not only the relationship, when the application has sufficient permissions. For example, a sponsor who is a user could be deleted with User.ReadWrite.All.
Required permissions
Permissions are not completely symmetrical.
| Operation | Delegated permission | Application permission |
|---|---|---|
| List sponsors | User.Read |
User.Read.All |
| Add or remove sponsor | User.ReadWrite.All |
User.ReadWrite.All |
List sponsorOf |
User.Read |
Not supported |
For delegated calls to list sponsors, the signed-in user also needs a supported Entra role—such as Guest Inviter, Directory Readers or User Administrator—or a custom role containing microsoft.directory/users/sponsors/read.
Updates require Directory Writers, User Administrator or an appropriate custom role with microsoft.directory/users/sponsors/update. Agent users also support Agent ID Administrator and dedicated Agent ID permissions.
The unusual limitation is /sponsorOf: application permissions are not supported. An unattended application therefore cannot use this endpoint to ask what every employee sponsors.
Sponsors in Microsoft Entra Agent ID
Microsoft Entra Agent ID introduces three administrative relationships:
- Owners: handle technical configuration, credentials and operational administration
- Sponsors: hold business accountability and make lifecycle decisions
- Managers: place agents into the organizational hierarchy and can request access packages for them
The main design principle is separation of duties. A developer might technically own an agent, while a business manager sponsors it and decides whether it is still needed.
Agent Identity sponsors are more powerful than normal user sponsors. They can disable or soft-delete an agent identity, modify sponsors and participate in lifecycle operations. Normal user sponsors have no comparable built-in authority over the sponsored user.
Do not mix the two sponsor models
An agent can have both:
- an agent identity;
- an agent user account used to access user-oriented services.
Each can have separate sponsors.
| Agent user account | Agent identity or blueprint | |
|---|---|---|
| Sponsor limit | 5 | 100, including at most 5 groups |
| Supported groups | Any group | Only selected group types |
| Required | No | Yes for identities and blueprints |
| Direct management rights | None | Limited lifecycle rights |
| Primary purpose | User-account accountability | Agent business governance |
It's recommended to assign the same sponsor to both objects when the agent uses an agent user account. Otherwise, one person might be responsible for the agent identity while nobody monitors its associated user access.
For delegated agent creation, the calling user becomes the sponsor when no sponsor is supplied. If explicit sponsors are provided, the caller is not added automatically. App-only creation must always specify at least one supported sponsor.
Useful app to build
Even the APIs are small, they enable useful governance solutions.
Sponsor coverage dashboard
You can build a dashboard showing:
- guests without sponsors
- guests with disabled sponsors
- guests sponsored only by one individual
- sponsors responsible for unusually many guests
- sponsorship relationships not reviewed for a defined period
This provides a measurable governance metric instead of another static policy document.
Employee offboarding assistant
When an employee leaves, the application can discover their sponsored identities, suggest replacement sponsors and transfer relationships.
Because app-only access to /sponsorOf is unavailable, an unattended version should build its index from each guest’s /sponsors relationship.
SharePoint guest remediation
Microsoft documents a known limitation: when SharePoint sharing creates a new external user, a sponsor is not automatically assigned.
A scheduled service can detect recently created guests without sponsors, identify the sharing-site owner or requestor, and create a remediation task. I would avoid blindly assigning the SharePoint user as sponsor without confirmation, because the person sharing one document is not always the correct long-term business owner.
Access-package approval portal
Sponsors can be used as approvers in entitlement management. A custom portal could show sponsors:
- pending access requests
- current access packages
- last sign-in and review information
- contract or project end date
- a recommendation to approve, reject or extend access The application supplies the workflow; the sponsor field supplies accountability.
Conclusion
Sponsors do not replace access reviews, entitlement management, Conditional Access or proper offboarding. They answer a different question: who can explain why this identity still exists?
For B2B guests, this creates human accountability around external access. For AI agents, it separates technical operation from business responsibility. The API is simple enough to adopt gradually, but the best results come when sponsorship is connected to onboarding, periodic review and offboarding—not treated as one more optional directory field.
