ABAC GRANT policies for models (Beta)

Beta

ABAC GRANT policies are in Beta. In Beta, GRANT policies can grant the EXECUTE privilege on models, attached at the catalog or schema level. Additional privileges and securable types will be supported in future releases.

This page describes ABAC GRANT policies, which dynamically grant Unity Catalog privileges to securable objects whose governed tags match a condition. It covers how to create, edit, list, and delete them in Catalog Explorer, SQL, and the Databricks SDK, how GRANT policies interact with direct grants, and the current Beta scope and limitations.

For an overview of ABAC and core concepts, including governed tags and built-in functions such as has_tag and has_tag_value, see Core concepts for attribute-based access control (ABAC).

Compute requirements

Creating, modifying, or dropping GRANT policies with SQL requires a classic compute cluster running Databricks Runtime 18.3 or above.

What is a GRANT policy

A GRANT policy is an attribute-based access control policy that dynamically grants Unity Catalog privileges to securable objects whose governed tags match the policy's condition. Unity Catalog evaluates the policy's WHEN condition against the governed tags on each securable object in the policy's scope every time access is checked, and grants the privilege on every securable object that matches.

In comparison, direct GRANT statements assign privileges on securable objects identified by their three-level namespace (catalog.schema.object).

In Beta, GRANT policies support one privilege on one securable type: EXECUTE on models. Both customer-registered MLflow models and Databricks-hosted foundation models in system.ai are covered. See Manage model lifecycle in Unity Catalog for how MLflow models are registered in Unity Catalog, and Access generative AI and LLM models from Unity Catalog for Databricks-hosted foundation models.

GRANT policies can reference either governed tags you create yourself or system tags predefined by Databricks in their conditions.

For example, the following policy uses the lifecycle governed tag applied to customer-registered MLflow models in production.ml_models. The policy grants EXECUTE only on models tagged lifecycle = 'production':

SQL

CREATE POLICY grant_production_model_access
ON SCHEMA production.ml_models
COMMENT 'Grant EXECUTE on production MLflow models'
TO `analysts`
GRANT EXECUTE FOR MODELS
WHEN has_tag_value('lifecycle', 'production');

The following policy grants EXECUTE on Anthropic-hosted foundation models in system.ai to data_scientists, except contractors, by matching the ai.model_creator system tag. Every model that carries ai.model_creator = 'anthropic' is covered, without a separate grant per model:

SQL

CREATE POLICY grant_anthropic_foundation_models
ON SCHEMA system.ai
COMMENT 'Grant EXECUTE on Anthropic foundation models'
TO `data_scientists`
EXCEPT `contractors`
GRANT EXECUTE FOR MODELS
WHEN has_tag_value('ai.model_creator', 'anthropic');

The equivalent access using direct grants requires one statement per model in system.ai, reissued as Databricks adds new Anthropic models:

SQL

GRANT EXECUTE ON MODEL `system`.`ai`.`databricks-claude-sonnet-4-6` TO `data_scientists`;
GRANT EXECUTE ON MODEL `system`.`ai`.`databricks-claude-opus-4-7` TO `data_scientists`;
GRANT EXECUTE ON MODEL `system`.`ai`.`databricks-claude-haiku-4-5` TO `data_scientists`;

GRANT policies differ from row filter and column mask policies in two ways:

• Row filter and column mask policies restrict the content of data a user can already access. GRANT policies determine whether the user can access the object at all.
• Row filter and column mask policies require a user-defined function (UDF) to implement the filter or mask. GRANT policies do not use UDFs. The condition is expressed inline in the policy definition.

How GRANT policies interact with direct grants

The effective privileges on an object are the union of direct grants and any applicable GRANT policies. A principal holds EXECUTE on a model when any of the following is true:

• A GRANT policy attached to the model's catalog or schema lists the principal in TO (and not in EXCEPT), and the policy's WHEN condition matches the tags on the model.
• A direct GRANT EXECUTE on the model, its schema, or its catalog is in effect for that principal, whether granted directly, through group membership, or through other administrative privileges.

Because access is the union of these sources, a more selective GRANT policy does not mean that an excluded principal lacks EXECUTE. The principal can still hold the privilege through a direct grant on the model, or its parent schema or catalog. If you intend to use GRANT policies as the primary way to control EXECUTE on models, first determine whether any direct grants already in place might override the policy:

• Use SHOW EFFECTIVE POLICIES ON SCHEMA <parent_schema> (or ON CATALOG <parent_catalog>) to list every GRANT policy whose scope covers the models in that schema or catalog. SHOW EFFECTIVE POLICIES does not support ON MODEL directly. The equivalent REST API is GET /api/2.1/unity-catalog/policies/{on_securable_type}/{on_securable_fullname}?include_inherited=true (Python SDK: w.policies.list_policies(..., include_inherited=True)).
• Use SHOW GRANTS on the model and its ancestors to enumerate direct grants. The equivalent REST API for direct grants on a securable object is GET /api/2.1/unity-catalog/permissions/{securable_type}/{full_name} (Python SDK: w.grants.get(...)); for the union of direct and inherited grants, use GET /api/2.1/unity-catalog/effective-permissions/{securable_type}/{full_name} (Python SDK: w.grants.get_effective(...)).

Create a GRANT policy

You can create a GRANT policy through the Catalog Explorer UI, with the CREATE POLICY SQL statement, or with the Databricks SDK.

To create a GRANT policy, you must have MANAGE on the catalog or schema where the policy is attached, or own that securable object.

Catalog Explorer

1. In your Databricks workspace, click Catalog.
2. Select the catalog or schema where you want to attach the policy. GRANT policies in Beta can only be attached at the catalog or schema level.
3. Click the Policies tab.
4. Click New policy.
5. Under Policy identification, enter a Policy name and an optional Description.
6. Under Principals and scope:
   • In Applied to, select the principals (users, groups, or service principals) that the policy applies to.
   • In Except for, optionally select principals to exclude from the policy.
   • In Scope, confirm the catalog or schema where the policy is attached.
7. Under Policy type, select Grant access.
8. Under Securable objects, select Model. Model is the only securable type supported for GRANT policies in Beta. The other types in the list (Table, Volume, Schema, Catalog) cannot be combined with Grant access.
9. Under Condition, choose how to scope the policy to models in the selected catalog or schema:
   • No condition applies the policy to all models under the selected catalog or schema.
   • Securables matching any of these tags applies the policy only to models that carry at least one of the selected governed tags.
   • Securables matching a custom expression lets you write a tag-based expression to determine which models the policy applies to. See Conditions and built-in functions for the available condition functions.
10. Under Privileges, select EXECUTE. EXECUTE is the only privilege supported for models in Beta.
11. Click Show code to review the equivalent SQL statement before saving, then click Create policy.

SQL

The SQL syntax for a GRANT policy uses a GRANT ... FOR ... WHEN ... body in place of ROW FILTER or COLUMN MASK.

SQL

CREATE [OR REPLACE] POLICY policy_name
ON { CATALOG catalog_name | SCHEMA schema_name }
[COMMENT description]
TO principal [, ...]
[EXCEPT principal [, ...]]
GRANT EXECUTE FOR MODELS
[WHEN condition]

Parameters:

• policy_name: A name for the policy. Must be unique among all policies defined on the same securable object.
• ON { CATALOG | SCHEMA }: The scope where the policy is attached. In Beta, GRANT policies can be attached at the catalog or schema level, not at an individual model.
• TO principal [, ...]: The users, groups, or service principals the policy applies to.
• EXCEPT principal [, ...]: Principals exempt from the policy.
• GRANT EXECUTE FOR MODELS: Specifies the privilege and securable type. In Beta, EXECUTE on MODELS is the only supported combination.
• WHEN condition: A tag-based boolean expression that determines which models the policy applies to within scope. Uses built-in functions has_tag('tag_name') and has_tag_value('tag_name', 'tag_value'). If omitted, defaults to TRUE (applies to all models in scope). See Conditions and built-in functions for the available condition functions.

Python SDK

For complete documentation, see the Databricks SDK for Python documentation.

This example creates a GRANT policy that grants EXECUTE on Anthropic-hosted foundation models in system.ai tagged ai.model_creator = 'anthropic', to data_scientists, except contractors:

Python

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.catalog import (
    GrantOptions,
    PolicyInfo,
    PolicyType,
    SecurableType,
)

w = WorkspaceClient()

w.policies.create_policy(PolicyInfo(
    name="grant_anthropic_foundation_models",
    comment="Grant EXECUTE on Anthropic foundation models",
    on_securable_type=SecurableType.SCHEMA,
    on_securable_fullname="system.ai",
    for_securable_type=SecurableType.MODEL,
    policy_type=PolicyType.POLICY_TYPE_GRANT,
    to_principals=["data_scientists"],
    except_principals=["contractors"],
    grant=GrantOptions(privileges=["EXECUTE"]),
    when_condition="has_tag_value('ai.model_creator', 'anthropic')",
))

Edit a GRANT policy

Catalog Explorer

1. In your Databricks workspace, click Catalog.
2. Select the catalog or schema the policy is attached to.
3. Click the Policies tab.
4. Select the policy you want to edit.
5. Update any fields you want to change.
6. Click Update policy.

SQL

To edit a GRANT policy with SQL, run CREATE OR REPLACE POLICY with the same name and target. See Create a GRANT policy.

Python SDK

Unlike CREATE OR REPLACE POLICY in SQL, update_policy supports partial updates. Use the update_mask parameter to specify which fields to change. Only those fields are updated. If update_mask is "*" or empty, all fields in policy_info are applied.

Python

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.catalog import PolicyInfo

w = WorkspaceClient()

w.policies.update_policy(
    on_securable_type="SCHEMA",
    on_securable_fullname="system.ai",
    name="grant_anthropic_foundation_models",
    policy_info=PolicyInfo(
        except_principals=["contractors", "interns"],
    ),
    update_mask="except_principals",
)

Delete a GRANT policy

Catalog Explorer

1. In your Databricks workspace, click Catalog.
2. Select the catalog or schema the policy is attached to.
3. Click the Policies tab.
4. Select the policy.
5. Click Delete policy.

SQL

To delete a GRANT policy with SQL, run DROP POLICY:

SQL

DROP POLICY IF EXISTS grant_anthropic_foundation_models ON SCHEMA system.ai;

Python SDK

Python

from databricks.sdk import WorkspaceClient

w = WorkspaceClient()

w.policies.delete_policy(
    on_securable_type="SCHEMA",
    on_securable_fullname="system.ai",
    name="grant_anthropic_foundation_models",
)

Show policies

Use SHOW POLICIES to list the policies defined on a securable object. Use SHOW EFFECTIVE POLICIES to also include policies inherited from parent scopes, such as catalog-level policies that affect a schema.

SQL

SHOW [EFFECTIVE] POLICIES ON { CATALOG | SCHEMA } securable_name

The result includes the policy name, policy type, and the catalog or schema where each policy is defined. GRANT policies are returned with policy type GRANT alongside any row filter and column mask policies attached at the same scope. The table column is populated only for table-scoped policies (row filter and column mask); for GRANT policies attached to a catalog or schema, it is NULL.

Example:

SQL

SHOW EFFECTIVE POLICIES ON SCHEMA system.ai;

policy_name	policy_type	catalog	schema	table	comment
grant_anthropic_foundation_models	GRANT	system	ai	NULL	Grant EXECUTE on Anthropic foundation models

SHOW GRANTS does not include privileges granted via a GRANT policy. To see all EXECUTE access on a model, combine SHOW GRANTS output for the model with the GRANT policies returned by SHOW EFFECTIVE POLICIES on its parent schema or catalog.

Describe a policy

Use DESCRIBE POLICY to view the details of a specific GRANT policy. Requires MANAGE on the target securable object or object ownership.

SQL

{ DESC | DESCRIBE } POLICY policy_name ON { CATALOG | SCHEMA } securable_name

The result shows the policy's properties as key-value pairs, including name, securable object type, securable object name, principals, privileges, and the WHEN condition.

Example:

SQL

DESCRIBE POLICY grant_anthropic_foundation_models ON SCHEMA system.ai;

info_name	info_value
Name	grant_anthropic_foundation_models
On Securable Type	SCHEMA
On Securable	system.ai
To Principals	data_scientists
Except Principals	contractors
For Securable Type	MODEL
Policy Type	GRANT
Granted Privileges	EXECUTE
When Condition	has_tag_value('ai.model_creator', 'anthropic')

Policy quotas

Resource	Limit
Policies per metastore	10,000
Policies per catalog or schema	100

These quotas are separate from the quotas for row filter and column mask policies.

Audit logging

GRANT policy create, alter, and drop operations are logged under the same createPolicy, deletePolicy, getPolicy, and listPolicies actions as row filter and column mask policies. See Audit logging for example audit log queries.

Best practices

The following recommendations help you design GRANT policies that are easier to maintain, audit, and reason about.

• Use groups in TO and EXCEPT, not individual users. Adding or removing users from a group named in a policy changes who the policy applies to, without editing the policy.
• Attach policies at the smallest scope that covers the targets. Use the narrowest scope that contains the securables the policy should apply to. A broader scope brings unrelated securables into the policy's tag-matching, and may grant access where you didn't intend.
• Use tag inheritance for safe defaults. Apply default tag values at the parent catalog or schema so descendants inherit them. Override the inherited tag only on the specific objects that need a different value. Combine this with EXCEPT to handle controlled exceptions to a policy.
• Don't mix GRANT policies and direct grants for the same privilege. For a given privilege on a securable, choose either GRANT policies or direct grants, not both. GRANT policies union with direct grants, so mixing them on the same securable makes it harder to reason about who has access and to audit changes.
• Use direct grants for USE CATALOG and USE SCHEMA, GRANT policies for EXECUTE. GRANT policies do not grant the USE CATALOG and USE SCHEMA prerequisites required to access a model. Grant those directly, and use a GRANT policy to scope EXECUTE on individual models by tag.

Limitations

• Only the EXECUTE privilege on models is supported. CREATE MODEL, CREATE MODEL VERSION, and APPLY TAG are not supported by GRANT policies and must be granted directly.
• The prerequisite permissions USE SCHEMA and USE CATALOG, which a user needs to reach a model, are not supported by GRANT policies and must be granted directly.
• A policy can be attached to the catalog or the schema, not to the model.
• SHOW GRANTS does not return privileges granted by a GRANT policy.
• INFORMATION_SCHEMA does not include GRANT policies.
• Deleting a model or a model version is not covered by GRANT policies. See Manage model lifecycle in Unity Catalog for how to delete model versions and models.
• You cannot use Delta Sharing to share models that have GRANT policies defined on them.

More information

See also Manage privileges in Unity Catalog.