# Do not treat an app-governance activity count as a retained Graph audit trail

> Why might an OAuth threat alert show a spike without containing every underlying API activity?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-302-do-not-treat-an-app-governance-activity-count-as-a-retained-graph-audit-trail/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:26:54+00:00
- Modified: 2026-09-10T01:40:02+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Why might an OAuth threat alert show a spike without containing every underlying API activity?

## Potentially affected

OAuth application threat-detection alerts generated by Defender for Cloud Apps app governance.

## DSE recommendation

Preserve the alert's aggregate indication and collect available activity records as separate evidence sources.

## Article

## Source facts

Microsoft says app-governance threat detection counts activities using transient data that may not be stored. An alert can therefore report a count or spike without including every related activity. For OAuth applications’ Microsoft Graph calls, the tenant can audit the activities through Log Analytics and Sentinel. The documented detections are nondeterministic and depend on behavior departing from the norm. [Microsoft Learn](https://learn.microsoft.com/en-us/defender-cloud-apps/app-governance-anomaly-detection-alerts).

## Applicability

Identify the app-governance alert, application and interval under investigation. Determine which activity logging was actually available for that interval; the documentation does not establish that it was configured in your tenant. Keep the alert’s aggregate observation distinct from individually retrievable calls and from an analyst’s conclusion.

## DSE recommendation

Preserve the alert’s aggregate indication and collect available activity records as separate evidence sources. Have the application owner explain expected activity while the responder examines the recorded calls, permissions and relevant changes. Mark missing underlying records as an evidence limitation rather than inventing a transaction list from the displayed count. For future investigations, review the tenant’s Graph activity-audit coverage and access with the logging owner.

## Verification

Compare the alert’s time and application identity with the available audit records, noting differences in coverage instead of forcing their totals to agree. Document which conclusions are supported by individual events and which rely only on the aggregate detection. In a controlled readiness exercise, verify that authorized responders can retrieve expected Graph activity through the configured logging path. Do not use the absence of a reproducible alert as a test of whether those records were retained.

## Official references

[Microsoft Learn: Investigate OAuth app threat detection alerts](https://learn.microsoft.com/en-us/defender-cloud-apps/app-governance-anomaly-detection-alerts). Source reviewed September 9, 2026.

## Primary reference

- Name: Investigate OAuth app threat detection alerts with app governance - Microsoft Defender for Cloud Apps | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/defender-cloud-apps/app-governance-anomaly-detection-alerts
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Do not treat an app-governance activity count as a retained Graph audit trail,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-302-do-not-treat-an-app-governance-activity-count-as-a-retained-graph-audit-trail/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.
