Hunting Entra ID Assistive Agent Abuse: Correlate Exchange, Graph, Entra Logs

A new surge in malicious delegated OAuth access is hitting Microsoft 365 tenants as assistive AI agents become commonplace. Security teams are now correlating logs from Entra ID, Exchange Online, and Microsoft Graph to catch attackers who hijack user consent to silently exfiltrate data through legitimate-looking Graph API calls.

In June 2026, Microsoft flipped the switch on Graph Activity Logs—detailed telemetry for every delegated and application-permission Graph request. Combined with the mature Entra ID sign-in and audit logs, plus Exchange mailbox audit logs, defenders finally have the three-legged stool needed to expose AI agent abuse. Threat hunters are already spotting agent tokens enumerating mailboxes, downloading sensitive files, and forwarding messages, all while masquerading as normal AI assistant activity.

The Delegated OAuth Problem That Agents Amplify

Delegated OAuth allows an application to act on behalf of a signed-in user. When a user consents to an app, that app receives an access token scoped to the permissions granted—and crucially, the token carries the user’s identity and privileges. In the past, attackers abused delegated permissions via rogue enterprise apps, but the risk was constrained because a real user had to interact with a malicious app. AI agents change that equation.

Assistive AI agents—like Microsoft 365 Copilot extensions, custom copilots on Graph connectors, and third‑party productivity agents—rely heavily on delegated permissions. They call Microsoft Graph continuously to read mail, search SharePoint, parse Teams messages, and execute commands. Once a user consents to an AI agent, that agent gets a long‑lived refresh token and can operate silently in the background, even when the user is offline. A compromised or malicious agent can therefore exfiltrate data for months without triggering obvious alerts, because the activity looks like legitimate Graph traffic from the user’s own IP and device.

Attackers have adjusted quickly. They craft convincing AI agents that promise to summarize documents or schedule meetings. A user grants consent, and the agent immediately starts using Graph’s Mail.Read, Files.Read.All, or Sites.Read.All on the delegated token. The token gives the attacker the same access the user has—bypassing resource-side access controls. And because Graph API calls originate from Microsoft’s own IP ranges, traditional network‑based indicators of compromise fail.

Graph Activity Logs: The Missing Piece

Until mid‑2026, monitoring delegated Graph abuse was extremely difficult. Entra ID sign‑in logs showed the initial user sign‑in and token issuance, but not the subsequent Graph API calls. Exchange mailbox audit logs captured access events, but only for the Exchange workload, leaving SharePoint, Teams, and OneDrive blind spots. Azure Monitor data plane logs for Graph were in private preview and lacked correlation with user identity.

Graph Activity Logs, now generally available, close this gap. Each log entry records:
- The identity of the user whose token was used (user_id)
- The application (client) that made the call (app_id, app_display_name)
- The exact Graph endpoint invoked (requestUri)
- The HTTP method and response code
- The permissions required for that endpoint (requiredPermissions)
- The authenticated IP address and user‑agent string

These fields allow defenders to pivot from an Entra ID sign‑in event, through the Exchange Online mailbox audit, into the Graph operations themselves. For the first time, a suspicious pattern—like an agent reading 500 emails inside two minutes—can be correlated with the original consent grant and the mailbox log entries, pinning the activity to the exact user and app.

Correlating the Three Log Sources

A practical hunt starts in the Entra ID audit logs, looking for delegated permission grants that involve AI agent applications. The Consent to application event (activity ApplicationConsent) with ConsentType = “Delegated” is the trigger. Filter for appDisplayName containing terms like “agent”, “copilot”, “assistant”, or known agent publisher domains. Note the objectId of the app and the user who consented.

Next, pivot to Entra ID sign‑in logs. Look for sign‑ins from that app for the same user shortly after consent. A malicious agent will often have sign‑in events with clientAppUsed equal to PrtToRichCient or Browser (depending on the agent’s registration) and deviceDetail.isCompliant = false. While not definitive, these can surface unmanaged agents.

Now bring in Graph Activity Logs using the user’s upn and the app’s servicePrincipalId. Look for:
- High‑volume read operations on /me/messages or /users/{id}/messages
- Use of the $search or $filter parameter with broad queries (e.g., searching for “passwords” or “credentials”)
- Calls to /me/drive/root/search or /sites/{siteId}/drive/root/children that enumerate entire document libraries
- Mail.Send operations that forward messages to external addresses
- Unusual patterns like accessing a different user’s mailbox via /users/{anotherUser}/messages—this indicates the agent is abusing Mail.Read.Shared or Mail.ReadWrite.Shared

Finally, validate with Exchange mailbox audit logs. For any suspicious Graph message access, check if the same subject user accessed those exact items via Graph in the same time window. Exchange tracks the ClientInfoString with a value of “Client=Microsoft Graph;” for Graph operations. Aligning timestamps and item counts confirms that the Graph activity translated into actual mailbox reads.

For example, a hunt might produce a table like:

Cross‑referencing with Exchange mailbox audit log shows 467 MessageAccessed events for Alice in the same minute, confirming the data was read. The sendMail event is then visible in the mailbox’s Send action entry with the external recipient.

Hunting Queries for Sentinel and Log Analytics

Microsoft Sentinel users can operationalize these correlations. The following KQL query joins Entra ID consent grants with Graph Activity Logs to identify apps that have been granted Mail.Read and immediately started enumerating messages:

let consentApps = AuditLogs
| where ActivityDisplayName == \"Consent to application\"
| where parse_json(tostring(TargetResources[0].modifiedProperties))[0].displayName == \"ConsentType\"
| where tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue) == \"Delegated\"
| extend appId = tostring(TargetResources[0].id)
| project TimeGenerated, User = InitiatedBy.user.userPrincipalName, appId;
GraphActivityLogs
| where TimeGenerated > ago(7d)
| where parse_json(tostring(RequestUri)) has \"/messages\"
| join kind=inner consentApps on $left.AppId == $right.appId
| where TimeGenerated between (TimeGenerated1 .. (TimeGenerated1 + 1d))
| summarize RequestCount = count() by User, AppId, AppDisplayName, bin(TimeGenerated, 1h)
| where RequestCount > 100

Adjust the threshold based on normal behavior in your environment. A heavily used agent may legitimately read thousands of messages per day; look for abrupt spikes or accesses when the user is not actively working.

To catch email forwarding via Graph, extend the query:

GraphActivityLogs
| where parse_json(tostring(RequestUri)) has \"/sendMail\"
| where HttpMethod == \"POST\"
| extend recipients = parse_json(tostring(RequestBody)).message.toRecipients
| mv-expand recipients
| where recipients.emailAddress.address !endswith \"@contoso.com\"
| project Timestamp, UserId, AppId, AppDisplayName, ExternalAddress = recipients.emailAddress.address

Combine this with sign‑in data to see if the user was authenticated at the time—if the token was used while the user was offline, it’s a strong signal of token reuse or silent agent operation.

Real‑World Hunting Observations

Since Graph Activity Logs went live, hunters have uncovered several recurring patterns:

• Consent storm – A single user consent to a rogue AI agent is followed within seconds by an identical consent from another user, often using a phishing link that pre‑fills the consent screen. The logs show two ApplicationConsent events for the same app within a short window from different users.
• Graph enumeration without mailbox access – Some agents misuse Files.ReadWrite.All to exfiltrate SharePoint documents without touching email. Correlating Graph calls to /drive endpoints with OneDrive and SharePoint audit logs paints the full picture.
• Cross‑tenant delegation – Attackers registering a multi‑tenant agent app and using it to access customer tenants via delegated consent. Entra ID sign‑in logs show HomeTenantId differs from the resource tenant, and Graph Activity Logs show data movement to external IPs.
• Agent‑to‑agent relay – A low‑privilege agent exfiltrates data to a second Azure function via Graph, which then pushes it to a command‑and‑control server. The only visible evidence is an agent calling a single Graph endpoint that isn’t part of its normal pattern.

In one case, a finance department user consented to a “Smart Contract Reviewer” agent. Within an hour, the agent’s token was used to search every SharePoint site for “invoice” and “bank account,” then emailed an archive to a Gmail address via sendMail. Exchange mailbox logs confirmed the send, and Graph logs pinpointed the exact $search queries. Had defenders only monitored Entra ID sign‑ins, they would have seen a normal delegated sign‑in and missed the data theft entirely.

Building a Proactive Detection Strategy

Defenders must treat AI agent consent like any other OAuth grant and apply the same governance rigor. Key steps:

1. Catalog reputable agents. Maintain a list of known AI agent client IDs that your organization trusts. Alert on any consent to an agent not on that list.
2. Restrict user consent. Use Entra ID consent settings to limit user consent to verified publishers or require admin approval for high‑impact permissions like Mail.ReadWrite, Files.ReadWrite.All, and Sites.ReadWrite.All. The allowedToConsent policies can be scoped by permission classification.
3. Enable Graph Activity Logs immediately. They are ingested into Log Analytics and Sentinel at minimal cost and provide forensic granularity that was previously impossible.
4. Correlate logs programmatically. Deploy the above Kusto queries as scheduled analytics rules in Sentinel to generate incidents when a new agent consent is followed by abnormal Graph volume.
5. Monitor token lifetime. Use Continuous Access Evaluation (CAE) policies to revoke tokens when user risk changes, and set a short token lifetime for apps with high‑privilege delegated permissions.
6. Educate users on AI agent consent. Include agent consent in phishing simulations, because the consent prompt looks nearly identical to many legitimate productivity agents.

The Road Ahead

Microsoft is already working on richer Graph Activity Log fields, including claims and reqestedScp so that defenders can see exactly which delegated permissions were exercised in each call. Future builds will also include the UserAgent header from the application, enabling differentiation between a genuine Microsoft Copilot agent and a custom‑built attacker tool.

As assistive AI agents become embedded in daily workflow, the attack surface they create will only grow. The log correlation technique described here isn’t a one‑time fix; it’s a continuous cycle of observing normal agent behavior, detecting deviations, and refining detection rules. Every tenant that embraces AI assistants must also embrace the logging and hunting foundations that make those assistants safe to use.

For threat hunters and SOC analysts, June 2026 is the turning point. Delegated OAuth abuse by AI agents is no longer hidden in the noise. Graph Activity Logs, when correlated with the established Entra and Exchange logs, expose the entire kill chain—from consent to exfiltration—in stark detail. The data is there. The queries are ready. The only question is whether defenders will start hunting before the next agent‑based breach.