The Security Bridge™️- Identity Threat Protection in Microsoft 365 - Part 2: Your Tenant Has More Identities Than Employees
- Derek Morgan
- Jul 22
- 5 min read
Organizations now manage a median of 109 machine identities for every human identity in their environment, up from 82 to 1 last year, according to Palo Alto Networks' 2026 Identity Security Landscape report, a survey of 2,930 cybersecurity decision-makers. AI agents account for roughly 79 of those 109, about 72.5% of the machine identity population. Machine identities are projected to grow another 77% over the next 12 months, agent identities specifically 85%.
Other 2026 reports land on different numbers. KPMG puts the ratio at 80 to 1. The Cloud Security Alliance found ratios as high as 144 to 1 in cloud-native environments. Rubrik Zero Labs cites 45 to 1. The methodology varies, but every one of these reports agrees on the direction: the identity population in a typical Microsoft 365 tenant is overwhelmingly non-human, and growing faster than the human side.
An access model built around reviewing what employees can reach doesn't scale to a population that's this lopsided. Identity security covers every entity capable of accessing data or making decisions: users, service principals, and agents alike.
The three identity classes
A Microsoft 365 tenant contains three distinct kinds of identity, and each needs a different governance model. Human identities are Entra ID users, the accounts your access reviews and MFA policies were built around. Workload identities are service principals, managed identities, and automation accounts, the identities behind app registrations, scripts, and integrations. Agent identities are the newest class, Entra Agent ID identities that give AI agents their own sign-in and their own permissions, capable of acting without a human in the loop.
Humans get access reviews and MFA. Workload identities need credential lifecycle management, someone has to own the secret, rotate it, and retire it. Agent identities need both, plus scoping for what an autonomous entity is actually allowed to decide. Most identity governance programs still only build for the first class.
Ownership is a takeover primitive
Service principals have owners, and an owner can add a credential, a client secret or certificate, to the service principal they own. Once that credential exists, anyone holding it can authenticate as the service principal in an app-only context. That app-only context inherits every permission and directory role the service principal holds.
Two independent 2026 disclosures land on this same mechanism. Silverfort's research on the Entra Agent ID Administrator role found that the role's scope let an account take ownership of almost any service principal in a tenant, not just agent-related ones, add a credential, and inherit its permissions, including a documented case of hijacking a Global Administrator account this way. Microsoft patched the specific scope overreach in April 2026. Semperis's EntraGoat research documented the same underlying primitive through a different path: a compromised low-privilege user discovers ownership of a service principal with a privileged directory role, adds a secret, and escalates to Global Administrator. Different entry points, same mechanism. Silverfort's research also found that 99% of tenants have at least one privileged service principal, one holding a directory role like Global Administrator or Privileged Role Administrator.
Directory roles aren't the only path to that outcome. A service principal doesn't need a role assignment to be dangerous, a handful of Microsoft Graph API permissions get it there on their own. RoleManagement.ReadWrite.Directory lets a service principal grant any directory role, including Global Administrator, to any principal it chooses, including itself. Application.ReadWrite.All lets it manage credentials on other applications, chaining into the same ownership-takeover primitive from a different angle. A service principal holding either permission is functionally as dangerous as one that already has Global Administrator, and an audit that only checks for directory role assignments will miss it entirely.
The detection gap
Entra ID records ownership changes and credential additions to the audit log. It doesn't alert on either by default. An attacker adding themselves as an owner, or adding a new secret to a privileged service principal, generates no notification unless an organization has built that detection rule itself.
What this looks like in production
I worked with a client that had several service principals holding privileged API permissions with no owner, or an owner who'd left the organization months earlier. We interviewed the current team, and nobody could account for what the service principals did or why they existed. Rather than delete them outright, we ran what's sometimes called a scream test: removed the API permissions and client secrets, disabled the service principals, and documented the change, then waited to see if anything broke. Nothing did.
Another client had a service principal assigned the Application Administrator role, scoped for a project that needed it to create other service principals. The project ended. The role assignment didn't. Audit logs showed someone had used that service principal after the project closed, meaning a role capable of creating and managing other application identities had been sitting active with no current business justification. We removed the role and disabled the service principal immediately.
In a recent client engagement, I saw a third version of this problem: a small group of service principals still carrying client secrets set to the legacy "never expires" option. Unlike the first two examples, these had an accountable owner, so the fix was procedural. We generated new secrets, worked with each owner to rotate them into the consuming applications, set up a workflow to notify owners ahead of future expirations, and removed the old secrets immediately once the new ones were confirmed working.
Business case
Silverfort's finding that 99% of tenants carry at least one privileged service principal means this exposure is close to universal. Pair that with Palo Alto Networks' growth numbers, machine identities up 77%, agent identities up 85% over the next 12 months, and the ungoverned population is compounding faster than most identity governance programs are built to track.
What to validate this week
Inventory every service principal holding a directory role, using Microsoft Graph or PowerShell, not a manual spreadsheet
Inventory service principals holding RoleManagement.ReadWrite.Directory or Application.ReadWrite.All, these grant Global Administrator-equivalent capability without any directory role assignment, so the check above won't catch them
Audit ownership on every privileged service principal; treat no-owner and disabled-owner cases as Tier 1 findings
Build detection rules for service principal ownership changes and credential additions, since Entra ID doesn't alert on either by default
Establish a quarterly ownership and credential-health review cadence for privileged service principals
Prefer managed identities over app secrets wherever the workload supports it, removing credential lifecycle risk instead of managing it
The takeaway
Identity security covers every entity capable of accessing data or making decisions: users, service principals, and agents alike. Ownership is the control point that decides whether that population is governed or invisible, and right now, in most tenants, it's invisible. Part 3 turns to Conditional Access: what it actually prevents, and where prevention has to hand off to detection.
Comments