Microsoft Sentinel can be used to gain visibility into the read operations that Strike Graph performs against your connected systems during automated evidence collection. Because Strike Graph authenticates to your source systems using dedicated service identities (service principals, OAuth applications, IAM roles, etc.), those access events appear in your existing audit logs — which Sentinel can then ingest and monitor.

This approach is entirely managed outside of Strike Graph's platform, leveraging the audit infrastructure you already have in place with MS Sentinel.

How It Works

When Strike Graph collects evidence from your systems, it authenticates using a dedicated identity and performs read-only API calls. Those calls are logged by the source system (Microsoft 365, Azure, AWS, etc.) the same as any other API access. By identifying Strike Graph's service identity in each source system, you can build Sentinel queries and alert rules that surface exactly what Strike Graph accessed, when, and whether the operation succeeded.

Setup by Integration

Microsoft 365 / Azure AD

Audit log source: Microsoft 365 Unified Audit Log, ingested into Sentinel via the Microsoft 365 data connector or the Azure Active Directory data connector.

1. Identify the service principal or OAuth application registered for Strike Graph in your Azure AD tenant (typically visible under Azure AD → App Registrations or Enterprise Applications). Note its Application (client) ID and Object ID.

2. In Sentinel, query the AuditLogs and SigninLogs tables, filtering by the Strike Graph application ID:

AuditLogs | where InitiatedBy.app.appId == "<StrikeGraph_AppId>" | project TimeGenerated, OperationName, Result, TargetResources | order by TimeGenerated desc

SigninLogs | where AppId == "<StrikeGraph_AppId>" | project TimeGenerated, UserPrincipalName, ResourceDisplayName, Status, IPAddress | order by TimeGenerated desc

1. For Office 365 SharePoint activity, use the OfficeActivity table:

OfficeActivity | where UserId contains "<StrikeGraph_ServiceAccount>" | project TimeGenerated, Operation, OfficeWorkload, ClientIP, ResultStatus

AWS

Audit log source: AWS CloudTrail, ingested into Sentinel via the Amazon Web Services S3 data connector.

1. Identify the IAM role or IAM user that Strike Graph assumes when accessing your AWS account. This is typically an assumed-role session; note the Role ARN.

2. Query CloudTrail events in Sentinel using the AWSCloudTrail table:

AWSCloudTrail | where UserIdentityArn contains "<StrikeGraph_RoleARN>" | project TimeGenerated, EventName, EventSource, SourceIpAddress, ErrorCode, ErrorMessage | order by TimeGenerated desc

1. To focus specifically on evidence collection operations (S3 reads, Config reads, etc.):

AWSCloudTrail | where UserIdentityArn contains "<StrikeGraph_RoleARN>" | where EventSource in ("s3.amazonaws.com", "config.amazonaws.com", "iam.amazonaws.com") | summarize count() by EventName, EventSource, bin(TimeGenerated, 1h)

Azure (General / Azure Resource Manager)

Audit log source: Azure Activity Log and Azure AD Audit Logs, ingested via the Azure Activity data connector.

AzureActivity | where Caller contains "<StrikeGraph_ServicePrincipalId>" | project TimeGenerated, OperationName, ResourceGroup, ResourceProviderValue, ActivityStatus | order by TimeGenerated desc

Recommended Sentinel Analytics Rules

Once you have confirmed the baseline queries return expected results, consider creating the following analytics rules:

Creating a Baseline Workbook (Optional)

For ongoing visibility rather than just alerting, consider building a Sentinel Workbook with tiles covering:

• Daily evidence collection activity by source system

• Authentication success/failure ratio for the Strike Graph service identity

• Resource types accessed (broken down by integration)

• Geographic location of API calls (should be consistent with your Strike Graph deployment region)

Notes and Caveats

• Since this is a service operated and maintained by Microsoft, this documentation is provided as guidance only. There's little we can support in terms of troubleshooting, and we recommend confirming any changes you make in Sentinel against their API and other documentation best practices.

• Read-only by design. Strike Graph's integrations are scoped to read-only permissions. If your Sentinel queries surface any write operations from these identities, that warrants immediate investigation.

• Least-privilege review. While setting up these queries is a good opportunity to audit the permissions granted to Strike Graph's service identities and confirm they remain appropriately scoped.

• Token refresh activity. OAuth token refresh calls may appear frequently in sign-in logs and are expected behavior — these are not evidence collection events themselves.

• No real-time event stream from Strike Graph. This approach gives you visibility at the source-system level. Sentinel will show you what was accessed from your environment, but not Strike Graph's internal processing state (e.g., whether evidence was accepted, rejected, or attached to a specific control).

Getting the Right Identifiers

To use the queries above, you will need the service identity details for each integration. These can typically be found:

• Azure AD / M365: Azure Portal → Azure Active Directory → App Registrations → search for "Strike Graph"

• AWS: AWS IAM Console → Roles → search for "StrikeGraph" or review the cross-account role trust policy provided during onboarding

• Other integrations: Contact Strike Graph support to confirm the service identity used for each active integration in your account