Microsoft Ownerless Agents: The silent risk in your Entra tenant

AI agents are being deployed faster than they are being governed. Every agent created in Microsoft Copilot Studio or Microsoft Foundry becomes an identity in Microsoft Entra ID, capable of accessing organizational data, calling APIs, and acting autonomously on behalf of users.

Unlike user accounts, agents do not have a manager. There is no automatic assignment of accountability when an agent is created. Unless explicitly configured, an agent can exist in your tenant with no one responsible for it.

An ownerless agent means:

  • No one is managing its credentials or secret rotation
  • No one reviews whether its permissions are still appropriate
  • No one notices when it behaves anomalously
  • No one decommissions it when the project ends

The agent continues to run, and continues to have access, indefinitely. This blog post explains what ownerless and sponsorless agents are, why they are a security risk, and how to detect and remediate them in your Microsoft Entra tenant.

Table of Contents

  1. Owner vs. Sponsor, What is the difference?
  2. Finding Ownerless and Sponsor-less Agents
  3. Recommendation
  4. Conclusion

Disclaimer: This blog post is provided for informational purposes only. While every effort has been made to ensure accuracy, implementation of these features should be performed by qualified administrators in accordance with your organization’s security and change management policies. The author is not responsible for any issues, data loss, or security incidents that may occur from following this guidance. Always test in a non-production environment first and consult official Microsoft documentation before implementing security features in production.

Owner vs. Sponsor, What is the difference?

Microsoft Entra Agent Identities support two distinct accountability roles:

Owner is the technical administrator responsible for operational management, setup, configuration, and credential management. Think of the Owner as the person who keeps the agent running correctly.

Sponsor is the business representative accountable for the agent’s purpose and lifecycle. The Sponsor is the person who can answer: “Why does this agent exist, and is it still needed?”

Both roles are optional at creation time. Both are critical for governance. Without a Sponsor, no one can request or approve Access Packages on behalf of the agent. Without an Owner, credentials go unmanaged and anomalies go unnoticed.

Finding Ownerless and Sponsor-less Agents

Via the Entra portal: Navigate to Entra ID > Agent ID (Preview) > All agent Identities (Preview). The overview shows all agents in your tenant. Add the Agent Blueprint ID column to distinguish modern agents (with a Blueprint ID) from classic agents (Service Principals).

For modern agents, inspect the details of each agent to verify whether an Owner and Sponsor are assigned.

Image 1: Setting an Owner or Sponsor using the Entra portal

Via Microsoft Graph API: For scale, use PowerShell to query all Agent Identities and report on missing Owners and Sponsors. Find all Agent Identities without a Sponsor and/or Owner:

Connect-MgGraph -Scopes "AgentIdentity.Read.All"
$agents = Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/beta/servicePrincipals/microsoft.graph.agentIdentity" `
-OutputType PSObject
foreach ($agent in $agents.value) {
$owners = Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/beta/servicePrincipals/$($agent.id)/owners" `
-OutputType PSObject
$sponsors = Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/beta/servicePrincipals/$($agent.id)/sponsors" `
-OutputType PSObject
$noOwner = $owners.value.Count -eq 0
$noSponsor = $sponsors.value.Count -eq 0
if ($noOwner -or $noSponsor) {
$flags = @()
if ($noOwner) { $flags += "No Owner" }
if ($noSponsor) { $flags += "No Sponsor" }
Write-Host "$($agent.displayName) | ID: $($agent.id) | $($flags -join ', ')" -ForegroundColor Red
}
}
Disconnect-MgGraph
Image 2: Finding agents without an Owner or Sponsor

Recommendation

Owner and Sponsor assignment cannot be technically enforced at creation time, Microsoft does not provide a native policy to make these fields mandatory. The most effective approach is a combination of two controls.

Process control: Require Owner and Sponsor assignment as part of your internal agent publishing or deployment process. For Microsoft Copilot Studio this means a mandatory approval step before production publishing. For Microsoft Foundry this means including Owner and Sponsor binding in your provisioning script. Both controls only work if everyone follows the process, direct creation via the portal or Graph API bypasses them entirely.

Detective control: Run the detection script on a recurring schedule via Azure Automation. Any agent found without an Owner or Sponsor triggers an alert for immediate remediation.

Neither control alone is sufficient. The process prevents the gap from occurring; the detection script catches what the process misses.

Assign an Owner and Sponsor to an existing agent:

Connect-MgGraph -Scopes "AgentIdentity.ReadWrite.All"
$agentId = "<Agent-Object-ID>"
$assignOwner = $true # Set to $false to skip
$assignSponsor = $true # Set to $false to skip
$ownerUserId = "<Owner-User-ID>"
$sponsorUserId = "<Sponsor-User-ID>"
if ($assignOwner) {
$existingOwners = Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/beta/servicePrincipals/$agentId/owners" `
-OutputType PSObject
$alreadyOwner = $existingOwners.value | Where-Object { $_.id -eq $ownerUserId }
if ($alreadyOwner) {
Write-Host "Owner already assigned, skipping." -ForegroundColor Yellow
} else {
$ownerBody = @{
"@odata.id" = "https://graph.microsoft.com/beta/users/$ownerUserId"
} | ConvertTo-Json
Invoke-MgGraphRequest -Method POST `
-Uri "https://graph.microsoft.com/beta/servicePrincipals/$agentId/owners/`$ref" `
-Body $ownerBody `
-ContentType "application/json"
Write-Host "Owner assigned successfully." -ForegroundColor Green
}
}
if ($assignSponsor) {
$existingSponsors = Invoke-MgGraphRequest -Method GET `
-Uri "https://graph.microsoft.com/beta/servicePrincipals/$agentId/sponsors" `
-OutputType PSObject
$alreadySponsor = $existingSponsors.value | Where-Object { $_.id -eq $sponsorUserId }
if ($alreadySponsor) {
Write-Host "Sponsor already assigned, skipping." -ForegroundColor Yellow
} else {
$sponsorBody = @{
"@odata.id" = "https://graph.microsoft.com/beta/users/$sponsorUserId"
} | ConvertTo-Json
Invoke-MgGraphRequest -Method POST `
-Uri "https://graph.microsoft.com/beta/servicePrincipals/$agentId/sponsors/`$ref" `
-Body $sponsorBody `
-ContentType "application/json"
Write-Host "Sponsor assigned successfully." -ForegroundColor Green
}
}
Disconnect-MgGraph
Image 3: Setting an Owner or Sponsor to an Agent

Conclusion

An agent without an Owner or Sponsor is an identity without accountability. It can accumulate permissions, run indefinitely, and operate completely outside your governance framework, not because someone made a bad decision, but because no one made any decision at all.

Microsoft makes Owner and Sponsor optional at creation time. That default is a governance risk. The detection script gives you visibility today. The process control reduces the gap tomorrow, but only if consistently followed. Schedule the script to run on a recurring basis so exceptions are caught before they become incidents.

Recommended action: Run the detection script against your tenant. For every agent without an Owner or Sponsor, assign one before the end of the week. Then build the assignment into your agent deployment process so it never happens again.