Why JML Was Designed for a Human-Shaped World

Joiner-Mover-Leaver workflows emerged from a specific mental model: a person joins an organization, their role changes over time, and eventually they leave. Each transition triggers a defined set of identity operations — account creation, group membership changes, license assignment, and ultimately account disablement and credential revocation.

This model works because humans have HR records. They have managers. They have employment contracts with start and end dates. The identity lifecycle is anchored to a human lifecycle, and every control in the JML chain — from automated provisioning in Entra ID to access certification in Microsoft Entra Identity Governance — assumes that anchor exists.

AI agents have none of these anchors. A Copilot Studio agent deployed to automate procurement approvals does not have an HR record. It does not have a manager in the organizational hierarchy. It does not have a contract end date. It has a service principal with an application registration, possibly a client secret with a 24-month expiry, and whatever permissions the developer granted it during a weekend sprint.

When a human employee is granted access to a SharePoint site, that access flows through a provisioning request, an approval workflow, and an access review cycle. When an AI agent is granted the same access via Sites.ReadWrite.All on a service principal, none of those controls fire. The permission exists. The audit trail does not.

---

The Service Principal Attack Surface You Are Not Reviewing

Service principals and managed identities are the credential substrate for agentic AI workloads in Azure and Microsoft 365. Understanding their specific failure modes is prerequisite to fixing them.

Service principals are application identities registered in Entra ID. They authenticate using client secrets or certificates. Client secrets, in particular, are a governance liability: they do not expire by default unless you set an explicit expiry, they can be created by application owners without IT involvement, and they are not subject to Conditional Access policies in the same way user credentials are.

Managed identities are the more secure option — they eliminate the credential management problem by binding the identity to an Azure resource. But they introduce a different governance problem: because they require no credential rotation and generate no provisioning ticket, they are frequently forgotten after the resource they were created for is decommissioned.

Run this KQL query against your Entra ID sign-in logs to see how many non-human identities are authenticating in your environment right now:

// Enumerate service principal sign-ins over the last 30 days
// Run in: Microsoft Sentinel or Log Analytics (SigninLogs table)
SigninLogs
| where TimeGenerated > ago(30d)
| where UserType == "servicePrincipal" or ServicePrincipalName != ""
| summarize
    SignInCount = count(),
    UniqueResources = dcount(ResourceDisplayName),
    LastSeen = max(TimeGenerated),
    FirstSeen = min(TimeGenerated)
    by ServicePrincipalName, AppId, IPAddress
| where SignInCount > 0
| order by SignInCount desc

Most environments running this query for the first time find dozens of service principals they cannot immediately attribute to a known workload. Some of those are legacy integrations. Some are vendor applications. And increasingly, some are AI agents deployed by business units without a formal IT intake process.

The second problem is permission scope. AI agents built on Microsoft Graph often request broad application permissions because developers default to the most permissive scope that makes the demo work. Mail.ReadWrite, Files.ReadWrite.All, Directory.ReadWrite.All — these are application-level permissions with no user context, no session boundary, and no MFA requirement. They are the highest-privilege access paths in your M365 tenant, and they are being granted to workloads that your JML process has never reviewed.

Use this PowerShell block to enumerate application permissions granted to service principals in your tenant:

Connect-MgGraph -Scopes "Application.Read.All", "Directory.Read.All"

$servicePrincipals = Get-MgServicePrincipal -All

foreach ($sp in $servicePrincipals) {
    $appRoleAssignments = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id

    foreach ($assignment in $appRoleAssignments) {
        $resourceSP = Get-MgServicePrincipal -ServicePrincipalId $assignment.ResourceId
        $appRole = $resourceSP.AppRoles | Where-Object { $_.Id -eq $assignment.AppRoleId }

        [PSCustomObject]@{
            ServicePrincipalName    = $sp.DisplayName
            AppId                   = $sp.AppId
            ResourceName            = $resourceSP.DisplayName
            PermissionName          = $appRole.Value
            PermissionDescription   = $appRole.DisplayName
            AssignedDate            = $assignment.CreatedDateTime
        }
    }
}

Run this and export the results. Filter for ResourceName containing "Microsoft Graph" and sort by PermissionName. What you will find is a list of application-level Graph permissions that bypasses every delegated access control your governance team thinks is in place.

---

How Agentic Workloads Break Compliance Frameworks

SOC 2 Type II, ISO 27001, and most enterprise insider threat programs share a common dependency: they assume that access to sensitive data can be traced to an accountable human identity. The audit trail — who accessed what, when, and why — is the evidentiary backbone of these frameworks.

AI agents operating under service principals break this assumption at the architectural level.

When an AI agent reads a SharePoint document library, the audit log records the service principal's App ID, not a human identity. When that agent writes data to an external system, the action is logged under the application registration, not under the employee who built the agent or the business unit that deployed it. The human accountability chain — the chain that SOC 2 auditors follow when they ask "who had access to this data?" — terminates at the application object.

This creates three specific compliance failures:

Access certification gaps. Microsoft Entra Identity Governance access reviews are designed to certify that human users still need their access. They do not natively surface application-level Graph permissions for review. A service principal with Mail.ReadWrite.All granted two years ago will never appear in a standard access review campaign unless you have explicitly built a process to include it.

Offboarding blind spots. When the developer who built an AI agent leaves the organization, your JML offboarding process disables their user account and revokes their licenses. It does not revoke the service principal they created. It does not rotate the client secret they provisioned. The agent continues to authenticate and operate after its human creator has been offboarded — with credentials that are now unowned.

Insider threat program gaps. Most insider threat programs monitor user behavior analytics through tools like Microsoft Purview Insider Risk Management, which correlates user activity with risk signals. Service principal activity is not correlated with user risk profiles. An agent exfiltrating data at scale would not trigger the same behavioral alerts that a human performing the same actions would generate.

---

Building a Non-Human Identity Governance Layer

Fixing this requires building a parallel governance track specifically for non-human identities. This is not a modification of your existing JML workflow — it is a separate process that runs alongside it.

The foundation is inventory. You cannot govern what you cannot enumerate. The PowerShell block above gives you a point-in-time snapshot. For continuous visibility, configure the Entra ID diagnostic settings to stream service principal sign-in logs to your Log Analytics workspace, then build a persistent KQL workbook that surfaces new service principals, permission changes, and authentication anomalies.

// Detect new service principals authenticating for the first time
// Useful for identifying shadow AI deployments
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| summarize FirstSeen = min(TimeGenerated) by ServicePrincipalName, AppId
| where FirstSeen > ago(7d)
| join kind=leftanti (
    AADServicePrincipalSignInLogs
    | where TimeGenerated between (ago(37d) .. ago(7d))
    | distinct AppId
) on AppId
| project ServicePrincipalName, AppId, FirstSeen
| order by FirstSeen desc

This query surfaces service principals that authenticated for the first time in the last seven days but had no activity in the prior 30 days. In a mature environment, every result should map to a known deployment event. Unrecognized results are your investigation queue.

Beyond inventory, the governance layer requires four operational controls:

Ownership assignment. Every service principal must have a designated owner — a human identity accountable for its existence, its permissions, and its decommissioning. Entra ID supports owner assignment on application registrations. Make this mandatory through a policy enforced by Azure Policy or a custom Entra ID governance workflow.

Permission minimization at registration. Establish an application permission allowlist for AI agent workloads. Broad permissions like Files.ReadWrite.All should require a formal exception process equivalent to privileged access approval. Default to the narrowest scope that satisfies the workload — Files.Read instead of Files.ReadWrite.All, site-scoped permissions instead of tenant-wide permissions.

Credential lifecycle enforcement. Client secrets must have explicit expiry dates, and expiry must trigger a renewal review — not an automatic rotation. The renewal review is the checkpoint where you verify the workload still exists, still needs the permission, and still has an active owner. Use Azure Key Vault with Entra ID managed identity where possible to eliminate client secrets entirely.

Periodic access certification for service principals. Build a quarterly review process that mirrors your human access review cycle. Export all service principals with Graph application permissions, assign each to its designated owner, and require the owner to certify that the permission is still required. Owners who cannot certify a permission within the review window trigger an automatic revocation workflow.

---

Governance Considerations for Regulated Environments

If your organization operates under regulatory frameworks that require demonstrable access control — financial services, healthcare, government — the non-human identity gap is not an abstract risk. It is a finding waiting to happen.

SOC 2 auditors reviewing your access control environment will ask for evidence that all access to in-scope systems is authorized, reviewed, and revocable. If your answer covers human identities but cannot account for service principals with access to the same systems, you have a control gap that a competent auditor will surface.

ISO 27001 Annex A control A.9.2 (User Access Management) and A.9.4 (System and Application Access Control) both apply to non-human identities, even though the original control language was written with human users in mind. The 2022 revision of ISO 27001 introduced A.5.9 (Inventory of Information and Other Associated Assets) and A.8.2 (Privileged Access Rights), both of which can be interpreted to require service principal governance.

The practical recommendation for regulated environments is to treat every AI agent as a privileged identity from the moment of registration. Apply the same approval gates, the same review cycles, and the same revocation procedures that you apply to human privileged accounts. The permissions these agents carry — application-level Graph access, managed identity roles on Azure resources — are functionally equivalent to privileged human access in terms of their blast radius.

---

Recommendations for Immediate Action

These are the controls to implement before your next audit cycle, ordered by operational impact:

Run the service principal enumeration query and build an ownership register. Every unowned service principal is an open finding. Assign owners within 30 days.

Audit all application-level Graph permissions in your tenant using the PowerShell block above. Flag any permission in the ReadWrite or FullControl tier that was granted more than 90 days ago without a documented review.

Enable Entra ID service principal sign-in logs and route them to Sentinel or Log Analytics. If you cannot see the authentication activity, you cannot detect anomalies.

Establish a mandatory intake process for AI agent deployments. Any workload that requires a service principal or managed identity must go through IT, receive an owner assignment, and have its permissions documented before deployment.

Add service principals to your next access review cycle. Use Microsoft Entra Identity Governance to create a review campaign scoped to application permissions, not just user group memberships.

---