The dominant take on Microsoft’s October 19 announcement is that AI agents are a brand-new identity perimeter, and that Project Perception is the thing that finally governs it. I think that’s wrong — or at least backwards. Agents aren’t a new category of principal. They’re the same non-human identity (NHI) sprawl we’ve refused to govern since the first unattended service account got a password that never expired, except now the account reasons about where to go next and makes the calls faster than you can read the log.
Let me steelman the hype properly, because the people writing it aren’t fools. Agents genuinely behave differently from a cron job wired to a service principal. A traditional workload identity does the same three Graph calls forever; you can baseline it in an afternoon. An LLM-driven agent generates its access pattern at runtime from a prompt and whatever context it scraped, so on Tuesday it reads a SharePoint library it never touched on Monday — not because someone changed the code, but because someone changed the question. There’s no human at the keyboard to hit an MFA prompt, no session to risk-score, no “unusual sign-in from Lagos” story because the sign-in is a client-credentials grant from the same datacentre every time. Microsoft’s framing — monitoring built for agent speed, authorization policies, anomaly detection on behaviour rather than geography — is a reasonable response to a real gap. All of that is true, and I’ll concede it up front.
Here’s where it falls apart. None of that changes the identity primitives underneath, and the primitives are where you actually get hurt.
Strip off the “agent” label and look at what it holds
An agent in the Microsoft stack authenticates as one of exactly the same four things it always was: a service principal behind an app registration, a managed identity, an OAuth app granted delegated or application permissions, or — God help you — a raw API key in an environment variable. Microsoft’s agent framing may offer a tidier portal experience, but a client-credentials flow is a client-credentials flow. The agent presents a secret or certificate, gets an access token, and that token carries the permissions you granted the app. No MFA. No Conditional Access by default unless you’ve paid for it. The token is a bearer token: whoever holds it is the agent for the next 60-odd minutes.
That last sentence is the whole story, and it’s the part the announcement politely skips.
Project Perception, from what Microsoft describes, is a detective control dressed in preventive language. Monitoring, anomaly detection, behavioural baselining — all of it fires after the agent has already made the call. That’s useful. It is not the same as least privilege, and conflating the two is how you end up with a dashboard full of alerts about reads you authorised eighteen months ago and forgot.
What a week with an over-permissioned agent actually looks like
I gave a Copilot-style agent its own app registration and pointed it at a SharePoint site via Graph. The default instinct — the one half the tutorials still show you — is to grant Sites.Read.All as an application permission. Do that and your agent can read every site in the tenant. Every. Site. The HR library, the M&A folder, the one marked “do not open.” The agent doesn’t know those are sensitive; it knows they match the query.
The fix isn’t Project Perception. It’s Sites.Selected, which has existed for years and which almost nobody uses because it’s three extra steps. You grant the app the capability tenant-wide, then grant access to one specific site out of band:
Now the agent can read exactly that site and nothing else, and when it reasons its way toward the M&A folder it gets a 403 instead of a filename. That’s the delegated-scope enforcement the brief asks about, and it lives in the grant, not in a security platform watching the grant.
Auditing the thing is better than it used to be. Every Graph call the agent makes lands in the MicrosoftGraphActivityLogs table if you’ve wired diagnostic settings to a Log Analytics workspace — with the service principal ID, the request URI, the scopes on the token, and the response code:
Pair that with AADServicePrincipalSignInLogs for the token issuance events and you have a defensible trail. This is genuinely good, and it’s the raw material anomaly detection — Perception’s or your own — feeds on.
Conditional Access can also be pointed at the agent, which surprises people. Workload identity Conditional Access lets you block a service principal from authenticating outside a named IP range, so a leaked secret used from somewhere unexpected fails the sign-in:
Be honest about the catch: that capability requires Microsoft Entra Workload ID Premium, licensed per workload identity per month. It is not in your E5. Budget for it per agent, because one agent is never one agent for long.
The part nobody puts on a slide
Here’s what bit me and will bite you. I rotated the agent’s secret and pulled its site permission mid-week to simulate a revocation. The already-issued access token kept working until it expired — Graph bearer tokens aren’t checked against revocation on every call. For a human you’d kill the session with Revoke-MgUserSignInSession. There is no clean equivalent for a service principal’s live token. You remove the credential, you remove the app-role assignment, and then you wait out the token lifetime, default around 60–75 minutes, while a compromised agent keeps reading.
For a human insider, an hour of residual access after you’ve hit the panic button is bad. For an agent making a few thousand Graph calls an hour, an hour is an exfiltration budget. That is the agent-specific risk, and it’s a token-lifetime and revocation problem, not something a behavioural anomaly engine closes.
So what does Zero Trust for agents actually mean, stripped of the poster? Verify explicitly: certificate-backed or federated credentials, never a static secret, Conditional Access on the workload identity. Least privilege: Sites.Selected and resource-scoped grants, not .All anything, with an expiry you enforce yourself because the grant won’t. Assume breach: short token lifetimes, and an accepted, rehearsed answer to “the agent is compromised, what’s our actual revocation latency?”
Project Perception will tell you when an agent does something strange. Worth having. But it watches a perimeter you already drew with app registrations and Graph grants — and most teams drew it badly, years ago, for service accounts they’ve since forgotten. The agent didn’t create that debt. It just reads it back to you at machine speed.