Someone in marketing connected an AI writing tool to the company SharePoint last quarter. They clicked accept, the tool started working, and nobody has looked at it since. That grant is still live, still reading files, and it is on no access review.
Every AI agent, Copilot extension, and third-party AI service that touches your tenant authenticates as a service principal in Microsoft Entra ID. These identities hold standing permissions, sign in without MFA, are not covered by ordinary Conditional Access, and carry credentials that commonly outlive the employee who created them. They are user accounts in everything but governance.
Three Doors Into the Tenant
| Entry path | What gets created | Who can do it |
|---|---|---|
| Third-party AI SaaS OAuth consent | Enterprise application with delegated Graph permissions | Any user, if user consent is not restricted |
| Copilot agents and internal builds | Service principal connected to tenant data sources | Makers, often outside IT |
| Developer app registration | App registration with a client secret and application permissions | Anyone who can register apps |
The third door is the widest. Application permissions are not scoped to a person: an app granted Files.Read.All reads every SharePoint site and OneDrive in the tenant, not the ones its creator could reach. Mail.Read as an application permission reads every mailbox unless someone narrowed it with an Exchange application access policy, which is rarely done. Same pattern as service principal sprawl, on an AI adoption timeline.
Why Your Existing Controls Miss Them
Conditional Access evaluates users signing in. An agent using an app-only token is not a user, so those policies never see it. Conditional Access for workload identities exists, but it is separately licensed and defaults to nothing. MFA does not apply, because there is no second factor on a client secret. Access reviews are built around people. And agent activity lands in the service principal sign-in logs, the same blind spot behind non-interactive sign-ins.
The delegated case fails differently: the agent inherits exactly what the consenting user can reach, which is safe until an over-permissioned user connects one. That is the Copilot oversharing problem with an API on top.
Then there is the credential. Client secrets are set with an expiry, often the two year maximum, and that expiry is the only lifecycle control most of them get. The creator leaves, their account is disabled, offboarding is marked complete, and the app keeps authenticating for another eighteen months. A stolen secret gives an attacker the app's full permission set with no MFA prompt and no risky sign-in signal, quieter than any token theft against a person.
What to Inventory This Week
Pull your enterprise applications and app registrations, then answer four questions for each.
What can it read? Separate delegated from application permissions. Application permissions ending in .All are the ones that matter.
Who consented, and were they allowed to? Check whether user consent is restricted, and review admin consent grants against applications you actually approved.
Is it still used? Service principal sign-in logs show last activity. Tenant-wide read with no authentication in ninety days is standing risk with no benefit.
When does its credential expire, and who owns it? An app whose only owner has left has no owner.
The fix is the governance you already run for people: a named human owner, a documented purpose, the narrowest permission set that does the job, an expiry, and a place in the quarterly access review. Restrict user consent so a new connector needs approval rather than a click. Scope mail and file access with application access policies instead of granting the whole tenant.
SecValley scans Entra ID, Microsoft 365, and Azure read-only and reports service principals, granted permissions, credential expiry, and owner state as dated findings.
Start with one query: which applications hold an application permission ending in .All, and can you name the business reason for each.
Frequently Asked Questions
What is an AI agent identity in Entra ID?
It is a service principal, the same non-human identity object used by any application. Connecting an AI agent, Copilot extension, or third-party AI service creates one, and it holds the permissions the agent uses to read or write data independently of any user session.
Does Conditional Access apply to AI agents?
Not by default. Standard policies evaluate user sign-ins. Agents authenticating with app-only tokens are covered only by Conditional Access for workload identities, a separately licensed feature that must be explicitly configured and targeted.
What is the difference between delegated and application permissions for an AI agent?
Delegated permissions let the agent act for a signed-in user and are capped by that user's own access. Application permissions are tenant-wide with no user involved, so Files.Read.All reaches every site and OneDrive in the organization regardless of who set it up.
How do I find AI tools employees connected without approval?
Review enterprise application consent grants in Entra ID by permission and consent date, then cross-check the service principal sign-in logs for which are actively authenticating. If user consent is unrestricted, assume the list contains applications nobody in IT approved.
