Microsoft Foundry Logging: Entra ID Diagnostic Settings and the Identity Plane

The first post in this series established the four logging layers in Microsoft Foundry: Activity Log, Diagnostic Settings, Application Insights, and the Entra ID identity plane. The Entra ID identity plane logs were called out specifically and for good reason: without enabling them, agent sign-in activity and identity lifecycle events cannot be used to leverage Microsoft Sentinel's capabilities. This post covers how to close that gap.

Entra ID diagnostic settings provide the capability to query agent sign-in activity and identity lifecycle events beyond the platform's native limits (~30 days with P2 licensing). Diagnostic settings enable the streaming of Entra ID logs to a Log Analytics Workspace where retention, schema access, and cross-source correlation are fully under your control and all of which are a requirement for a reliable audit trail.

Every token exchange an AI Foundry agent performs produces sign-in entries, but the richest representation of those events are only available once exported. In Log Analytics, the AADServicePrincipalSignInLogs schema exposes fields (including agent-specific context) that are not consistently available in other experiences like Advanced Hunting.

Directory changes tell the other half of the story. The AuditLogs table is the primary source for events such as application registrations, permission grants, and credential updates. All of which are activities that define how agents are created and what they are allowed to do.

Other datasets, like MicrosoftGraphActivityLogs, have little to no meaningful retention unless explicitly exported. Without diagnostic settings in place ahead of time, that data is simply not recoverable.

This post walks through what to enable, what each table actually contains, and how to correlate identity-plane telemetry with Foundry resource logs once both datasets land in the same workspace.

Disclaimer: Diagrams and structural drafts were produced with AI assistance; the analysis, technical judgements, and text are my own unless stated otherwise.

This blog post will NOT delve into the agent authentication flow itself but it will instead focus on AI Foundry agent logging.

For a deeper understanding of how agent identities work (including agent authentication), Derk van der Woude has written an extensive series on agent identities worth reading first.

Every authenticated AI Foundry agent interaction generates entries across the Entra ID sign-in logs. The table those entries land in depends on which identity type is performing the authentication. For agents built on the Agent Identity model, two tables carry the relevant events: AADServicePrincipalSignInLogs for app-only authentication by Blueprint and Agent Identity principals, and AADNonInteractiveUserSignInLogs for delegated flows where an Agent User acts within a human user's context (look at the below diagram for more context). Both tables carry the Agent field, which is the only schema mechanism available in Log Analytics for distinguishing agentic sign-ins from ordinary service principal activity in a KQL query.

This section covers what those entries look like, how the two-event pattern per agent request appears in the logs, and how the Agent field is used to filter and classify them. For the architectural explanation of why the Agent Identity model is structured the way it is: Blueprints, federated identity credentials, the full token exchange chain, see Derk van der Woude's agent identity series , in particular the "From Blueprint to Token" post. This section covers the output of that architecture as it appears in the log tables, not the architecture itself.

The diagram below maps each agent identity type to its authentication event and the resulting Log Analytics table.

A single user request to a Foundry agent produces two entries in AADServicePrincipalSignInLogs, not one. Each represents a distinct authentication step in the token acquisition chain.

The first event, T1, is the Blueprint authenticating to the AAD Token Exchange Endpoint: Public endpoint (Resource ID: fb60f99c-7a34-4190-8149-302f77469936). The Blueprint is a service principal representing the logical definition of the agent type. It authenticates using a federated identity credential to obtain a short-lived signed assertion. This produces one row in AADServicePrincipalSignInLogs where ResourceDisplayName is AAD Token Exchange Endpoint: Public endpoint and ResourceIdentity is fb60f99c-7a34-4190-8149-302f77469936. Conditional Access does not evaluate this event: per the Entra Agent ID documentation , the intermediate token exchange to the AAD Token Exchange Endpoint: Public endpoint is explicitly excluded from Conditional Access enforcement because it does not involve resource access.

To surface T1 events in KQL:

KQL

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(1h)
| extend AgentInfo = parse_json(Agent)
| where isnotempty(AgentInfo)
| where AgentInfo.agentType =~ "agentIdentityBlueprintPrincipal"
| project TimeGenerated, ServicePrincipalId, ServicePrincipalName, ResourceDisplayName,
          ResourceIdentity, ResultType, ResultDescription, AgentInfo

The second event, T2, is the Agent Identity authenticating to the actual target resource: the Microsoft Foundry endpoint, Microsoft Graph, or any other service the agent is permitted to call. The Agent Identity is a separate service principal, derived from the Blueprint via the federated identity credential established at the Blueprint. It presents the T1 assertion to obtain an access token scoped to the actual resource. This produces a second row in AADServicePrincipalSignInLogs where ResourceDisplayName and ResourceIdentity are the target endpoint. Conditional Access evaluates this event but it requires Workload ID Premium licensing (more on this later). This is the event that matters for policy enforcement and detection.

Both rows share similar TimeGenerated values as the exchange typically completes within milliseconds, but carry different ServicePrincipalId and ServicePrincipalName values. The T1 row identifies the Blueprint; the T2 row identifies the Agent Identity instance.

To surface T2 events in KQL:

KQL

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(1h)
| extend AgentInfo = parse_json(Agent)
| where isnotempty(AgentInfo)
| where AgentInfo.agentType =~ "agenticAppInstance"
| project TimeGenerated, ServicePrincipalId, ServicePrincipalName, ResourceDisplayName,
          ResourceIdentity, ResultType, ResultDescription, AgentInfo

Three detection signals follow directly from this pattern:

A T1 event with no matching T2 within the expected time window may indicate a broken token exchange chain. The agent did not complete authentication. Correlating T1 to T2 requires time-window proximity combined with prior knowledge of which Agent Identities belong to which Blueprint: the two rows carry different ServicePrincipalId values (Blueprint on T1, AgentIdentity on T2), and there is no explicit join key within AADServicePrincipalSignInLogs linking a specific T1 row to its corresponding T2.
A T2 event with a ResourceIdentity value that does not match the agent's intended targets is a lateral movement or misconfiguration signal.
Multiple T2 events from the same Agent Identity targeting different resources in a short window warrants investigation for scope creep or potential credential abuse.

The matching T2 event for any given T1 row will share a close TimeGenerated timestamp. The ServicePrincipalId on the T2 row identifies the Agent Identity, which is distinct from the Blueprint's ServicePrincipalId on the T1 row.

The `Agent` Field: Identifying Agentic Sign-Ins

The Agent column in AADServicePrincipalSignInLogs and AADNonInteractiveUserSignInLogs is a JSON string field that is populated only when a sign-in is agentic. For non-agentic service principal sign-ins, the field is empty. It is the only native mechanism to distinguish agent token exchanges from ordinary service principal activity at query time.

The primary property within the JSON is agentType. The values it takes, and what each means for SecOps, are as follows:

`agentType`	`agentSubjectType`	Identity type	Log table	Authentication context
`agentIdentityBlueprintPrincipal`	✗	Blueprint (Service Principal)	`AADServicePrincipalSignInLogs`	T1 token exchange to `AzureADTokenExchange`
`agenticAppInstance`	✗	Agent Identity (Service Principal)	`AADServicePrincipalSignInLogs`	T2 access token for target resource
`agenticAppInstance`	`agentIDuser`	Agent User (non-human user account)	`AADNonInteractiveUserSignInLogs`	Delegated OBO flow acting in user context

In Log Analytics, the core pattern for isolating all agentic sign-ins and classifying them by type:

KQL

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| extend AgentInfo = parse_json(Agent)
| where isnotempty(AgentInfo)
| extend AgentType = tostring(AgentInfo.agentType)
| where AgentType has_any ("agentIdentityBlueprintPrincipal", "agenticAppInstance")
| extend IsT1Exchange = ResourceIdentity has "fb60f99c-7a34-4190-8149-302f77469936"
| project TimeGenerated, ServicePrincipalId, ServicePrincipalName,
          AgentType, IsT1Exchange, ResourceDisplayName, ResourceIdentity,
          ClientCredentialType, ConditionalAccessStatus, ResultType,
          ResultDescription, AgentInfo

One caveat applies before operationalising any query that uses parse_json(Agent).

The Agent field does not exist in the Advanced Hunting EntraIdSpnSignInEvents table. This is the single most consequential schema gap between Log Analytics and Advanced Hunting for AI Foundry agent logging. Without it, there is no persistent, KQL-queryable mechanism to distinguish agent token exchanges from regular service principal sign-ins in a Sentinel analytics rule. This point is the subject of the next section.

Does Advanced Hunting Cover the Same Ground?

No.

Advanced Hunting and Entra ID diagnostic settings are complementary: they surface different data at different schema depths with different retention limits, even when queried from the same portal.

The question comes up more often now because the Defender portal provides a unified query surface. When Microsoft Sentinel is onboarded to the Defender portal (generally available, with the Azure portal version of Sentinel reaching end of life in March 2027), Advanced Hunting can query both Defender XDR tables and Sentinel LAW tables from a single interface. Teams working in this environment see EntraIdSpnSignInEvents and AADServicePrincipalSignInLogs in the schema panel and reasonably ask whether one makes the other redundant. They do not.

The diagram below shows the two data paths that the unified Advanced Hunting interface draws from.

The two paths are not the same data, not the same schema, and not interchangeable.

Note: EntraIdSignInEvents, EntraIdSpnSignInEvents, and GraphApiAuditEvents reached general availability in February 2026. They were in preview when the schema comparisons below were first documented. The field-level differences described here reflect the current GA versions.

Schema Gaps: Fields That Only Exist in Diagnostic Settings

The most consequential difference between EntraIdSpnSignInEvents (Advanced Hunting) and AADServicePrincipalSignInLogs (LAW via diagnostic settings) is a single column: Agent. Without it, there is no KQL-queryable mechanism within the Defender XDR tables to distinguish agentic token exchanges from ordinary service principal activity. Filtering by agentType, classifying Blueprint versus Agent Identity events, and writing analytics rules that target the T1/T2 event pair all depend on this field. It does not exist in the Advanced Hunting schema.

The following fields are present in AADServicePrincipalSignInLogs but absent from EntraIdSpnSignInEvents:

Field	Purpose for agent SecOps
`Agent`	Contains the `agentType` JSON. The only mechanism to identify agentic sign-ins in KQL. Filtering by Blueprint versus Agent Identity versus Agent User authentication requires this field.
`FederatedCredentialId`	Confirms federated identity credential usage per sign-in. Required for credential hygiene audits at scale: verifying agents authenticate with FIC rather than client secrets.
`ClientCredentialType`	Identifies the credential type used for each sign-in. Detects agents authenticating with client secrets where FIC is expected.
`ConditionalAccessPolicies`	Full JSON of all Conditional Access policies evaluated, including policy names, enforcement modes, and block or grant outcomes. `EntraIdSpnSignInEvents` contains no Conditional Access columns at all: neither the full policy JSON nor an integer status code.
`AuthenticationProcessingDetails`	Step-by-step authentication chain detail. Required for debugging OBO flow failures and tracing the full token exchange sequence.
`NetworkLocationDetails`	Authentication processor network context, including geolocation and IP category.
`AutonomousSystemNumber`	ASN of the requesting entity. Detects token requests originating from unexpected network infrastructure.
`AuthenticationContextClassReferences`	Authentication context class references for step-up Conditional Access enforcement. Required to verify step-up policies are being applied to agent identities.

The same pattern applies to Graph API activity. MicrosoftGraphActivityLogs (LAW) carries fields that GraphApiAuditEvents (Advanced Hunting) does not: ClientAuthMethod encodes how the client authenticated for each API call (public client, client secret, or certificate), enabling detection of Graph calls made with client secrets rather than FIC. SignInActivityId is the explicit foreign key to the corresponding row in AADServicePrincipalSignInLogs, making Graph-to-sign-in correlation precise rather than dependent on timestamp and principal approximation.

Both queries below can be run from the unified Advanced Hunting interface in the Defender portal when Sentinel is onboarded. Run them against the same time window to compare what each table actually contains for your service principals.

KQL

// MicrosoftGraphActivityLogs — LAW table with credential type and sign-in join key
MicrosoftGraphActivityLogs
| where TimeGenerated > ago(1h)
| where isnotempty(ServicePrincipalId)
| extend CredentialType = case(
    ClientAuthMethod == 0, "PublicClient",
    ClientAuthMethod == 1, "ClientSecret",
    ClientAuthMethod == 2, "Certificate",
    "Unknown")
| project TimeGenerated, ServicePrincipalId, RequestMethod, RequestUri,
          ResponseStatusCode, ClientAuthMethod, CredentialType, SignInActivityId

KQL

// GraphAPIAuditEvents — Advanced Hunting table; CredentialType and SignInActivityId absent
GraphAPIAuditEvents
| where Timestamp > ago(1h)
| where isnotempty(ServicePrincipalId)
| project Timestamp, ServicePrincipalId, RequestMethod, RequestUri,
          ResponseStatusCode, Scopes

The gap is equally significant for identity lifecycle events. GraphApiAuditEvents does not capture Entra directory operations. Blueprint creation and deletion, permission grants to Agent Identity service principals, credential additions to Blueprint applications, and Entra role assignments to agent identities are directory operations. They appear in AuditLogs (via diagnostic settings) only. There is no Advanced Hunting equivalent for agent identity lifecycle auditing.

Retention: Why Thirty Days Falls Short

Defender XDR tables retain data for 30 days by default. The Entra admin portal retains sign-in logs for 30 days under P1 or P2 licensing and 7 days on the free tier. Once routed to a Log Analytics Workspace via diagnostic settings, the LAW's own retention setting governs: 90 days by default, configurable to 2 years, with optional extension to 12 years via the Sentinel data lake.

MicrosoftGraphActivityLogs is a specific exception worth calling out on two counts. First, retention: there is zero native retention for this category in the Entra portal, regardless of licence. The diagnostic settings export is the ONLY mechanism for retaining Graph API activity data. Without it, Graph API calls from agent service principals leave no persistent audit trail anywhere. Second, schema depth: the LAW table carries fields absent from GraphApiAuditEvents, including ClientAuthMethod (the credential type used for the API call, distinguishing public client, client secret, and certificate) and SignInActivityId (an explicit join key to the corresponding sign-in event in AADServicePrincipalSignInLogs). Both fields are only available once the category is exported to a LAW.

A clarification on what the unified portal does and does not change: onboarding Sentinel to the Defender portal provides a unified query interface over two separate data stores. It does not copy Advanced Hunting data into the LAW or extend its 30-day retention period. When the window closes on EntraIdSpnSignInEvents, that data is gone regardless of how the LAW is configured.

For Microsoft Foundry agent logging specifically, 30 days is operationally insufficient for four reasons:

Reason	Why 30 days is insufficient	MITRE ATT&CK relevance
Behavioural baselines	Agent authentication patterns require weeks to months of historical data to baseline. Volume, resource targets, timing, and failure rate trends cannot be reliably modelled over 30 days. Anomalies are only detectable against a stable baseline.	TA0003 Persistence, TA0001 Initial Access — long-term footholds and credential abuse that surface only as statistical deviations from baseline.
Slow-burn attacks and staged exfiltration	Adversaries deliberately operate below detection thresholds, spreading exfiltration or lateral movement across weeks. 30-day windows are a known constraint that attackers exploit by design.	TA0010 Exfiltration, T1030 Data Transfer Size Limits — staged transfers kept small and infrequent to avoid volume-based detection.
Post-incident forensics	Investigations frequently begin after the initial triage window. By the time an alert is escalated, scoped, and assigned, the relevant authentication events may already be outside a 30-day window.	Full kill chain — forensics must reconstruct TA0001 through TA0011 Command and Control across the complete attack timeline, not just the final events.
Regulatory and compliance requirements	The Azure Security Benchmark, ISO 27001, and NIST CSF specify 90 to 180 day minimum retention for authentication logs. 30-day retention creates an audit gap that cannot be closed retrospectively.	Compliance controls map across TA0006 Credential Access and TA0005 Defense Evasion — the tactics that authentication logs are specifically retained to detect and evidence.

For organisations subject to the EU AI Act, Mark Schuijt and Niek Jachimowski have written an overview of how Microsoft Foundry maps to EU AI Act obligations, covering inventory, classification, audit trails, and access governance. Worth reading alongside this post.

Correlation: Foundry Resource Logs Are Not in Defender XDR

Foundry resource logs route to the Log Analytics Workspace configured on the Foundry resource. The relevant categories (Audit, RequestResponse, AzureOpenAIRequestUsage) land in AzureDiagnostics with ResourceType == "MICROSOFT.COGNITIVESERVICES/ACCOUNTS". No equivalent table exists in the Defender XDR schema. There is no path to Foundry resource log data through Advanced Hunting.

The analytical consequence is direct. The question "which agent identity authenticated, under which Conditional Access policies, to produce this specific inference request?" requires joining sign-in data with Foundry audit data. That join is not possible from Advanced Hunting alone.

When Entra ID sign-in logs and Foundry resource logs co-reside in the same Log Analytics Workspace, a single KQL JOIN bridges the identity and data planes. When MicrosoftGraphActivityLogs is also present, SignInActivityId provides a direct foreign key from any Graph API call to its corresponding row in AADServicePrincipalSignInLogs, making the Graph-to-sign-in join exact rather than relying on timestamp and principal approximation. The correlation query pattern will be covered in detail in Blog 003 in this series, once both datasets are in place.

The Role Advanced Hunting Still Plays

Advanced Hunting is the right tool for four specific analytical scenarios. The argument is not to dismiss it but to use it where it performs best rather than as a substitute for a properly configured LAW pipeline.

Cross-product threat hunting. EntraIdSpnSignInEvents can be joined with AlertEvidence, DeviceEvents, CloudAppEvents, and EmailEvents in a single query. This cross-product breadth is Advanced Hunting's strongest capability. No LAW-only configuration provides equivalent reach across the full Microsoft security stack without significant additional data connector work.

Incident response triage. A 30-day lookback covers the typical initial compromise window for most IR investigations. The Defender portal Advanced Hunting interface is optimised for investigation speed, with inline incident context and quick entity pivoting. For triage work that does not require richer schema fields, it is faster than querying a LAW directly.

Graph API endpoint investigation. GraphApiAuditEvents surfaces which Graph API endpoints are being accessed, by which service principal, with which permission scopes. Useful for targeted investigation of unexpected Graph activity without a MicrosoftGraphActivityLogs routing configuration in place.

Unified portal convenience. When Sentinel is onboarded to the Defender portal, Sentinel LAW tables are queryable directly from Advanced Hunting alongside Defender XDR tables. A single query can combine the depth of AADServicePrincipalSignInLogs (with the Agent field) and the cross-product breadth of Advanced Hunting. The limitation is that Advanced Hunting does not support persistent scheduled analytics rules in Sentinel's format. Cross-product queries are possible; automated alerting on those queries is not, via the Advanced Hunting path alone.

Advanced Hunting alone is not sufficient for: persistent detection alerting, long-term behavioural baselines, agent lifecycle auditing, and any use case requiring a join with Foundry resource logs.

Enabling Entra ID Diagnostic Settings

Entra ID diagnostic settings are configured at the tenant level, not on the Foundry resource. This is a distinct configuration surface from Azure resource-level diagnostics, which are set on the Foundry Hub in the Azure portal. The configuration is accessible from two locations:

Microsoft Entra admin center: entra.microsoft.com > Identity > Monitoring & health > Diagnostic settings
Azure portal: portal.azure.com > Microsoft Entra ID > Monitoring > Diagnostic settings

Both surfaces configure the same tenant-level settings. The Entra admin center is the dedicated identity management surface; the Azure portal path is convenient when already working within a broader Azure deployment.

The required role is Security Administrator at the tenant level.

Multiple diagnostic settings can co-exist, routing different log categories to different destinations. For Foundry deployments, all agent-relevant categories should route to the same destination workspace to enable cross-table correlation.

Which Categories to Enable

The table below uses the exact category names as they appear in the Entra diagnostic settings wizard, alongside the resulting LAW table name and priority for Foundry agent logging.

Diagnostic Category	LAW Table	Purpose	Priority
ServicePrincipalSignInLogs	`AADServicePrincipalSignInLogs`	Blueprint T1 and Agent Identity T2 token exchanges. Primary agent authentication log.	Required
AuditLogs	`AuditLogs`	Agent Identity lifecycle: creation, deletion, permission grants, credential changes, Blueprint updates.	Required
NonInteractiveUserSignInLogs	`AADNonInteractiveUserSignInLogs`	Delegated OBO flows where an Agent User acts within a human user's context.	Required
MicrosoftGraphActivityLogs	`MicrosoftGraphActivityLogs`	Graph API calls from agent service principals. Zero retention without this export.	Recommended
SignInLogs	`SignInLogs`	Interactive user sign-ins. Useful for OBO correlation and user authentication baselines.	Recommended
ManagedIdentitySignInLogs	`AADManagedIdentitySignInLogs`	Managed identity sign-ins if any agents authenticate via managed identity rather than Agent Identity.	Recommended
RiskyServicePrincipals	`RiskyServicePrincipals`	ID Protection risk signals for agent service principals. Workload ID Premium required.	Optional
ServicePrincipalRiskEvents	`ServicePrincipalRiskEvents`	Service principal risk event detail. Workload ID Premium required.	Optional

MicrosoftGraphActivityLogs deserves a specific note. Unlike all other categories, there is no native retention for this data anywhere in the Entra portal, regardless of licence. The diagnostic settings export is the only mechanism for retaining Graph API activity. Treating this category as optional means accepting that Graph API calls from agent service principals leave no persistent audit trail.

Destination: The Same Workspace as Foundry Resource Logs

Routing Entra ID diagnostic settings to the same Log Analytics Workspace as the Foundry resource diagnostic settings is not a recommendation. It is a prerequisite for every identity-to-data-plane correlation query described in this post and in the subsequent posts in this series.

In the diagnostic settings wizard, select "Send to Log Analytics workspace" under Destination details, then select the same subscription and workspace as the Foundry Hub's diagnostic settings.

Allow up to 15 minutes for sign-in logs to begin appearing after initial configuration. First-time tenant activation can take up to three days per Microsoft's documentation; per-setting latency for existing tenants is typically within 15 minutes.

The LAW's own retention configuration governs these tables, not the Entra portal's 30-day display limit. A workspace configured for 90-day retention retains AADServicePrincipalSignInLogs for 90 days regardless of what the admin portal shows.

For CAF/ALZ deployments with multiple Log Analytics Workspaces, two options apply: route Entra diagnostic settings to a central hub workspace and accept that per-workload Foundry correlation requires cross-workspace queries, or align Foundry resource logging to target the same hub workspace used for Entra data. Blog 003 will cover the workspace topology decision in the context of enterprise-scale deployments.

Multiple diagnostic settings routing to different destinations simultaneously is supported. Each additional destination incurs separate ingestion costs for the duplicated categories.

Prerequisites and Licensing

Role: Security Administrator at the Entra tenant level. This must be an Entra directory role assignment, not a subscription-level Azure RBAC role.

Workspace: The target Log Analytics Workspace must exist before configuring diagnostic settings. The wizard does not create new workspaces.

Licence requirements:

Licence	What it enables for diagnostic settings
Entra ID P1	Minimum requirement for routing `ServicePrincipalSignInLogs`, `NonInteractiveUserSignInLogs`, and `SignInLogs` to a LAW.
Entra ID P2	Richer ID Protection signals in sign-in log rows: `RiskDetail` as a descriptive string, `RiskLevelDuringSignIn`, and `RiskState` at string level rather than numeric codes. Also required for `EntraIdSpnSignInEvents` in Advanced Hunting.
Workload ID Premium	Required for `RiskyServicePrincipals` and `ServicePrincipalRiskEvents` categories. Also enables Conditional Access for Agents and ID Protection for Agents.
MicrosoftGraphActivityLogs	Available at P1 or P2. No additional licence required beyond P1.

Log Analytics pricing tiers:

LAW Table	Basic Logs eligible	Notes
`AADServicePrincipalSignInLogs`	Yes	Lower ingestion cost per GB at Basic Logs tier. Trade-off: 30-day interactive query retention (no joins or cross-table queries). Use Analytics tier for security analytics requiring joins across tables or longer retrospective access. Basic Logs is sufficient for single-table alerting rules.
`AADNonInteractiveUserSignInLogs`	Yes	Same Basic/Analytics trade-off as above.
`AuditLogs`	No	Analytics tier only. No Basic Logs option. Factor full analytics-tier ingestion cost into planning.
`MicrosoftGraphActivityLogs`	Yes	Basic Logs eligible.

For Sentinel deployments targeting behavioural analytics and retrospective investigation, Analytics tier for sign-in tables is the correct choice. Basic Logs is viable only when the use case is limited to real-time alerting with no retrospective query requirement.

Key Takeaways

Entra ID diagnostic settings are the foundation for Microsoft Foundry agent security operations, not an optional enhancement. The Agent field, full Conditional Access policy detail, FederatedCredentialId, and all agent identity lifecycle data in AuditLogs are available only via Log Analytics tables. None of these fields exist in Advanced Hunting.
Route all agent-relevant categories to the same Log Analytics Workspace as Foundry resource logs. The identity-to-data-plane JOIN is the primary analytical output of this configuration and is only possible when both datasets co-reside in the same workspace.
The Agent column in AADServicePrincipalSignInLogs and AADNonInteractiveUserSignInLogs is the only native mechanism to identify and filter agentic sign-ins in KQL. It is absent from Advanced Hunting tables. Without it, distinguishing agent token exchanges from ordinary service principal activity requires fragile heuristics.
Advanced Hunting is a valid complement for cross-product threat hunting over a 30-day window and for incident response triage. It is not a substitute for persistent, correlated, long-retention identity plane logging. The two data sources serve different analytical roles and work best in combination from the unified Defender portal.
AuditLogs (via diagnostic settings) is the only source for agent identity lifecycle events. Blueprint creation, permission grants, credential additions, and deletions do not appear in any Advanced Hunting table. Without AuditLogs, the agent identity audit trail is invisible to Sentinel analytics rules.
MicrosoftGraphActivityLogs should be treated as required, not recommended. It is the only source for Graph API activity retention: there is no native retention in the Entra portal regardless of licence. Beyond retention, the LAW table carries ClientAuthMethod (credential type per API call, enabling detection of secret-based Graph calls where FIC is expected) and SignInActivityId (a direct foreign key to AADServicePrincipalSignInLogs). Neither field exists in GraphApiAuditEvents. Without this category exported, Graph API activity from agent service principals leaves no persistent audit trail and no precise sign-in correlation path.