The Identity Trust Chain AI Services Build Without Asking You

Microsoft 365 Copilot, Copilot Studio, Azure OpenAI, and the broader family of AI services in the Azure ecosystem all depend on identity infrastructure to function. That infrastructure is Entra ID. The problem is that the trust relationships these services establish are often implicit, poorly documented, and invisible to the tools most security teams use to audit identity.

Consider a standard enterprise Copilot Studio deployment. A maker builds an agent that queries SharePoint document libraries, calls an Azure Function for enrichment, and posts results to a Teams channel. Behind the scenes, this agent authenticates using a service principal registered in Entra ID. That service principal may have been granted Sites.Read.All, Files.ReadWrite.All, or broader delegated permissions—often during a wizard-driven setup that no one reviewed with a security lens.

The service principal's credentials—either a client secret or a certificate—are stored somewhere. Maybe in Azure Key Vault. Maybe in a Power Platform environment variable. Maybe hardcoded in a flow definition that a maker exported to their local machine. Each of those storage locations is a potential credential exposure point, and none of them appear in your Intune device compliance reports.

Managed identities partially address the credential storage problem, but they introduce their own governance challenges. A system-assigned managed identity tied to an Azure Function inherits the permissions you grant it, but those permissions are often over-provisioned during development and never scoped down before production. A user-assigned managed identity shared across multiple resources creates a blast radius problem: compromise one resource, and the identity's permissions are available to an attacker across every resource it's assigned to.

---

What Entra ID Audit Logs Actually Show You—and What They Miss

Entra ID audit logs capture service principal sign-ins, but the default retention window is 30 days for most tenants without a Microsoft Entra ID P1 or P2 license feeding into Log Analytics. If your AI pipeline makes thousands of token acquisitions per day, the signal-to-noise ratio in raw audit logs makes anomaly detection impractical without structured queries.

The following KQL query, run against your Log Analytics workspace, surfaces service principal authentication events and groups them by application and resource to help you identify which AI service identities are most active:

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| summarize
    TotalSignIns = count(),
    UniqueResources = dcount(ResourceDisplayName),
    LastSeen = max(TimeGenerated)
    by AppDisplayName, ServicePrincipalId, ServicePrincipalName
| extend RiskIndicator = iff(UniqueResources > 5, "High Resource Spread", "Normal")
| order by TotalSignIns desc
| project
    AppDisplayName,
    ServicePrincipalName,
    TotalSignIns,
    UniqueResources,
    LastSeen,
    RiskIndicator

Run this query and look specifically at service principals with names that match your AI service deployments—anything with "Copilot", "OpenAI", "LogicApp", or "PowerAutomate" in the display name. A service principal accessing more than five distinct resources is worth investigating. That spread often indicates permissions that were granted broadly and never reviewed.

What this query cannot show you is delegated permission flows—scenarios where a service principal is acting on behalf of a user via OAuth 2.0 on-behalf-of (OBO) flow. In those cases, the token carries the user's identity but the permissions may be broader than what the user could access interactively, because the application's granted scopes define the ceiling, not the user's actual role assignments.

---

How Intune-Managed Endpoints Connect to an Unmanaged AI Attack Surface

Here is where the gap becomes operationally dangerous for endpoint teams specifically. Your Intune-managed Windows 11 devices are compliant. They run Defender for Endpoint. They're joined to Entra ID and subject to Conditional Access policies that require compliant device state for access to Microsoft 365 resources.

Now a user on that compliant device opens Power Automate and builds a flow that calls Azure OpenAI using a connection that authenticates with a service principal someone shared with them via a team channel. That flow runs in the Power Platform cloud—not on the endpoint. The endpoint's compliance state is irrelevant to the flow's execution context. The service principal's permissions are evaluated against Entra ID directly, with no Conditional Access gate in the path.

This is the architectural disconnect: endpoint compliance governs user interactive sessions, but AI pipeline execution happens in cloud-hosted compute that your Conditional Access policies were never designed to cover.

The practical consequence is that a user whose device is blocked from accessing SharePoint due to a compliance failure can still trigger a Power Automate flow—running under a service principal—that reads from the same SharePoint site. The data access happens. The Conditional Access block is bypassed. Not through any malicious action, but through the normal operation of a workflow the user built last month.

---

Mapping the Permission Footprint of AI Service Principals

Before you can govern AI identity chains, you need to enumerate them. The following PowerShell script uses the Microsoft Graph PowerShell SDK to export all service principals in your tenant that have application-level permissions (not delegated), which represent the highest-risk category for AI pipelines:

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

$servicePrincipals = Get-MgServicePrincipal -All -Filter "servicePrincipalType eq 'Application'"

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

    foreach ($assignment in $appRoleAssignments) {
        $resourceSP = Get-MgServicePrincipal -ServicePrincipalId $assignment.ResourceId

        [PSCustomObject]@{
            ServicePrincipalName    = $sp.DisplayName
            ServicePrincipalId      = $sp.Id
            AppId                   = $sp.AppId
            ResourceName            = $resourceSP.DisplayName
            PermissionId            = $assignment.AppRoleId
            CreatedDateTime         = $assignment.CreatedDateTime
        }
    }
}

$results | Where-Object { $_.ResourceName -like "*Graph*" -or $_.ResourceName -like "*SharePoint*" } |
    Sort-Object ServicePrincipalName |
    Export-Csv -Path ".\AIServicePrincipalPermissions.csv" -NoTypeInformation

Write-Host "Exported $($results.Count) permission assignments. Review AIServicePrincipalPermissions.csv."

Run this against your production tenant and filter the output for Graph API and SharePoint permissions. Any service principal with Files.ReadWrite.All, Mail.ReadWrite, Sites.FullControl.All, or User.ReadWrite.All at the application level is a high-priority governance item. These permissions, held by an AI pipeline service principal, represent a data exfiltration path that bypasses user-level access controls entirely.

---

Token Lifetime Policies and Why AI Pipelines Break Your Assumptions

Microsoft Entra ID allows administrators to configure token lifetime policies that control how long access tokens and refresh tokens remain valid. Most enterprise tenants have configured these policies with user sessions in mind—shorter lifetimes for sensitive applications, longer lifetimes for productivity tools to reduce authentication friction.

AI service principals operate under different token acquisition patterns. An Azure Function calling the Graph API will acquire a new access token on each execution if it's using a managed identity, because managed identity tokens are short-lived by design. But a Logic App using a service principal with a client secret may cache tokens and reuse them across executions, depending on how the connector is configured. If that client secret has a two-year expiration—which is the default when created through the Azure portal—and the token cache is not invalidated after a security incident, you have a long-lived credential that persists through your incident response.

The following KQL query identifies service principal authentications where the token lifetime exceeded your configured policy thresholds, which can indicate cached tokens or misconfigured application authentication:

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| extend TokenLifetimeSeconds = datetime_diff('second', 
    todatetime(AdditionalDetails), 
    TimeGenerated)
| where isnotempty(ConditionalAccessStatus)
| summarize
    SignInCount = count(),
    AvgIntervalMinutes = avg(TokenLifetimeSeconds) / 60,
    AppDisplayName = any(AppDisplayName)
    by ServicePrincipalId, bin(TimeGenerated, 1h)
| where AvgIntervalMinutes > 60
| project
    TimeGenerated,
    ServicePrincipalId,
    AppDisplayName,
    SignInCount,
    AvgIntervalMinutes
| order by AvgIntervalMinutes desc

Pair this query with your Entra ID token lifetime policy inventory. If a service principal is authenticating at intervals that suggest token reuse beyond your configured access token lifetime, investigate whether the application is caching credentials outside of the MSAL token cache—a pattern common in older Azure SDK versions and third-party AI integration libraries.

---

Compliance Gaps Under SOC 2, FedRAMP, and HIPAA

Audit frameworks do not distinguish between user-driven data access and service principal-driven data access. Under SOC 2 Type II, the access control criteria require that logical access to systems and data is restricted to authorized individuals. A service principal with Files.ReadWrite.All that was provisioned by a developer eighteen months ago and never reviewed does not meet that standard—regardless of whether a human being is actively using it.

FedRAMP introduces additional requirements around data residency and boundary definition. Azure OpenAI services have specific regional deployment constraints, and the data processed by an AI pipeline may traverse regions depending on how the service is configured. If your FedRAMP authorization boundary assumes data stays within a specific Azure Government region, but your Logic App calls a commercial Azure OpenAI endpoint because someone used the wrong connection string, you have a boundary violation that your endpoint compliance posture cannot detect or prevent.

HIPAA creates the most direct operational risk for healthcare organizations deploying AI pipelines. If a Copilot Studio agent queries a SharePoint library that contains documents with protected health information, and that agent's service principal was granted broad read access without a data classification review, you have a potential HIPAA breach vector that exists entirely in the identity layer—not in the endpoint layer where most healthcare IT teams focus their compliance controls.

The governance gap is not that these frameworks are unclear. The gap is that most organizations have mapped their compliance controls to user identity and endpoint state, and have not extended those controls to the service principal layer that AI pipelines operate on.

---

Operational Steps to Close the Identity Gap

Closing this gap requires treating AI service principals with the same rigor applied to privileged user accounts. That means four concrete operational changes.

First, build a service principal inventory specific to AI workloads. Use the PowerShell script above as a starting point, then tag service principals in Entra ID with a custom attribute that identifies them as AI pipeline identities. This makes them queryable as a distinct population for access reviews.

Second, enforce Entra ID access reviews on AI service principals quarterly. Entra ID access reviews support service principal review cycles. Configure reviews that require the owning application team to attest to each permission assignment. Any permission not attested within the review window should be automatically revoked.

Third, replace client secrets with managed identities wherever the compute layer supports it. Azure Functions, Logic Apps, Container Apps, and App Service all support managed identities. Client secrets have expiration dates that are routinely missed; managed identities rotate automatically and cannot be extracted from the compute environment.

Fourth, define Conditional Access policies for workload identities. Microsoft Entra ID now supports Conditional Access for workload identities under the Entra ID P2 license tier. These policies can restrict service principal authentication to specific IP ranges—your Azure datacenter egress IPs—and alert on authentication attempts from unexpected network locations. This does not replicate the full Conditional Access model for users, but it closes the most obvious lateral movement path.

---