Deconstructing the Assistive Agent Threat Vector: Analyzing Microsoft Entra Agent ID Logs

Recent analysis of Microsoft Entra Agent ID logs has uncovered a nuanced but high-impact threat vector: the use of assistive agents leveraging the OAuth On-Behalf-Of (OBO) flow. This mechanism allows an agent to act with delegated user privileges, enabling it to perform sensitive actions—such as sending external emails—under the guise of a legitimate human identity.

In a documented incident, an email with the subject line “Here is your invoice” was flagged within Exchange Purview. The logs recorded the “Send” action as being initiated by an AgentId rather than a standard user account. Initial telemetry provided a deceptive starting point: the client IP was logged as 40.126.23.26, with a user-agent string suggesting PowerShell running on macOS.

However, surface-level investigation is often insufficient in modern cloud environments. By pivoting from the AppAccessContext.UniqueTokenId and ClientRequestId into the Microsoft Graph Activity Logs, investigators were able to uncover the true underlying mechanics. This deeper telemetry confirmed a Graph POST request to /users/{user}/microsoft.graph.sendMail and revealed the actual source IP as 51.3.97.221.

To bridge the gap between the API call and the identity, the investigation correlated the unique token with AADNonInteractiveUserSignInLogs. This correlation produced a specific sign-in record for Agent001 (AppId: 8cd0a10f-0be8-413a-9bf2-f44bc568d1e4). The logs demonstrated that the agent successfully obtained a token on behalf of [email protected], possessing high-privilege scopes including Mail.Send and Mail.ReadWrite.

As noted in Red Canary’s threat research, this case study illustrates the vital necessity of cross-log correlation. By weaving together Purview Exchange activity, Microsoft Graph API telemetry, and Azure AD Non-Interactive sign-in logs, defenders can distinguish between human-driven actions and agentic execution, exposing both the true origin and the actual scope of the activity.

A critical technical indicator of this specific flow is the combination of two metadata fields: Agent.agentType set to agenticAppInstance and agentSubjectType set to notAgentic. Together, these fields signal an assistive (OBO) flow, differentiating it from standard service principals or fully autonomous agent sign-ins.

The resulting forensic timeline provides a clear narrative: At 2026-05-08T15:27:05Z, Agent001 utilized Microsoft Graph (beta) to dispatch an email as [email protected] to [email protected], originating from IP 51.3.97.221 via a PowerShell/7.6.1 user-agent.

Technical Deep Dive: Microsoft Entra Agent ID Logs

The recorded Microsoft Graph scopes reflect the delegated permissions granted to the agent’s “blueprint principal” at the moment a user consented to the access_agent scope. Furthermore, sign-in telemetry indicates that the issued token satisfied per-user Multi-Factor Authentication (MFA) requirements via specific claims within the token.

Figure 1: Microsoft Graph Command Line Tools app (Source: Red Canary).

For security operations teams, the operational takeaways are immediate:

• Impact of Delegated Permissions: Assistive agents can execute high-impact actions that reside at the intersection of the agent’s scoped permissions and the end-user’s existing roles. While blocking high-risk Graph permissions is a necessary baseline, it does not entirely eliminate the risk of an authorized agent being leveraged for abuse.
• The Correlation Mandate: Defenders cannot rely on a single log source. To disambiguate agent activity from human or service principal activity, you must correlate Purview/Exchange logs, MicrosoftGraphActivityLogs, and AADNonInteractiveUserSignInLogs.
• Essential Correlation Pivots: Focus on matching AppAccessContext.UniqueTokenId with SignInActivityId, aligning ClientRequestId values, and verifying matching SessionId values across datasets.
• Identifying the OBO Flow: The most reliable signature for an assistive OBO flow is the pairing of agent.agentType == agenticAppInstance and agent.agentSubjectType == notAgentic.

Detection Strategy: Security engineers should implement detection logic that flags unexpected Mail.Send Graph calls where the caller is identified as an agent, especially when the originating IP deviates from known user locations or when the scope includes sensitive permissions like Mail.ReadWrite.

Hunting Workflows: Effective threat hunting should focus on validating how access_agent consent was originally obtained (inspecting redirect URIs and consent dialogs). Additionally, investigators should scrutinize the agent blueprint principal by inspecting the federatedCredentialId and parentAppId fields to trace the activity back to its architectural origin.

As the adoption of AI agents accelerates, they must be treated as first-class identity types. This requires instrumenting specialized logs, building automated correlation playbooks, and strictly enforcing least-privilege principles around agent blueprints and consent surfaces to mitigate the risk of agent-facilitated compromise.