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 rédigez 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 Unity Gateway .

La politique régit chaque interaction à deux points d'évaluation :

  • La phase d’entrée (ON CALL) avant que Databricks n’appelle le service.
  • La phase de sortie (ON RESULT) après la réponse du service.

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 ; effectuez un branch sur event:type::string ('request' pour la phase d’entrée, 'response' pour la phase de sortie) pour agir sur une seule phase. Pour obtenir la liste complète des champs event, 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. Au lieu d’une erreur, l’appelant reçoit une réponse réussie (HTTP 200) dont le tour de l’assistant signale le bloc, avec le reason dans un objet databricks_service_policy de niveau supérieur.
  • 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.

Pour plus de politiques personnalisées, notamment les listes d’autorisation d’outils, les blocages de mots-clés et de sujets, les limites de longueur de requête, les vérifications de réponse et les classifieurs LLM en tant que juge, consultez Exemples de politiques de service.

Étape 2 : Associez la politique à un service​

Pendant la version bêta, vous associez une politique de service via l’interface utilisateur de Unity Gateway , sur un MCP Service, un Model Service ou un Model Provider Service individuel. Vous pouvez associer plus d’une politique à un service : chaque association possède une priorité (rang) et la chaîne s’arrête à la première DENY. Lors de la phase d’entrée, les politiques sont évaluées par ordre de rang croissant (le plus bas en premier) ; lors de la phase de sortie, 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 Unsafe Content ou Jailbreak . 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 de CAN_QUERY 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 sous l’espace de noms system.ai, telles que system.ai.block_unsafe_content pour bloquer les contenus dangereux ou nuisibles. Pour en utiliser un, suivez l’ étape 2 mais choisissez le garde-fou intégré dans Guardrail type au lieu de Custom . Les garde-fous intégrés ne nécessitent aucune configuration spécifique à la politique : vous définissez les mêmes champs Phase , Rank , Evaluator model service et Mode que pour n’importe quelle politique.

Pour obtenir la liste complète des stratégies intégrées et une remarque sur la façon dont elles apparaissent dans Unity Catalog, consultez Stratégies 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 Unity Gateway, ouvrez le service cible et affichez les politiques qui lui sont associé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 réponse réussie (HTTP 200) plutôt qu'une erreur. Le tour de l'assistant indique que le contenu a été bloqué, et un objet databricks_service_policy de haut niveau contient le reason que vous avez spécifié. ASK met l'appel en pause pour une 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.

Déboguer et auditer une décision de politique​

Lorsqu’une politique bloque une interaction, le bloc reason dans l’objet databricks_service_policy nomme la politique et fournit une brève explication. Voir Observer les résultats de la politique.

Pour voir le raisonnement complet derrière une décision LLM-as-a-judge intégrée ou personnalisée, y compris la confiance de l’évaluateur et le contenu exact qu’il a jugé, examinez la table d’inférence du service de modèle de l’évaluateur.

Une politique LLM-as-a-judge exécute son prompt sur un service de modèle d’évaluateur distinct (le juge). Le verdict du juge n’est pas enregistré dans la table d’inférence du service protégé, qui ne Logs que la propre requête et réponse du service protégé. L’entrée et le verdict du juge ne sont capturés que lorsqu’une table d’inférence est activée sur le service de modèle évaluateur .

Capturer les verdicts de l’évaluateur​

Activez une table d’inférence sur le service de modèle qui exécute la vérification. Vous avez deux options :

  • Activer une table d’inférence directement sur l’évaluateur déjà utilisé par la barrière de sécurité. L’évaluateur « default » est un service de modèle system.ai, et vous pouvez y activer une table d’inférence.
  • Sous Options avancées , lorsque vous attachez la politique, pointez le garde-fou vers un service de modèle d’évaluation que vous possédez (il ne doit pas nécessairement s’agir d’un modèle system.ai), puis activez une table d’inférence sur ce service.

Pour activer une table d’inférence, consultez Logs les requêtes et les réponses dans des tables d’inférence. Activez-la avant les interactions que vous souhaitez auditer : seules les évaluations exécutées après l’activation des Logs sont capturées, et les lignes peuvent mettre quelques minutes à apparaître.

Lire un verdict​

Chaque évaluation écrit une ligne par politique et par phase dans la table d’inférence de l’évaluateur :

  • request est le prompt de juge assemblé : les critères de la politique, le contrat de sortie JSON et le contenu en cours d’évaluation enveloppé dans des marqueurs <ContentToEvaluate>. Pour une politique d’entrée multi-tours (fenêtre de conversation), le contenu évalué correspond aux tours récents ainsi qu’à la dernière entrée ; sinon, il s’agit du message unique.
  • response est la complétion brute de l’évaluateur. Le verdict est le contenu du message de l’assistant : un objet JSON avec flagged, confidence et, lorsque flagged est true, reason.
  • destination_name identifie l’évaluateur, et request_id lie l’évaluation à l’interaction qui l’a déclenchée.

Pour trouver les évaluations ayant bloqué du contenu, filtrez la table d'inférence de l'évaluateur sur le verdict :

SQL
SELECT
  event_time,
  request_id,
  get_json_object(response, '$.choices[0].message.content') AS verdict,
  request
FROM <catalog>.<schema>.<evaluator_inference_table>
WHERE get_json_object(response, '$.choices[0].message.content') ILIKE '%"flagged":true%'
ORDER BY event_time DESC;

La colonne verdict affiche la décision de l’évaluateur, telle que {"flagged":true,"confidence":0.87,"reason":"..."}. Un reason n’apparaît que lorsque flagged est true. Pour tracer une interaction spécifique à la place, filtrez par son request_id.

remarque

Auditez les blocages à partir de la table d’inférence de l’évaluateur, et non de celle du service protégé. Lorsqu’une politique de phase d’entrée refuse une requête, Databricks n’invoque pas le service sous-jacent ; par conséquent, une interaction bloquée peut ne pas produire de ligne dans la table d’inférence du service protégé. L’extraction des ID de requête à partir de la table protégée omet donc les interactions bloquées ; filtrez plutôt la table de l’évaluateur sur le verdict.

Restreindre à une interaction dans une grande table​

La table d’inférence de l’évaluateur ne possède pas de colonne de nom de politique, et le id dans le corps de la réponse (chatcmpl-...) n’est pas le request_id. Restreignez la recherche à l’interaction que vous êtes en train de debugging à l’aide de ces filtres, et limitez l’analyse par période :

  • request_id (le plus précis) : chaque évaluation pour une interaction le partage. Capturez-le à partir de l’en-tête de réponse databricks-request-id de l’appel, puis filtrez WHERE request_id = '<id>'. Cela fonctionne pour un bloc. Confirmez que la valeur de l’en-tête correspond à la colonne, car le champ id du corps de la réponse est une valeur différente.
  • Contenu de la demande : le request du juge contient le contenu évalué ; ainsi, une chaîne distinctive dans votre prompt permet de pin l’interaction, par exemple request ILIKE '%<your marker>%'.
  • Temps : event_time >= current_timestamp() - INTERVAL 30 MINUTES limite l’analyse.

Pour savoir quelle politique a produit une ligne, lisez son request. Le message système correspond aux critères de cette politique, ce qui vous permet de filtrer et d’identifier la politique. Par exemple request ILIKE '%<distinctive phrase from the policy prompt>%'. Le reason dans le verdict reformule généralement le Trigger.

SQL
SELECT event_time, request_id, invocation_id,
       get_json_object(response, '$.choices[0].message.content') AS verdict,
       request
FROM <catalog>.<schema>.<evaluator_inference_table>
WHERE event_time >= current_timestamp() - INTERVAL 30 MINUTES
  AND request ILIKE '%<your marker or prompt text>%'
  AND get_json_object(response, '$.choices[0].message.content') ILIKE '%"flagged":true%'
ORDER BY event_time DESC;

Non-déterminisme et tests de simulation​

L’évaluateur est un modèle, ses verdicts sont donc non déterministes : la même entrée peut renvoyer des verdicts différents selon les exécutions, et la variation est plus importante entre différents modèles d’évaluateur ou lorsque le routage des requêtes couvre plusieurs versions de modèle. Le reason est un texte libre court, et non des données structurées par entité, et il peut citer le contenu signalé. Pour une vérification répétable et déterministe, utilisez la politique intégrée Sensitive Data Detection ou une politique SQL personnalisée au lieu d’un juge LLM.

Databricks recommande d'attacher d'abord une politique LLM-as-a-judge en mode Log , ce qui enregistre le verdict sans bloquer, avec une table d'inférence activée sur son évaluateur. Inspectez les verdicts sur le trafic réel, affinez le prompt et le classement, puis basculez la politique sur Enforce . La détection des données sensibles s'exécute uniquement en mode d'application.

Droits d’accès​

Les étapes ci-dessus nécessitent les privilèges suivants :

Étape

Accès requis

Attachez le garde-fous

MANAGE sur le service cible (protégé) et EXECUTE sur la fonction de politique que vous joignez. Voir Étape 2.

Sélectionnez un évaluateur non-default

CAN_QUERY selon le service de modèle d’évaluateur que vous choisissez.

Activer un tableau d’inférence sur l’évaluateur

Autorisation de gérer le service de modèle d’évaluation (par exemple, si vous l’avez créé), ainsi que USE CATALOG, USE SCHEMA et CREATE TABLE sur le catalogue et le schéma où la table est stockée. Consultez les prérequis de la table d’inférence.

Lire le tableau d’inférence de l’évaluateur

SELECT sur la table, plus USE CATALOG et USE SCHEMA sur son catalogue et son schéma. Le créateur du service de modèle est propriétaire de la table et accorde l’accès à d’autres personnes.

Étape

Accès requis

Attachez le garde-fous

MANAGE sur le service cible (protégé) et EXECUTE sur la fonction de politique que vous joignez. Voir Étape 2.

Sélectionnez un évaluateur non-default

CAN_QUERY selon le service de modèle d’évaluateur que vous choisissez.

Activer un tableau d’inférence sur l’évaluateur

Autorisation de gérer le service de modèle d’évaluation (par exemple, si vous l’avez créé), ainsi que USE CATALOG, USE SCHEMA et CREATE TABLE sur le catalogue et le schéma où la table est stockée. Consultez les prérequis de la table d’inférence.

Lire le tableau d’inférence de l’évaluateur

SELECT sur la table, plus USE CATALOG et USE SCHEMA sur son catalogue et son schéma. Le créateur du service de modèle est propriétaire de la table et accorde l’accès à d’autres personnes.

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