Aller au contenu principal
Dernière mise à jour le

Créez et associez une politique de service

info

Bêta

Cette fonctionnalité est en Bêta. Les administrateurs de compte peuvent contrôler l'accès à cette fonctionnalité depuis la page Aperçus de la console de compte. Consultez Gérer les aperçus Databricks.

Pour un aperçu des politiques de service, voir politiques de service pour les éléments sécurisables d'IA.

Pour créer une politique de service, vous écrivez une fonction de politique SQL, puis vous l'attachez à un service MCP, un service de modèle ou un service de fournisseur de modèle via l'interface utilisateur de la Unity AI Gateway . La politique régit chaque interaction à deux points d'évaluation : ON CALL (avant que Databricks n'invoque le service) et ON RESULT (après que le service réponde).

Prérequis​

  • Un administrateur de compte doit activer la version bêta pour votre compte à partir de la page **Previews** dans la console du compte.
  • Pour créer la fonction de politique : CREATE FUNCTION privilège sur le schéma cible.
  • Pour attacher une politique à un service : MANAGE sur l'élément sécurisable du service cible **et** EXECUTE sur la fonction de politique.

Étape 1 : Rédigez la fonction de stratégie​

Une fonction de politique de service est une UDF SQL enregistrée dans Unity Catalog. Il prend un unique paramètre VARIANT, event (les données d'interaction et le contexte), et renvoie un résultat VARIANT :

SQL
CREATE OR REPLACE FUNCTION <catalog>.<schema>.<function_name>(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN <expression>;

La fonction s'exécute aux deux points d'évaluation ; Branch sur event:type::string ('request' pour ON CALL, 'response' pour ON RESULT) pour agir sur une seule phase. Pour connaître tous les event champs, la valeur de retour et le sous-ensemble SQL pris en charge, consultez la référence des fonctions de politique de service.

Écrire une politique de décision​

Une politique de décision renvoie un VARIANT avec un champ result de ALLOW, DENY ou ASK et un reason facultatif. Construisez le résultat avec named_struct et enveloppez-le dans to_variant_object afin que la fonction renvoie un VARIANT, en gardant result et reason comme champs de premier niveau.

La valeur result détermine ce qui se passe (elle est insensible à la casse) :

  • ALLOW: l’interaction se déroule.
  • DENY: Databricks bloque l’interaction. L'appelant reçoit une erreur structurée avec le reason.
  • ASK: l'interaction est interrompue pour une approbation humaine avant de continuer.

Pour le sous-ensemble SQL pris en charge et les règles de renvoi d'un VARIANT, consultez la référence de la fonction de politique de service.

Exemple : refuser un push GitHub depuis un service MCP

Cette politique bloque tout appel à l'outil push_files et autorise toutes les autres interactions. Étant donné que la politique est attachée à un service MCP spécifique, la fonction n'a qu'à vérifier le nom de l'outil :

SQL
CREATE OR REPLACE FUNCTION main.governance.block_github_push(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:type::string = 'request'
      AND event:context.tool.name::string = 'push_files'
    THEN to_variant_object(named_struct('result', 'DENY', 'reason', 'GitHub push operations are not permitted by policy.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

Exemple : exiger une approbation humaine avant l'exécution d'un outil destructeur.

Cette politique met en pause tout appel à l'outil delete_repository pour approbation humaine et autorise toutes les autres interactions.

SQL
CREATE OR REPLACE FUNCTION main.governance.ask_before_repo_delete(
  event VARIANT
)
RETURNS VARIANT
LANGUAGE SQL
RETURN
  CASE
    WHEN event:context.tool.name::string = 'delete_repository'
    THEN to_variant_object(named_struct('result', 'ASK', 'reason', 'Deleting a repository requires human approval.'))
    ELSE to_variant_object(named_struct('result', 'ALLOW', 'reason', ''))
  END;

Lorsque cette politique renvoie DEMANDER, Databricks met en pause l'appel pour approbation humaine avant son exécution.

Pour les agents externes qui appellent les services MCP, Databricks délivre la décision d'approbation en utilisant l'élicitation en mode URL MCP: l'utilisateur ouvre l'URL fournie pour approuver ou refuser l'appel. L'agent externe doit relancer l'appel après approbation. Pour utiliser ASK avec un agent externe, le client MCP de l’agent doit prendre en charge la version 2025-11-25 du protocole MCP ou une version ultérieure.

Pour les services MCP, l'approbation d'un appel d'outil met en cache l'approbation pendant une heure, afin qu'un appel identique ne soit pas de nouveau sollicité dans ce délai.

Étape 2 : Associez la politique à un service​

Pendant la Beta, vous associez une politique de service via l'interface utilisateur de la Unity AI Gateway , sur un service MCP, un service de modèle ou un service de fournisseur de modèle individuel. Vous pouvez associer plusieurs politiques à un service : chaque association a une priorité (rang), et la chaîne s'arrête à la première DENY. Pour ON CALL, les politiques sont évaluées par ordre de classement croissant (le plus bas en premier) ; pour ON RESULT, dans l'ordre inverse.

Pour associer une politique :

  1. Dans la barre latérale du workspace, cliquez sur AI Gateway .

  2. Sélectionnez le service à gouverner : un service de modèle sur la tab Models , un service de fournisseur de modèles sur la tab Providers , ou un service MCP sur la tab MCPs .

  3. Ouvrez l'onglet Politiques , puis cliquez sur Nouvelle politique .

  4. Saisissez un **Nom** pour la politique.

  5. Sous **Appliqué à**, sélectionnez les principaux auxquels la politique s'applique. Le default, **Tous les utilisateurs du compte**, l'applique à tout le monde.

  6. Dans Type de garde-fou , sélectionnez ce que la politique exécute :

    • Un garde-fou intégré, tel que le blocage des PII ou le contenu dangereux . « Le **service de modèle d'évaluation** qui exécute la vérification (le juge LLM) est présélectionné ; pour en utiliser un autre, développez **Options avancées** et sélectionnez-le (vous avez besoin CAN_QUERY de sur le modèle que vous choisissez). »
    • Personnalisé : cliquez sur **Fonction personnalisée**, puis sur **Sélectionner la fonction**, et sélectionnez la fonction SQL que vous avez écrite à l'étape 1.

  7. Sous Phase , sélectionnez l'endroit où la politique s'exécute : garde-fous d'entrée (LORS DE L'APPEL, avant l'invocation du service), garde-fous de sortie (LORS DU RÉSULTAT, après la réponse), ou les deux. Une fonction personnalisée peut s'exécuter dans les deux phases et Branch sur event:type pour se limiter à l'une d'entre elles. Certains garde-fous intégrés ne s'exécutent que dans une seule phase, comme la détection de jailbreak en entrée et la détection d'hallucinations en sortie.

  8. Définissez le rang pour contrôler l'ordre d'évaluation. Le rang le plus bas s'exécute en premier sur la requête et en dernier sur la réponse.

  9. Cliquez sur Créer une politique .

La politique apparaît dans la **tab** des **Politiques** du service. Pendant la version bêta, prévoyez un court délai pour qu'il se propage avant de tester.

remarque

Pendant la version Beta, l'interface utilisateur de la politique pourrait changer. Si un libellé diffère de ces étapes, suivez les libellés du produit.

Utiliser une politique intégrée​

Databricks fournit des politiques de service intégrées dans le catalogue system.ai, telles que system.ai.block_pii pour bloquer les informations personnellement identifiables. Pour en utiliser un, suivez l'étape 2, mais choisissez le garde-fou intégré dans Type de garde-fou au lieu de Personnalisé . Les garde-fous intégrés ne nécessitent aucune configuration spécifique à une politique : vous définissez les mêmes champs Phase , Rang , Service de modèle d'évaluateur et Mode que pour toute autre politique.

Pour obtenir la liste complète des politiques intégrées, consultez les Politiques de service intégrées.

Vous avez besoin du privilège EXECUTE sur la fonction de politique intégrée et du privilège MANAGE sur le service cible.

Vérifier la politique​

Après avoir associé une stratégie, vérifiez qu'elle est active et qu'elle produit les résultats attendus.

remarque

Après avoir attaché ou modifié une politique, laissez un court instant pour que la modification prenne effet avant de tester. Pendant la phase bêta, les modifications de politique peuvent prendre jusqu'à une ou deux minutes pour se propager.

Confirmer le rattachement​

Dans la Passerelle d'IA Unity, ouvrez le service cible et affichez ses politiques attachées. La politique que vous avez créée apparaît dans la liste.

Observez les résultats de la politique​

Vous pouvez confirmer qu'une politique prend effet :

  • De l'appelant : lorsque la politique renvoie DENY, l'appelant reçoit une erreur structurée qui inclut le reason que vous avez spécifié. ASK suspend l'appel pour approbation humaine.
  • **Dans les tables système** : l'activité du modèle et du MCP est enregistrée dans les tables d'utilisation, et les charges utiles complètes de requête et de réponse dans les tables d'inférence.

Limitations​

Les limitations suivantes s'appliquent pendant la bêta :

  • Transformation : les politiques de service renvoient une décision (ALLOW, DENY ou ASK) ; elles ne transforment pas le contenu de la requête ou de la réponse pendant la version bêta.
  • Langage de stratégie : Les fonctions de stratégie personnalisées ne prennent en charge que LANGUAGE SQL.
  • **Portée de l'attachement** : l'attachement de politique est limité à l'interface utilisateur et à un service individuel, et la politique s'applique à tous les utilisateurs du compte. L'attachement de politiques au niveau du catalogue ou du schéma, les conditions de contrôle d'accès basé sur les attributs (ABAC) et les principaux personnalisés ne sont pas disponibles.
Sur cette page