Politiques GRANT ABAC (bêta)

info

Bêta

Les politiques ABAC GRANT sont en bêta. Les politiques GRANT sont attachées au niveau du catalogue ou du schéma et accordent des privilèges sur les types sécurisables pris en charge. Les privilèges que vous pouvez accorder dépendent du type sécurisable. Voir Types sécurisables et privilèges pris en charge.

Les politiques ABAC GRANT accordent dynamiquement des privilèges Unity Catalog aux objets sécurisables dont les tags gouvernés correspondent à une condition. Cette page explique comment créer, modifier, lister et supprimer des politiques ABAC GRANT, comment les politiques GRANT interagissent avec les octrois directs, ainsi que la portée et les limitations actuelles de la version bêta.

Vous pouvez créer et gérer des politiques ABAC GRANT à l’aide de l’explorateur de catalogues ou du Databricks SDK pour tout type sécurisable pris en charge. SQL est uniquement pris en charge pour les modèles.

Pour un aperçu de l'ABAC et des concepts clés, y compris les tags régis et les fonctions intégrées telles que has_tag et has_tag_value, consultez Concepts clés du contrôle d'accès basé sur les attributs (ABAC).

Exigences en matière de compute

L'utilisation de SQL pour créer, modifier ou supprimer des politiques GRANT nécessite une ressource de compute classique exécutant Databricks Runtime 18 LTS ou une version ultérieure.

remarque

Databricks Runtime 18 est plus récent que Databricks Runtime 18,0, 18,1 et 18,2. Les fonctionnalités qui auraient auparavant été livrées sous forme de version numérotée ultérieure sont désormais livrées sous forme de mises à jour datées pour Databricks Runtime 18 à la place. Pour plus de détails, consultez À propos des notes de version unifiées.

Qu’est-ce qu’une politique GRANT ?

Une politique GRANT est une politique de contrôle d'accès basée sur les attributs qui accorde dynamiquement des privilèges Unity Catalog aux objets sécurisables dont les tags régis correspondent à la condition de la politique. Unity Catalog évalue la condition WHEN de la stratégie par rapport aux tags régis sur chaque objet sécurisable dans le champ d’application de la stratégie chaque fois que l’accès est vérifié, et accorde le privilège sur chaque objet sécurisable qui correspond.

En comparaison, les instructions GRANT directes attribuent des privilèges sur des objets sécurisables identifiés par leur espace de noms à trois niveaux (catalog.schema.object).

Les politiques GRANT peuvent faire référence soit à des tags gouvernés que vous créez vous-même, soit à des tags système prédéfinis par Databricks dans leurs conditions.

Exemples de politiques GRANT

Ces exemples s’appliquent à la fois aux modèles MLflow enregistrés par les clients et aux modèles de fondation hébergés par Databricks dans system.ai. Pour plus d’informations sur la façon dont les modèles MLflow sont enregistrés dans Unity Catalog, consultez Gérer le cycle de vie des modèles dans Unity Catalog. Pour les modèles de fondation hébergés par Databricks, consultez Accéder aux modèles d’IA et de LLM depuis Unity Catalog.

La politique suivante utilise le tag gouverné lifecycle appliqué aux modèles MLflow enregistrés par les clients dans production.ml_models. La politique accorde EXECUTE uniquement sur les modèles tagués 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');

La politique suivante utilise la balise système ai.model_creator préappliquée pour accorder EXECUTE sur chaque modèle de fondation hébergé par Anthropic dans system.ai à data_scientists, à l'exception de contractors. La politique couvre automatiquement tout modèle Anthropic que Databricks ajoutera ultérieurement :

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');

L'accès équivalent utilisant des octrois directs nécessite une instruction par modèle dans system.ai, rééditée à mesure que Databricks ajoute de nouveaux modèles Anthropic :

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`;

Les politiques GRANT diffèrent des politiques de filtres de lignes et de masques de colonne de deux manières :

• Les politiques de filtre de lignes et de masque de colonne restreignent le contenu des données auxquelles un utilisateur peut déjà accéder. Les politiques GRANT déterminent si l'utilisateur peut accéder à l'objet.
• Les politiques de filtre de ligne et de masque de colonne nécessitent une fonction définie par l’utilisateur (UDF) pour implémenter le filtre ou le masque. Les politiques GRANT n’utilisent pas les UDF. La condition est exprimée en ligne dans la définition de la politique.

Les privilèges que vous pouvez accorder dépendent du type sécurisable. Pour obtenir la liste complète des types pris en charge et leurs privilèges pouvant être accordés par politique, consultez Types sécurisables et privilèges pris en charge.

Types sécurisables et privilèges pris en charge

Le tableau suivant présente les types pris en charge et leurs privilèges pouvant être accordés par politique. Unity Catalog valide les privilèges que vous nommez par rapport au type sécurisable lors de la création de la politique, et rejette tout privilège non pris en charge par ce type.

Type sécurisable	APPLY_TAG	EXECUTE	READ_METADATA	READ_SKILL	WRITE_SKILL
MODEL	✓	✓	✓	—	—
MODEL_SERVICE	✓	✓	✓	—	—
MODEL_PROVIDER_SERVICE	✓	✓	✓	—	—
MCP_SERVICE	✓	✓	✓	—	—
AGENT_SERVICE	✓	✓	✓	—	—
SKILL	✓	—	✓	✓	✓

Type sécurisable	APPLY_TAG	EXECUTE	READ_METADATA	READ_SKILL	WRITE_SKILL
MODEL	✓	✓	✓	—	—
MODEL_SERVICE	✓	✓	✓	—	—
MODEL_PROVIDER_SERVICE	✓	✓	✓	—	—
MCP_SERVICE	✓	✓	✓	—	—
AGENT_SERVICE	✓	✓	✓	—	—
SKILL	✓	—	✓	✓	✓

Un tiret (—) signifie que vous ne pouvez pas accorder ce privilège via une politique GRANT pour ce type sécurisable, bien que vous puissiez toujours être en mesure de l'accorder avec une instruction GRANT directe. Pour tout ce que vous pouvez accorder directement sur chaque type d'objet, voir référence des privilèges Unity Catalog.

SKILL ne prend pas en charge EXECUTE. Utilisez plutôt READ_SKILL et WRITE_SKILL pour régir l’accès aux compétences.

Comment les politiques de GRANT interagent avec les autorisations directes

Les privilèges effectifs sur un objet sont l’union des octrois directs et de toute politique GRANT applicable. Cette logique d’union s’applique à chaque type et privilège pris en charge dans types et privilèges pris en charge. L'exemple suivant utilise EXECUTE sur un modèle. Un principal détient EXECUTE sur un modèle lorsque l'une des conditions suivantes est vraie :

• Une politique GRANT attachée au catalogue ou au schéma du modèle répertorie le principal dans TO (et non dans EXCEPT), et la condition WHEN de la politique correspond aux tags du modèle.
• Une GRANT EXECUTE directe sur le modèle, son schéma ou son catalogue est en vigueur pour ce principal, qu'elle soit accordée directement, par l'intermédiaire de l'appartenance à un groupe, ou par d'autres privilèges administratifs.

Parce que l'accès est l'union de ces sources, une politique GRANT plus sélective ne signifie pas qu'un principal exclu manque de EXECUTE. Le principal peut toujours détenir le privilège par le biais d'une attribution directe sur le modèle, ou son schéma ou catalogue parent. Si vous avez l'intention d'utiliser des politiques GRANT comme moyen principal de contrôler EXECUTE sur les modèles, déterminez d'abord si des grants directs déjà en place pourraient outrepasser la politique :

• Utilisez SHOW EFFECTIVE POLICIES ON SCHEMA <parent_schema> (ou ON CATALOG <parent_catalog>) pour lister chaque politique GRANT dont la portée couvre les modèles dans ce schéma ou ce catalogue. SHOW EFFECTIVE POLICIES ne prend pas en charge ON MODEL directement. L'API REST équivalente est 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)).
• Utilisez SHOW GRANTS sur le modèle et ses ancêtres pour énumérer les autorisations directes. L'API REST équivalente pour les autorisations directes sur un objet sécurisable est GET /api/2.1/unity-catalog/permissions/{securable_type}/{full_name} (SDK Python : w.grants.get(...)) ; pour l'union des autorisations directes et héritées, utilisez GET /api/2.1/unity-catalog/effective-permissions/{securable_type}/{full_name} (SDK Python : w.grants.get_effective(...)).

Créer une politique GRANT

Vous pouvez créer une stratégie GRANT via l’interface utilisateur de Catalog Explorer, avec l’instruction SQL CREATE POLICY, ou avec le SDK Databricks.

Pour créer une stratégie GRANT, vous devez disposer de MANAGE sur le catalogue ou le schéma où la stratégie est appliquée, ou être propriétaire de cet objet sécurisable.

Catalog Explorer

1. Dans votre workspace Databricks, cliquez sur Catalogue .

2. Sélectionnez le catalogue ou le schéma où vous souhaitez attacher la politique. Les politiques GRANT ne peuvent être attachées qu'au niveau du catalogue ou du schéma.

3. Cliquez sur l'onglet tab .

4. Cliquez sur Nouvelle politique .

5. Sous Identification de la politique , saisissez un Nom de la politique et une Description facultative.

6. Sous Principals et périmètre :

   • Dans Appliqué à , sélectionnez les principaux (utilisateurs, groupes ou Service Principal) auxquels la politique s’applique.
   • Dans À l'exception de , sélectionnez éventuellement les principaux à exclure de la stratégie.
   • Dans Scope , confirmez le catalogue ou le schéma où la politique est attachée.

7. Sous Type de politique, sélectionnez Accorder l'accès.

8. Sous Objets sécurisables , sélectionnez le type sécurisable auquel la politique s’applique. Voir types et privilèges pris en charge.

9. Sous Condition , choisissez comment définir la portée de la politique aux objets sécurisables du type sélectionné dans le catalogue ou le schéma :

   • No condition applique la politique à tous les objets sécurisables de ce type sous le catalogue ou le schéma sélectionné.
   • Les objets sécurisables correspondant à l’un de ces tags appliquent la politique uniquement aux objets sécurisables qui portent au moins l’un des tags régis sélectionnés.
   • Objets sécurisables correspondant à une expression personnalisée vous permet d'écrire une expression basée sur des tags pour déterminer les objets sécurisables auxquels la politique s'applique. Voir Conditions et fonctions intégrées pour les fonctions de condition disponibles.

10. Sous Privilèges , sélectionnez les privilèges à accorder. Les privilèges disponibles dépendent du type sécurisable que vous avez choisi. Voir types et privilèges pris en charge.

11. Cliquez sur Afficher le code pour examiner l'instruction SQL équivalente avant d'enregistrer, puis cliquez sur Créer une politique .

SQL

La syntaxe SQL d'une politique GRANT utilise un corps GRANT ... FOR ... WHEN ... à la place de ROW FILTER ou COLUMN MASK.

SQL

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

Paramètres :

• policy_name: Un nom pour la politique. Doit être unique parmi toutes les politiques définies sur le même objet sécurisable.
• ON { CATALOG | SCHEMA }: le périmètre dans lequel la politique est appliquée. Les politiques GRANT peuvent être attachées au niveau du catalogue ou du schéma, et non à un objet sécurisable individuel.
• TO principal [, ...]: Les utilisateurs, les groupes ou les Service Principal auxquels la politique s'applique.
• EXCEPT principal [, ...]: Principaux exempts de la politique.
• GRANT privilege [, ...] FOR MODELS: les privilèges à accorder et le type sécurisable auquel ils s’appliquent. En SQL, les politiques GRANT ne prennent actuellement en charge que les modèles. Les privilèges valides dépendent du type. Voir types et privilèges pris en charge. Pour créer une politique pour les autres types pris en charge, utilisez l’Explorateur de catalogues ou le Databricks SDK.
• WHEN condition: une expression booléenne basée sur des tags qui détermine les objets sécurisables auxquels la politique s’applique au sein de la portée. Utilise les fonctions intégrées has_tag('tag_name') et has_tag_value('tag_name', 'tag_value'). S’il est omis, default est TRUE (s’applique à tous les objets sécurisables du type dans la portée). Voir Conditions et fonctions intégrées pour les fonctions de condition disponibles.

Pour des exemples de modèles, consultez Qu’est-ce qu’une politique GRANT.

Python SDK

Pour une documentation complète, veuillez consulter la documentation du SDK Databricks pour Python.

Cet exemple crée une politique GRANT qui octroie EXECUTE sur chaque modèle de fondation hébergé par Anthropic dans system.ai à data_scientists, à l'exception des contractants :

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')",
))

Pour les autres types sécurisables, définissez for_securable_type sur la valeur SecurableType correspondante et transmettez les privilèges valides pour ce type. Voir types et privilèges pris en charge.

Modifier une politique GRANT

Catalog Explorer

Gérez les politiques GRANT depuis l’onglet Policies du catalogue ou du schéma parent auquel elles sont rattachées.

1. Dans votre workspace Databricks, cliquez sur Catalogue .
2. Sélectionnez le catalogue ou le schéma auquel la politique est attachée.
3. Cliquez sur l'onglet tab .
4. Sélectionnez la politique que vous souhaitez modifier.
5. Mettez à jour les champs que vous souhaitez modifier.
6. Cliquez sur **Mettre à jour la politique**.

SQL

Pour modifier une politique GRANT avec SQL, exécutez CREATE OR REPLACE POLICY avec le même nom et la même cible. Consultez Créer une politique GRANT.

Python SDK

Contrairement à CREATE OR REPLACE POLICY dans SQL, update_policy prend en charge les mises à jour partielles. Utilisez le paramètre update_mask pour spécifier les champs à modifier. Seuls ces champs sont mis à jour. Si update_mask est "*" ou vide, tous les champs de policy_info sont appliqués.

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",
)

Supprimer une politique GRANT

Catalog Explorer

Gérez les politiques GRANT depuis l’onglet Policies du catalogue ou du schéma parent auquel elles sont rattachées.

1. Dans votre workspace Databricks, cliquez sur Catalogue .
2. Sélectionnez le catalogue ou le schéma auquel la politique est attachée.
3. Cliquez sur l'onglet tab .
4. Sélectionnez la politique.
5. Cliquez sur Supprimer la politique .

SQL

Pour supprimer une politique GRANT avec SQL, exécutez 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",
)

Afficher les politiques

Utilisez SHOW POLICIES pour lister les politiques définies sur un objet sécurisable. Utilisez SHOW EFFECTIVE POLICIES pour inclure également les politiques héritées des étendues parentes, telles que les politiques de niveau catalogue qui affectent un schéma.

SQL

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

Le résultat inclut le nom de la stratégie, le type de stratégie et le catalogue ou le schéma où chaque stratégie est définie. Les stratégies GRANT sont renvoyées avec le type de stratégie GRANT ainsi que toutes les stratégies de filtre de lignes et de masque de colonnes attachées au même périmètre. La colonne table est renseignée uniquement pour les stratégies à l'échelle de la table (filtre de lignes et masque de colonnes) ; pour les stratégies GRANT attachées à un catalogue ou un schéma, elle est NULL.

Exemple :

SQL

SHOW EFFECTIVE POLICIES ON SCHEMA system.ai;

policy_name	policy_type	catalogue	Schéma	Table	Commentaire
grant_anthropic_foundation_models	Accorder	système	AI	NULL	Octroyer EXECUTE sur les modèles de fondation Anthropic.

policy_name	policy_type	catalogue	Schéma	Table	Commentaire
grant_anthropic_foundation_models	Accorder	système	AI	NULL	Octroyer EXECUTE sur les modèles de fondation Anthropic.

SHOW GRANTS n'inclut pas les privilèges accordés via une politique GRANT. Pour voir tous les accès sur un objet sécurisable, combinez la sortie SHOW GRANTS pour l'objet sécurisable avec les politiques GRANT renvoyées par SHOW EFFECTIVE POLICIES sur son schéma ou catalogue parent.

Décrire une politique

Utilisez DESCRIBE POLICY pour afficher les détails d’une politique GRANT spécifique. Nécessite READ METADATA ou MANAGE sur l’objet sécurisable cible, ou la propriété de l’objet.

SQL

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

Le résultat affiche les propriétés de la politique sous forme de paires clé-valeur, y compris le nom, le type d'objet sécurisable, le nom d'objet sécurisable, les principaux, les privilèges et la condition WHEN.

Exemple :

SQL

DESCRIBE POLICY grant_anthropic_foundation_models ON SCHEMA system.ai;

info_name	info_value
Nom	grant_anthropic_foundation_models
Sur le type sécurisable	Schéma
Sur Sécurisable	system.ai
À Principals	data scientists
Sauf Principals	prestataires
Pour le type sécurisable	Modèle
Type de politique	Accorder
Privilèges octroyés	EXÉCUTER
Condition	has_tag_value('ai.model_creator', 'anthropic')

info_name	info_value
Nom	grant_anthropic_foundation_models
Sur le type sécurisable	Schéma
Sur Sécurisable	system.ai
À Principals	data scientists
Sauf Principals	prestataires
Pour le type sécurisable	Modèle
Type de politique	Accorder
Privilèges octroyés	EXÉCUTER
Condition	has_tag_value('ai.model_creator', 'anthropic')

Balises système sur les modèles de fondation dans system.ai

Les modèles de fondation que Databricks héberge dans system.ai sont pré-balisés avec des tags système que les politiques GRANT peuvent référencer directement. Vous n'avez pas besoin de taguer vous-même ces modèles pour les utiliser dans une politique.

Tag	Exemples de valeurs
ai.model_creator	anthropic, openai, google, meta
ai.model_family	claude-opus, gpt, gemini, qwen

Tag	Exemples de valeurs
ai.model_creator	anthropic, openai, google, meta
ai.model_family	claude-opus, gpt, gemini, qwen

Pour les modèles que vous enregistrez dans vos propres catalogues et schémas, appliquez des tags gouvernés par le biais du workflow de tags standard de Unity Catalog. Voir Governed tags.

Quotas de politique

Ressource	Limite
Stratégies par métastore.	10 000
Stratégies par catalogue ou schéma	100

Ressource	Limite
Stratégies par métastore.	10 000
Stratégies par catalogue ou schéma	100

Ces quotas sont distincts des quotas pour les stratégies de filtre de ligne et de masque de colonne.

Journalisation d'audit

Les opérations de création, de modification et de suppression des politiques GRANT sont enregistrées sous les mêmes actions createPolicy, deletePolicy, getPolicy et listPolicies que les politiques de filtrage des lignes et de masquage des colonnes. Voir Journalisation d'audit pour des exemples de requêtes de log d'audit.

Bonnes pratiques

• Utilisez des groupes dans TO et EXCEPT, et non des utilisateurs individuels. L'ajout ou la suppression d'utilisateurs d'un groupe nommé dans une politique modifie les personnes auxquelles la politique s'applique, sans modifier la politique.
• Joignez les politiques à la portée la plus restreinte qui couvre les cibles. Utilisez la portée la plus étroite qui contient les objets sécurisables auxquels la politique doit s’appliquer. Une portée plus large inclut des éléments sécurisables non pertinents dans la correspondance des tags de la politique, et peut accorder un accès non intentionnel.
• Utilisez l'héritage des tags pour des default sûres. Appliquez les valeurs de tag par default au catalogue ou au schéma parent afin que les descendants les héritent. Outrepassez le tag hérité uniquement sur les objets spécifiques qui nécessitent une valeur différente. Combinez cela avec EXCEPT pour gérer les exceptions contrôlées à une politique.
• Ne mélangez pas les stratégies GRANT et les octrois directs pour le même privilège. Pour un privilège donné sur une ressource sécurisable, choisissez soit les stratégies GRANT, soit les octrois directs, pas les deux. Les politiques GRANT s'unissent aux octrois directs, de sorte que les mélanger sur le même élément sécurisable rend plus difficile de comprendre qui a accès et d'auditer les modifications.
• Utilisez des octrois directs pour les prérequis USE CATALOG et USE SCHEMA, et des politiques GRANT pour les privilèges pris en charge par le type. Les politiques GRANT n’accordent pas les prérequis USE CATALOG et USE SCHEMA nécessaires pour accéder à un élément sécurisable. Accordez-les directement et utilisez une politique GRANT pour définir la portée des privilèges pris en charge par le type par tag, tel que EXECUTE là où c'est pris en charge ou READ_SKILL et WRITE_SKILL pour les compétences.

Limitations

• Les privilèges CREATE MODEL et CREATE MODEL VERSION ne sont pas pris en charge par les politiques GRANT et doivent être accordés directement. Pour les privilèges pris en charge pour MODEL, voir types et privilèges pris en charge.
• ALL_PRIVILEGES, MANAGE et MODIFY ne sont pas pris en charge par les politiques GRANT.
• Les autorisations préalables USE SCHEMA et USE CATALOG, dont un utilisateur a besoin pour accéder à un élément sécurisable, ne sont pas prises en charge par les politiques GRANT et doivent être accordées directement.
• Une politique peut être attachée au catalogue ou au schéma, mais pas à un objet sécurisable individuel.
• SHOW GRANTS ne retourne pas les privilèges accordés par une politique GRANT.
• INFORMATION_SCHEMA n'inclut pas les politiques GRANT.
• La création d'une politique GRANT en SQL n'est actuellement disponible que pour les modèles. Pour créer une politique sur les services de modèle, les services de fournisseur de modèle, les services Model Context Protocol (MCP), les services d'agent ou les compétences, utilisez Catalog Explorer ou le SDK Databricks. Une fois la politique créée, vous pouvez toujours la gérer en SQL pour n'importe quel type : SHOW POLICIES, SHOW EFFECTIVE POLICIES, DESCRIBE POLICY et DROP POLICY prennent une portée de catalogue ou de schéma et ne sont pas limités par le type sécurisable.
• Les tags système sont disponibles sur les modèles, mais pas encore sur les services de modèle. Pour limiter une politique aux services de modèle, effectuez une correspondance sur les tags gouvernés appliqués par le client.
• La suppression d'un modèle ou d'une version de modèle n'est pas couverte par les politiques GRANT. Consultez Gérer le cycle de vie des modèles dans Unity Catalog pour savoir comment supprimer les versions de modèle et les modèles.
• Vous ne pouvez pas utiliser Delta Sharing pour partager des modèles sur lesquels des politiques GRANT sont définies. Delta Sharing ne prend pas en charge le partage de services de modèle, de services de fournisseur de modèle, de services MCP, de services d’agent ou de compétences, indépendamment de l’application d’une politique GRANT.

Plus d'informations

Voir aussi Gérer les privilèges dans Unity Catalog.