Documentation of Authorization evidence field in Activity Logs

Hello @Neel Manthani

Thank you for posting your query on Microsoft Q&A platform.

Microsoft does not provide any official documentation that defines, guarantees, or supports using the authorization.evidence.roleAssignmentId field in Azure Activity Logs to determine which specific role assignment (direct or group-based) authorized an action.

Because of this, the field cannot be relied on for audit‑grade or deterministic analysis, especially in scenarios involving group-based assignments or multiple effective role assignments.

Microsoft documentation for Azure Activity Logs clearly defines what is guaranteed to be logged:

• The operation/action
• The scope
• The caller
• The status

This is documented in the Azure Activity Log schema. No guarantee is given that RBAC evaluation details (such as which specific role assignment enabled access) are logged

Reference: Azure Activity Log event schema https://learn.microsoft.com/azure/azure-monitor/platform/activity-log-schema

Based on Microsoft documentation:

• Azure Activity Logs are not an RBAC decision trace
• They do not document RBAC evaluation paths, group membership resolution, or precedence
• authorization.evidence.roleAssignmentId is not documented as complete, deterministic, or authoritative

Microsoft only supports Activity Logs for recording what happened, not why a specific RBAC path allowed it.

Reference: Azure Monitor Activity Log overview https://learn.microsoft.com/azure/azure-monitor/platform/activity-log

So, At this time, Microsoft does not provide official documentation that supports using the authorization.evidence.roleAssignmentId field from Azure Activity Logs as a reliable indicator of which RBAC role assignment (direct or group-based) authorized an action. The field should therefore be treated as best‑effort metadata only and not as authoritative audit evidence.

Kindly let us know if the solution provided worked for you.

If you need any further assistance, please feel free to reach out.

If you found the comment helpful, please consider clicking "Upvote it".

Thanks,
Suchitra.

"Microsoft documentation for Azure Activity Logs clearly defines what is guaranteed to be logged:

• The operation/action
• The scope
• The caller
• The status"

Where is the above clearly defined? I searched both referenced pages https://learn.microsoft.com/azure/azure-monitor/platform/activity-log-schema + https://learn.microsoft.com/azure/azure-monitor/platform/activity-log and found no mention of any data guarantees.

Hello @Neel Manthani

The authorization.evidence block including roleAssignmentId, roleDefinitionId, principalId, principalType, role, and roleAssignmentScope is documented as part of the Activity Log schema in the official Azure Activity Log event schema reference page, where it appears in the sample JSON for Administrative category events.

However, what is not documented is the behavioral semantics of this field. Specifically:

Multiple Assignments: Microsoft does not document how the ARM RBAC engine selects which roleAssignmentId to log when a caller has multiple effective role assignments (e.g., a direct assignment plus group membership). There is no published documentation describing the precedence or selection logic used to populate the evidence block.

Missing Evidence: Microsoft does not document specific scenarios (such as denied actions, specific resource providers, or system identities) where the evidence block may be omitted or left empty, even though an authorization block is present in the log entry.

The Activity Log documentation describes what happened (the operation, caller, scope, status, and timestamp), and the schema shows the structure of the authorization.evidence object. But it does not provide behavioral guarantees about the completeness or determinism of the evidence field meaning you cannot assume it will always be populated, or that it will reflect a specific RBAC evaluation path when multiple role assignments apply.

For audit-grade monitoring of group-based role usage, consider supplementing Activity Logs with:

• Azure RBAC change tracking via Activity logs for Azure RBAC changes, which documents role assignment create/delete operations.
• Privileged Identity Management (PIM) for just-in-time access and audit trails on privileged role activations.
• Microsoft Entra ID Audit Logs for Entra role assignment changes and sign-in details.

The authorization.evidence field is documented in the schema, but its population behavior is not formally specified. Treat it as informational metadata rather than a deterministic RBAC decision trace until Microsoft publishes behavioral documentation for this field.

If you have any further questions, please feel free to reach out.

Thanks,

Suchitra.