Hi @dtb_usr 

Good day!!

Materialized views created by DLT now enforce file-level access using the identity of the pipeline owner. This means that any file-level operations—such as refreshes or updates—on materialized views are performed using the credentials and privileges of the pipeline owner, ensuring consistent access enforcement.

How Identity Enforcement Works

• When a DLT pipeline creates and maintains materialized views (MVs), all file-level access is executed as the pipeline owner.
• If the pipeline owner changes (for example, if ownership is transferred due to the owner leaving the company or through a managed process), all related assets—including materialized views—are re-owned by the new pipeline owner. Future DLT runs and file accesses are performed as this new owner.
• These enforcement rules ensure that:
  • Access checks for backing data happen using the current pipeline owner’s credentials.
  • After ownership changes, historical grants (such as SELECT on existing MVs) and other permissions remain intact, but future operations are controlled by the new owner.
     
• This approach eliminates the risk of lingering access if the original owner leaves the organization and centralizes control, making it clear which identity is responsible for access.

Important Limitations & Permissions

• To change the pipeline owner (and thus the identity used for file-level access), a user must have both workspace admin and metastore admin privileges.
• The new owner immediately becomes responsible for all DLT-managed resources, and all file-level accesses by DLT MVs are run with their privileges.
• Non-admin users and pipeline owners themselves cannot arbitrarily transfer ownership to others, reducing risk of privilege escalation.
   
• Pipeline ownership must always map to a single user (not a group). Service principal support is planned but not yet available for all configurations.