What is NOT changing

• Base table access checks for views: These will still be evaluated using the owner’s identity, which means session users can still query views without direct privileges on the underlying tables.
• Access checks to dependencies for views and functions: Access checks to tables, views, other functions, and other dependencies will still use the owner’s identity.
• Non-view-based access: Behavior remains unchanged when data access does not involve views or functions.

Example

If alice@company.com queries sales_view, which references a table sales_gold with an ABAC row filter:

• Today: The filter on sales_gold is evaluated against the view owner's identity. Alice sees what the owner of sales_view is allowed to see.
• After April 28, 2026: The filter is evaluated against Alice's identity. Alice sees only the rows she is authorized to access, as defined by the ABAC row filters on the sales_gold table. Similarly, when a function accesses the sales_gold table, those policies are evaluated using Alice's identity.

How to opt in

You can opt into the new behavior at your own pace before it becomes the default for all policies on July 27, 2026, using one of two methods:

• Account-level setting applies the new behavior to all policies in your account. This is useful when you want to validate or adopt the new behavior consistently across your environment. When enabled, this setting overrides per-policy configuration. 
• Per-policy API use_session_identity field applies the new behavior to individual policies, either existing policies or new policies at creation time. This is useful when you want to review gradually, policy by policy.

Account-level setting

The setting is available in the account console under the Previews section. To enable this setting, set the following toggle to On.

Per-policy API field use_session_identity

The use_session_identity field is a boolean on the policy object. You can set it when creating a new policy or update it on an existing policy through the Unity Catalog ABAC policies REST API.

curl --location \
  'https://<workspace-url>/api/2.1/unity-catalog/policies' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <token>' \
  --data '{
      "use_session_identity": true,
      "on_securable_fullname": "<catalog-name>",
      "on_securable_type": "CATALOG",
      "name": "<policy-name>",
      "to_principals": [
          "account users"
      ],
      "policy_type": "POLICY_TYPE_ROW_FILTER",
      "for_securable_type": "TABLE",
      "match_columns": [
          {
              "condition": "hasTagValue(\"<tag-key>\",\"<tag-value>\")",
              "alias": "u0"
          }
      ],
      "row_filter": {
          "function_name": "<catalog>.<schema>.<function-name>",
          "using": [
              {
                  "alias": "u0"
              }
          ]
      }
  }'

Update an existing policy to enable session identity

curl --location --request PATCH \
  'https://<workspace-url>/api/2.1/unity-catalog/policies/<on_securable_type>/<on_securable_fullname>/<policy-name>' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <token>' \
  --data '{
      "use_session_identity": true
  }'

Verify the setting on a policy

The response includes "use_session_identity": true or false. 

curl --location \
  'https://<workspace-url>/api/2.1/unity-catalog/policies/<on_securable_type>/<on_securable_fullname>/<policy-name>' \
  --header 'Authorization: Bearer <token>'

How to assess impact

Review your environment before July 27, 2026.

Step 1: Identify access through views and functions

Use the diagnostic notebook to identity views and functions that reference ABAC-protected tables. The notebook takes a CSV file as input, and the filename is your Databricks account ID. Databricks should have provided all relevant files for your account IDs with the email notification. If you did not receive the relevant files, contact your Databricks account team or Databricks Support.

After running the code, the notebook helps you identify:

• Views that reference ABAC-protected tables, and their owner info
• Functions that reference ABAC-protected tables
• The base tables referenced
• The policies involved
• The users or groups those policies currently apply to, and the exempted users

Step 2: Review policy outcomes before and after the change

Opt into the new behavior and review whether your policies produce the intended access outcomes.

In particular, review whether:

• Users who query views continue to receive filtered or masked access.
• Any users currently granted access to data records based on the baseline access of view or function owners should instead be governed directly through policy conditions.

For each policy + view/function + base table combination, we recommend the assessment outlined in the chart below. This assessment requires MANAGE or ownership on the relevant securables to view policy definitions and object grants. See the Manage privileges in Unity Catalog (AWS | Azure | GCP) documentation for the full privilege requirements.

1. Policies set on materialized views or streaming tables?

If Yes, no action is needed in this case.

The evaluation model does not change with the switch to session identity. Refresh operations continue to be performed using the identity of the pipeline owner or the “run as” identity, while data access continues to be through the querying user, like today.

2. Views or tables are Delta Shared?

If Yes, you only need to review your setup if you have shared views.

For shared tables, the switch to session identity does not change access at the recipient  side. The share owner was already exempted from the policy, so the recipient receives full records and policies need to be set on the recipient side to control sensitive data access.

For shared views, the exemption requirement changes on the provider side:

• Before: The view owner had to be exempted from the policy to share the view.
• After: The share owner must be exempted from the policy to share the view.

3. Does the policy actually apply to this base table?

If No, no action is needed in this case.

A policy may be set on the scope where the base table is, but have no effect on it if the table's and table columns’ tags do not match the policy's WHEN condition and MATCH COLUMNS expression. If the policy conditions do not match, it is safe to ignore this combination.

4. Does the policy apply to the view/function owner today?

Check whether the owner is in the TO list and not in the EXCEPT list.

Scenario A: NO, the policy does NOT apply to the owner 

Then, after the switch, users in the policy’s TO list may see less data than before because the policy will start applying to them. Review this setup to make sure it reflects your intent.

• Before: No filtering or masking occurs for anyone querying this view or function, because the policy evaluates against the owner, and the owner is not subject to it. 
• After: Querying users who are in the TO list (and not in EXCEPT) may start seeing filtered or masked data.
  • If you intend for querying users to see filtered or masked data through this view or function, verify the TO and EXCEPT lists include the correct principals, communicate the change to affected users, and set use_session_identity = true on this policy.
  • If you do not intend to filter/mask data, modify the policy's TO or EXCEPT lists so that querying users are not subject to the policy through this view or function. Once adjusted, set use_session_identity = true on this policy.

Scenario B: YES, the policy applies to the owner

Then, after the switch, users not in the policy’s TO list may see more data than before, because the policy will no longer apply to them through the owner. This is a potential data exposure risk. Review this setup to ensure it reflects your intent.

• Before: Filtering or masking applies to all users querying this view or function, because the policy evaluates against the owner, and the owner is subject to it. 
• After: Only users individually in the TO list (and not in EXCEPT) will see filtered or masked data. Other users will see unfiltered or unmasked data.
  • If you intend for all users querying this view or function to see filtered or masked data, run SHOW GRANTS/get effective permissions on the view or function to see who has access, verify all those principals are covered by the TO list, and check that the EXCEPT list does not exclude users who should still be filtered. If TO is account users with no EXCEPT, all users are already covered. Once TO and EXCEPT are correct, set use_session_identity = true.
  • If only specific users should see filtered or masked data, verify the TO and EXCEPT lists target exactly those users. Users not in TO (or in EXCEPT) will see unfiltered or unmasked data after migration. Confirm this is intended, then set use_session_identity = true.

Step 3: Simplify your policies further (optional)

You may also want to use this opportunity to simplify your policies.

For example, if you included view owners in the TO clauses of your ABAC policies as a prerequisite to ensure the policies applied at all, this will no longer be required under the new behavior.

If you added identity functions such as current_user() or is_account_group_member()  only to ensure policy logic evaluated using the session user, that logic may no longer be necessary under the new behavior.

FAQ

1. Does this change whether users need direct access to base tables behind views?

No. Base table access checks for views still use the owner’s identity.

2. Does this change dependency access checks for views and functions?

No. Dependency access checks still use the owner’s identity.

3. Are direct table queries affected?

No. This change applies to cases where ABAC-protected tables are accessed through views or functions.

4. Does this affect both row filters and column masks?

Yes. This applies to both ABAC row filters and ABAC column masking policies on base tables referenced by views or functions.

5. Does this affect functions in the same way as views?

Yes. When a function accesses a base table protected by ABAC row filters or column masks, those policies will be evaluated using the session user’s identity.

6. Do I need to rewrite all my policies?

Not necessarily. Some policies may continue to work as intended without any change. Others may need review, especially if access outcomes for querying users previously depended on the view or function owner’s identity.

7. Do I need to update UDFs that use identity functions?

Not necessarily. Your UDFs will likely continue to produce the same outcome, because session identity functions already evaluate for the session user. However, if you added identity-based logic only to ensure evaluation followed the querying user, that logic may no longer be necessary under the new behavior.

8. Who can I contact if I have questions?

Please reach out to Databricks support or your account team.

Appendix

Example: Access control BEFORE and AFTER the switch to the session identity model

The example below illustrates how access outcomes change when policy evaluation moves from the view owner to the session user, and how policy definitions can often be simplified after the switch.

Before

1. Alice has full access to table categories (11 records; column catgroup has 3 distinct categories: Sports, Concerts, Shows) and can manage objects in this scope.
2. Two groups have SELECT on the table, but are restricted by a row filter policy:
   • Group sees_only_concerts is restricted to catgroup = `Concerts`
   • Group sees_only_sports is restricted to catgroup = `Sports`  

Access for sees_only_concerts	Access for sees_only_sports

3. Alice creates a view that exposes fewer columns, revokes the groups’ direct access to the base table, and grants them SELECT on the view.
4. Because the view uses the DEFINER model, the row filter policy evaluates using Alice’s identity as the view owner rather than the identity of the querying user. As a result, both groups can see all rows Alice can see.

Access for sees_only_concerts	Access for sees_only_sports

5. To enforce access controls when access happens through views, the governance admin must add additional logic:
   1. Ensure policies also apply to view owners, even if those owners do not themselves require filtered or masked access.
   2. Use a broad TO clause (for example, account users) so the policy applies to current and future view users.
   3. Implement the actual access logic inside the policy UDF using group membership checks.

CREATE OR REPLACE POLICY `filter_categories` 
ON SCHEMA catalog.silver_schema 
ROW FILTER filter_category 
TO `account users` -- include all users to make sure policy applies to all future cases
-- EXCEPT `view owner` // must not DO this; excluding the view owner means policy will not apply  
FOR TABLES
MATCH COLUMNS hasTag('category') AS m
ON COLUMN m 

-- We must handle in the UDF who the policy must apply to
-- Since the view owner doesn't require filtered access, we return "true" in their case
CREATE OR REPLACE FUNCTION filter_category (catgroup STRING) 
RETURN
  CASE 
      WHEN is_account_group_member('sees_only_concerts') THEN 
          CASE WHEN catgroup = 'Concerts' THEN true ELSE false END
      WHEN is_account_group_member('sees_only_sports') THEN
          CASE WHEN catgroup = 'Sports' THEN true ELSE false END
      WHEN session_user() = 'view.owner@email.com' THEN true END
      ELSE false
  END

After

The policy described at step 5 still produces the same outcome because Alice had full access to the base table, but it can be simplified as follows:

1. Change the TO clause to be more specific: only reference users who need filtered access.
2. Remove the checks related to the view owner, since they do not require filtered access.

  -- One shared UDF                                                                
  CREATE OR REPLACE FUNCTION filter_by_category (catgroup STRING, allowed STRING)                                                   
  RETURN                                                            
    catgroup = allowed                                              
                  
-- Policy 1: Concerts  
 CREATE OR REPLACE POLICY `filter_concerts`
    ON SCHEMA catalog.silver_schema
    ROW FILTER filter_by_category                       
    TO `sees_only_concerts`                    -- include only users who need filtered access      
    FOR TABLES                                                       
    MATCH COLUMNS hasTag('category') AS m
    USING COLUMNS (m, 'Concerts');  

  -- Policy 2: Sports                                                                    
  CREATE OR REPLACE POLICY `filter_sports`                          
    ON SCHEMA catalog.silver_schema
    ROW FILTER filter_by_category
    TO `sees_only_sports`                      -- include only users who need filtered access   
    FOR TABLES
    MATCH COLUMNS hasTag('category') AS m
    USING COLUMNS (m, 'Sports')