Make access through OneLake external data sharing identifiable in OneLake diagnostics logs

I used Microsoft Fabric OneLake external data sharing to share OneLake data from Tenant A with Tenant B.

OneLake diagnostics was enabled on the Tenant A side.

After that, a user in Tenant B accessed the shared data, and an access record was output to the OneLake diagnostics logs on the Tenant A side.

At that time, the logs did not record the Tenant B user. Instead, the user who created the external data share in Tenant A was recorded in the executingUpn column.

I understand that this behavior may be by design, because the external tenant user information may not be directly displayed in the provider tenant, or because access through external data sharing may be recorded under the permission context of the user who configured the share in the provider tenant.

However, from an audit and security investigation perspective, it is difficult to determine from the logs alone whether the access was a direct access by an internal user in Tenant A or an access by a user in Tenant B through external data sharing.

External data sharing is an important feature for securely sharing data across tenants.

Therefore, I would like OneLake diagnostics logs to clearly identify when access is made through external data sharing.

For example, the following types of improvements would be helpful:

Example:
・accessContext = External data sharing
・accessType = External share access
・isExternalDataSharingAccess = true

・Or display additional information for executingUpn, such as:
　・External tenant user
　・Access via external data sharing

It is not necessary to show the actual UPN of the external tenant user.

At a minimum, I would like the logs to make it possible to distinguish between direct access by an internal user in the provider tenant and access through external data sharing.

This would allow Fabric administrators and data owners to more accurately distinguish expected access through external data sharing from direct access by internal users when reviewing OneLake diagnostics logs.

In enterprise environments, auditability and traceability for cross-tenant data sharing are important. Therefore, I believe this improvement would be very useful for operating OneLake external data sharing.