The Service-Principal Governance Hack Is Dead. Agents Got Their Own Identity.

The thing that finally pushed me to look was a service principal named agent-finance-recon-prod that had been sitting in a privileged group for months. Nobody created a review for it. Nobody could have. Access reviews point at users and groups; this was a bot wearing a service principal’s coat, and the governance tooling genuinely did not know what to do with it. So it sat there, quietly holding permissions, the way a houseguest holds a spare key three years after they moved out.

That gap, AI agents that behave like users but file like app registrations, is the thing Microsoft’s latest Entra ID Governance updates are trying to close. The guest half of the announcement is the other perennial mess. I turned both on in a test tenant to see what was real and what was a roadmap slide wearing a GA badge. Mixed results, as usual.

Day one: what an “AI agent” actually is in Entra

First thing to get straight, because the vendor language is deliberately slippery: an AI agent here is not a vibe. Microsoft gave agents a real identity surface, Agent ID, and the agents that get one are the ones born inside the Microsoft stack: things built in Copilot Studio and Azure AI Foundry. When you spin one of those up, it now gets its own first-class identity object in Entra rather than squatting inside whatever app registration the developer happened to use.

Under the hood, that identity is still a specialised flavour of service principal. This matters. It means the agent inherits a lot of the plumbing you already understand, it shows up in sign-in logs, it can be targeted by Conditional Access, it has an object ID you can hang a policy off. But Microsoft is treating it as a distinct class in the admin center, which is the part that actually changes your day. You stop grepping through 400 enterprise apps trying to guess which three are bots.

Think of it like the moment a company stops logging contractors in the visitor book and starts issuing them badges. Same humans walking through the same door. Completely different ability to answer “who’s in the building right now and why.”

The honest caveat: as I write this, the agent identity surface carries preview framing. Treat it like preview. Don’t build a compliance control you’ll have to attest to an auditor on top of something that can change its blade name next month.

An hour in: which governance features actually point at agents

Here’s where I had to separate the pitch from the product. The pitch is that the full Entra ID Governance suite, access reviews, entitlement management, lifecycle workflows, PIM, now embraces agents. The product, in my tenant, was narrower and more interesting than that.

What I could verify working the way you’d hope:

• Visibility and Conditional Access. Agents as a targetable identity class. This is the genuinely useful, available-now part. You can scope a CA policy at agent identities and stop them signing in from anywhere you wouldn’t let a human.
• Access reviews pointed at agent access. This is the headline feature and the one I’d flag hardest as preview-shaped. The promise is that the same recurring review machinery that nags a manager about a stale group membership can now ask “does this agent still need this?” It worked in the demo path. I would not yet stake a quarterly compliance cycle on it.

What I did not find was a clean, GA lifecycle-workflow template for agents, the joiner/mover/leaver automation that works so well for employees doesn’t yet have an obvious agent equivalent. And entitlement-management access packages for agents are more “conceptually adjacent” than “ship it today.” If someone tells you lifecycle workflows now fully govern agent onboarding and offboarding, ask them to show you the template in their own tenant.

So the accurate framing: agents became governable objects. The full governance lifecycle around them is arriving in stages, and reviews are the leading edge of it. That’s still a real improvement over the previous state, which was nothing.

The next morning: the guest half, which is mostly enhancement, not revolution

The guest controls are the less glamorous and, for most tenants, more immediately valuable piece. And here I want to be blunt: almost none of this is net-new. It’s the existing guest lifecycle story getting sharper edges.

Entra has had access reviews for guests, inactive-user insights, sponsors, and entitlement-management-driven guest access packages for a while. The enhancements tighten the loop:

• Inactive guest signal feeding reviews. The stale-guest problem, accounts that last signed in during a project that wrapped two reorgs ago, gets surfaced more directly into the review flow, so a reviewer sees “hasn’t signed in for 90 days” next to the name instead of having to go dig it out of sign-in logs.
• Tighter lifecycle endings. Better wiring between a failed review and the actual removal or block, so “nobody approved this guest” more reliably becomes “this guest no longer has access” rather than a report nobody reads.
• Entitlement management as the front door. The push remains: stop inviting guests ad hoc from the Users blade, route them through access packages with an expiry and a sponsor attached. That’s not new advice. It’s just better supported.

The physical analogy that stuck with me: the old guest model handed out keys and hoped. The enhanced model is a key that dissolves on a timer unless someone actively renews it. The default should be expiry. It still isn’t, out of the box, you have to configure it, which remains my single biggest irritation with guest governance generally.

Where this all lives, and what it costs

You configure the governance pieces, access reviews, entitlement management, lifecycle workflows, under Identity Governance in the Entra admin center. Guest collaboration settings (who can invite, what guests can see) live under External Identities. Conditional Access for both agents and guests sits in the Protection → Conditional Access blade. The agent identity surface is its own area in the admin center; expect it to move while it’s in preview.

Licensing is the part people skip and then get surprised by. The governance features that matter here, access reviews, entitlement management, lifecycle workflows, PIM, are Microsoft Entra ID Governance, which is a premium add-on that sits on top of an Entra ID P1 or P2 base. Access reviews specifically have always been P2 territory. For guest reviewers there’s historically been a per-reviewed-guest billing model under External ID, so a large guest estate has a real meter running. On the agent side, assume agent governance rides the same Governance SKU rather than falling into a base plan, and verify it against your own tenant’s licensing blade before you promise anyone it’s free. I’m not going to pretend the agent licensing story is fully settled; it isn’t.

What I’d run on the way in

Before you touch anything, inventory what you’ve got. I wanted to see which service principals in my tenant actually look like agents, and which guests haven’t signed in this year. Read-only, paginated, no changes:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

Connect-MgGraph -Scopes "Application.Read.All","AuditLog.Read.All","User.Read.All"
​
try {
    # Service principals that look agent-ish - review the output, do not act on it blindly
    $sps = Get-MgServicePrincipal -All -Property "id,displayName,servicePrincipalType,tags" `
        -ErrorAction Stop
    $sps |
        Where-Object { $_.DisplayName -match 'agent|copilot|bot' } |
        Select-Object DisplayName, Id, ServicePrincipalType |
        Export-Csv .\candidate-agents.csv -NoTypeInformation
}
catch {
    Write-Error "Agent inventory failed: $($_.Exception.Message)"
}
​
try {
    # Guests with no sign-in in ~90 days
    $cutoff = (Get-Date).AddDays(-90).ToString("o")
    $staleGuests = Get-MgUser -All -Filter "userType eq 'Guest'" `
        -Property "id,displayName,mail,signInActivity" -ErrorAction Stop |
        Where-Object {
            $_.SignInActivity.LastSignInDateTime -lt $cutoff -or
            -not $_.SignInActivity.LastSignInDateTime
        }
    $staleGuests |
        Select-Object DisplayName, Mail, Id,
            @{n='LastSignIn';e={$_.SignInActivity.LastSignInDateTime}} |
        Export-Csv .\stale-guests.csv -NoTypeInformation
}
catch {
    Write-Error "Guest inventory failed: $($_.Exception.Message)"
}

Then, and only then, after a human has read the CSV, act on the reviewed file, never the live query. Note the -WhatIf. Leave it on until you’ve seen the dry-run output and believe it:

1
2
3
4
5
6
7
8
9
10
11
12

# Operates on the reviewed export, not a live query. -WhatIf by default.
$toRemove = Import-Csv .\stale-guests-APPROVED.csv
​
foreach ($g in $toRemove) {
    try {
        Remove-MgUser -UserId $g.Id -WhatIf -ErrorAction Stop
        Write-Host "Would remove guest: $($g.DisplayName)"
    }
    catch {
        Write-Error "Failed on $($g.DisplayName): $($_.Exception.Message)"
    }
}

For the review policies themselves, the Microsoft.Graph.Identity.Governance module is where you live, the accessReviews and entitlementManagement endpoints. The agent-identity Graph surface is still settling; don’t hardcode anything against it in a pipeline you can’t easily change.

If you take one thing from my week: agents just stopped being invisible, and that alone is worth turning on. But the governance lifecycle around them is a frame, not a finished building, reviews first, the rest arriving. The guest controls are the opposite shape: unglamorous, mostly enhancements, and the ones that’ll actually shrink your attack surface by Friday. Do the boring guest cleanup first. Treat the agent features as a preview you’re learning, not a control you’re certifying. And whatever you do, make expiry the default, a key that dissolves on a timer beats a report nobody reads, every single time.