règles de service pour les objets sécurisables d’IA

info

Bêta

Cette fonctionnalité est en bêta. Les administrateurs de Workspace peuvent contrôler l'accès à cette fonctionnalité depuis la page Aperçus en optant pour l'aperçu Politiques de service de passerelle Unity . Consultez Gérer les aperçus au niveau du workspace.

Les politiques de service vous permettent de régir le contenu des interactions avec les services d'IA enregistrés dans Unity Catalog — y compris les serveurs MCP externes et les modèles de tout fournisseur, pas seulement ceux hébergés par Databricks. Les octrois Unity Catalog déterminent *si* un principal peut appeler un service. Les politiques de service régissent la façon dont cette interaction se déroule, en fonction du contenu de la demande et de la réponse, et de la personne qui effectue l'appel.

Les politiques de service sont les mécanismes que vous utilisez pour implémenter des gardes-fous pour les services d’IA. Si vous souhaitez ajouter des gardes-fous, tels que le blocage des informations PII, des injections de invites ou du contenu dangereux, les politiques de service constituent le mécanisme : Databricks dispose de gardes-fous intégrés pour les risques courants, vous pouvez rédiger des politiques personnalisées pour des règles spécifiques à votre organisation, et vous pouvez appliquer les décisions d’un fournisseur de gardes-fous tiers à l’aide d’une politique de service externe.

C'est particulièrement important lorsque les agents agissent pour le compte des utilisateurs. Un agent hérite de tout ce auquel l'utilisateur peut accéder, et les services accèdent souvent à des systèmes externes. Les politiques de service vous permettent de définir des garde-fous pour cette activité. Par exemple, vous pouvez exiger le consentement de l'utilisateur avant qu'un agent ne pousse du code vers un repository Git via un service MCP, refuser la réponse d'un modèle contenant des informations personnelles identifiables (PII) ou bloquer du contenu dangereux.

Les politiques personnalisées peuvent également vérifier et imposer la présence ou l’absence de tags de requête fournis par l’appelant. Consultez Exiger un projet éligible et la référence des tags de requête.

Les politiques de service sont l'un des trois types de politiques de contrôle d'accès basées sur les attributs (ABAC) dans Unity Catalog :

• Les politiques ABAC GRANT accordent des privilèges Unity Catalog sur des éléments sécurisables dont les tags gouvernés correspondent à une condition. Ils déterminent si un principal peut accéder à un objet.
• Row filter and column mask policies contrôlent les lignes et les colonnes qu’un principal peut voir dans une table.
• Les politiques de service régissent le contenu de chaque requête et de chaque réponse adressées à un service IA afin de l’autoriser ou de le rejeter. Sur un service MCP, une politique peut également contenir une demande d’entrée pour approbation.

Les politiques ABAC GRANT relèvent du contrôle d'accès. Les politiques de filtrage de lignes et de masques de colonnes ainsi que les politiques de service sont des politiques de contenu qui régissent ce qui se passe une fois qu'un principal dispose d'un accès. À l'instar d'un filtre de lignes ou d'un masque de colonnes, une politique de service SQL personnalisée fait référence à une fonction Unity Catalog qui contient la logique de gouvernance et l'associe à un élément sécurisable.

Comment les politiques de service complètent les octrois de Unity Catalog

Les privilèges et les politiques de service d'Unity Catalog répondent à différentes questions de gouvernance et opèrent à différents points d'application.

Aspect	Privilèges Unity Catalog	Politiques de service
Question répondue	Ce principal peut-il appeler ce service ?	Comment cette interaction doit-elle procéder ?
Entrées	Identité du principal et privilèges accordés	Contenu de la demande, contenu de la réponse, balises de demande, annotations d'outils et contexte de l'acteur
Point d'application	Avant que la requête n'atteigne le service	Avant que le service ne soit invoqué (phase d'entrée, ON CALL) et après que le service a répondu (phase de sortie, ON RESULT)
Granularité	Par principal, par sécurisable	Par requête, en fonction du contenu et du contexte

Aspect	Privilèges Unity Catalog	Politiques de service
Question répondue	Ce principal peut-il appeler ce service ?	Comment cette interaction doit-elle procéder ?
Entrées	Identité du principal et privilèges accordés	Contenu de la demande, contenu de la réponse, balises de demande, annotations d'outils et contexte de l'acteur
Point d'application	Avant que la requête n'atteigne le service	Avant que le service ne soit invoqué (phase d'entrée, ON CALL) et après que le service a répondu (phase de sortie, ON RESULT)
Granularité	Par principal, par sécurisable	Par requête, en fonction du contenu et du contexte

Les stratégies de service ne remplacent pas les autorisations Unity Catalog. Un principal doit d'abord disposer des privilèges Unity Catalog appropriés pour appeler un service. Les stratégies de service évaluent ensuite le contenu de chaque interaction pour appliquer des règles de gouvernance supplémentaires.

Décisions politiques

Une politique de service évalue le contenu d'une requête ou d'une réponse et renvoie l'un des trois résultats suivants :

• **AUTORISER** : l'interaction se poursuit.
• DENY : la politique bloque l'interaction. Au lieu d'un statut d'erreur, Databricks renvoie une réponse de succès (HTTP 200). Le tour de l'assistant contient un court message nommant la politique de service qui a bloqué, et un objet databricks_service_policy de haut niveau contient les détails structurés, y compris le bloc reason. Le renvoi du bloc en tant que tour normal empêche les clients conversationnels qui renvoient l'historique complet, tels que les agents de codage, de re-trigger le même bloc à chaque tour ultérieur.
• ASK : sur un service MCP, la stratégie interrompt une requête pour obtenir l'approbation de l'utilisateur avant l'exécution de l'outil. Utilisez cette action lorsqu'un utilisateur doit approuver une opération sensible, telle qu'un appel d'outil MCP destructif. Pour les agents externes appelant un service MCP, l'invite d'approbation est transmise via l'élicitation en mode URL MCP. Si une politique SQL ou Python personnalisée renvoie ASK pour un service de modèle ou un service de fournisseur de modèles, Databricks bloque la requête ou la réponse, car ces services ne peuvent pas demander l'approbation de l'utilisateur. Consultez la page Rédiger une politique de décision.

Une politique personnalisée est soit une fonction définie par l'utilisateur (UDF) SQL qui reçoit l'événement d'interaction (lequel inclut l'acteur et le contenu de la requête ou de la réponse) et renvoie un résultat de décision, soit une politique de type LLM-as-a-judge qui classe le contenu en fonction de critères que vous rédigez en langage naturel. Les politiques intégrées sont gérées par Databricks, et une politique de service externe envoie le contenu à un service de garde tiers qui renvoie la décision.

Points d'évaluation

Databricks évalue une politique de service à deux moments dans chaque interaction :

• Entrée (ON CALL) : avant que Databricks n'appelle le service, par rapport à la requête. Utilisez cette phase pour inspecter les requêtes avant qu'elles n'atteignent le service sous-jacent. Par exemple, bloquez une requête qui appelle un outil MCP destructeur, ou refusez une invite contenant des PII avant qu'elle n'atteigne un modèle.
• Sortie (ON RESULT) : après la réponse du service, par rapport à la réponse. Utilisez cette phase pour inspecter les réponses avant qu'elles ne soient renvoyées à l'appelant. Par exemple, bloquez une réponse contenant du contenu hallucinatoire ou des données sensibles.

Une fonction de politique SQL personnalisée s’exécute aux deux points. Il inspecte la phase actuelle (event:type) et décide comment agir, afin qu’une seule politique puisse régir la demande, la réponse ou les deux. Pour agir sur une seule phase, Branch sur event:type dans le corps de la fonction. Les politiques intégrées et les politiques personnalisées de type LLM en tant que juge sont délimitées par un paramètre Phase . Certaines politiques intégrées prennent en charge différentes phases sur différents services. Le garde-fou Jailbreak ne s’exécute qu’en phase d’entrée sur les services de modèle et de fournisseur de modèle, et sur l’entrée, la sortie ou les deux sur les services MCP. Le formulaire de politique présélectionne la sortie pour Jailbreak sur un service MCP, mais les appelants de l’API doivent explicitement définir le champ de requête options.phases de la politique sur pre_call (entrée), post_call (sortie) ou pre_call,post_call (les deux). La détection d’hallucinations ne s’exécute qu’en phase de sortie. Les politiques de service externe sont également délimitées par phase : vous choisissez la phase d’entrée, la phase de sortie ou les deux lorsque vous en attachez une.

Ordre d'évaluation

Vous pouvez attacher plus d'une politique de service à un service. Chaque association possède un rang (priorité), et un DENY à un certain rang arrête l'évaluation de tous les rangs suivants. Databricks évalue les rangs par ordre croissant lors de la phase d' entrée (ON CALL, rang le plus bas en premier) et dans l'ordre inverse lors de la phase de sortie (ON RESULT). Les politiques de même rang conservent l'ordre dans lequel vous les avez associées lors des deux phases. Utilisez le rang pour contrôler quelles vérifications s'exécutent en premier.

Évaluation au sein d'un rang

Databricks évalue les politiques au même rang en deux étapes :

1. Les politiques bloquantes LLM-as-a-judge s'exécutent en parallèle. Il s'agit des politiques de type LLM-as-a-judge intégrées et personnalisées qui bloquent le contenu (DENY), telles que la détection de contenu dangereux. Comme il s'agit de contrôles s'appuyant sur un modèle, leur exécution simultanée signifie que leur latence ajoutée correspond approximativement à celle de l'évaluation individuelle la plus lente, et non à leur somme.
2. Les politiques restantes s’exécutent ensuite de manière séquentielle , mais uniquement si aucune politique de la première étape n’a renvoyé DENY. Cette étape couvre les politiques SQL personnalisées, les politiques de services externes, la politique intégrée system.ai.detect_sensitive_data et les politiques qui se mettent en pause pour approbation (ASK), y compris une politique LLM-as-a-judge configurée pour demander au lieu de bloquer. Elles s’exécutent dans l’ordre où vous les avez associées, sans ordre fixe par type de politique. ASK met en pause un appel d’entrée uniquement pour les services MCP. Pour les services de modèle et les services de fournisseur de modèle, ASK bloque la requête ou la réponse.

Un DENY dans l'étape parallèle ignore l'étape séquentielle. L'étape séquentielle ne s'arrête pas à un DENY: toutes les politiques qu'elle contient s'exécutent, même après qu'une d'elles a renvoyé DENY. Par exemple, une politique SQL personnalisée qui refuse une requête n'empêche pas une politique de service externe ultérieure de même rang d'envoyer le contenu à son fournisseur. Lorsque plusieurs politiques opposent un refus, l'appelant voit la raison provenant du premier DENY dans l'ordre d'attachement. Un DENY dans l'une ou l'autre étape arrête tous les rangs ultérieurs. Par conséquent, pour ignorer une politique lorsqu'une autre refuse l'accès, placez la politique de refus à un rang évalué en premier.

Étant donné que Databricks parallélise les vérifications lentes basées sur des modèles, l’empilement de plusieurs garde-fous bloquants sur un service n’en multiplie pas la latence.

Le diagramme suivant montre où se situent les deux phases autour d'un service et ce que chaque décision fait :

Pour voir les politiques associées à un service spécifique et leur ordre d'exécution, ouvrez le Policies tab du service et cliquez sur See execution flow .

Politiques de service intégrées

Databricks fournit des politiques de service intégrées sous l'espace de nom system.ai. Celles-ci couvrent les scénarios de gouvernance courants sans SQL personnalisé. Les garde-fous IA de Databricks sont des politiques de service intégrées : des politiques préconfigurées et gérées par Databricks (telles que la détection de contenu non sécurisé et de jailbreak) que vous attachez de la même manière qu’une politique personnalisée :

• system.ai.block_unsafe_content: refuse les interactions qui contiennent du contenu dangereux ou nuisible.
• system.ai.block_jailbreak: détecte le contenu de jailbreak et d'injection de prompt. Sur les services de modèle et les services de fournisseur de modèle, il évalue uniquement l’entrée du modèle. Sur les services MCP, il peut évaluer l’appel d’outil et les arguments en entrée, le résultat de l’outil en sortie ou les deux.
• system.ai.block_hallucination: refuse les réponses qui contiennent un contenu halluciné.
• system.ai.detect_sensitive_data: détecte les données sensibles structurées (telles que les numéros de carte de crédit et les numéros de sécurité sociale) et bloque l'interaction ou masque les valeurs correspondantes. Contrairement aux autres, il est déterministe (basé sur des modèles, sans modèle d'évaluation) et peut masquer plutôt que simplement bloquer. Voir Détectez les données sensibles avec une politique de service.

Pour utiliser une stratégie intégrée, attachez-la à un service. Vous devez disposer de MANAGE sur le service cible.

remarque

Les politiques intégrées sont gérées par Databricks et n'apparaissent pas comme des fonctions que vous pouvez parcourir dans le schéma system.ai dans l'explorateur de catalogue. Vous les sélectionnez et les associez par leur nom via l'interface utilisateur Unity Gateway, comme décrit dans Créer et associer une politique de service.

Fonctionnement des stratégies de service intégrées

Les politiques de service intégrées sont des vérifications LLM-as-a-judge : chacune exécute un prompt organisé par Databricks contre un modèle d'évaluateur pour décider si le contenu enfreint la politique.

Le service de modèle d'évaluation

Chaque politique de service intégrée exécute son prompt sur un service de modèle d’évaluation , le modèle qui évalue le contenu. Databricks présélectionne un evaluateur par default, de sorte qu’aucun paramétrage n’est requis. Pour utiliser un autre modèle, développez l’élément Options avancées lorsque vous associez la politique et sélectionnez-en un. Vous avez besoin de EXECUTE sur le service de modèle que vous choisissez, ainsi que de USE CATALOG et de USE SCHEMA sur son catalogue et son schéma. Consultez Accorder l’accès à un service de modèle. Databricks vérifie cet accès lorsque vous associez la politique, de sorte que les appelants du service protégé n’ont pas besoin d’accéder à l’évaluateur. L’évaluateur est distinct du service que vous protégez, de sorte qu’une politique peut évaluer une requête adressée à un service de modèle en utilisant un modèle différent comme évaluateur.

Databricks gère le prompt de la politique, qui est en lecture seule. Vous pouvez le consulter sous Prompt lorsque vous associez la politique pour voir les critères exacts que l'évaluateur applique.

Ce que l’évaluateur reçoit

Lorsqu’une politique de service intégré s’exécute, Databricks envoie à l’évaluateur une demande en deux parties :

• Un **message système** qui contient l'invite de stratégie et un contrat de sortie (décrit dans la section suivante).
• Un message utilisateur contenant le contenu à évaluer. Dans la phase d'entrée, il s'agit du dernier message de l'utilisateur sur un modèle ou un service de fournisseur de modèle, ainsi qu'une fenêtre de tours de conversation récents (voir ci-dessous), ou l'appel d'outil et ses arguments sur un service MCP. Dans la phase de sortie, il s'agit de la réponse du modèle ou du résultat de l'outil MCP après l'exécution de l'outil.

L'évaluateur reçoit du texte sérialisé plutôt que des charges utiles image ou audio décodées. Sur la phase de sortie et sur les services MCP, il juge uniquement cet élément extrait. Pour l’évaluation de la sortie Jailbreak sur un service MCP, l’entrée inclut result.content et result.structuredContent, y compris le texte en ligne et les blobs de ressources textuelles. Les autres juges LLM sur les services MCP ne reçoivent que result.content. Dans la phase d’entrée, les juges LLM sur les services MCP ignorent les appels d’outil qui n’ont pas d’arguments.

Le jailbreak sur un service MCP extrait les blobs de ressources de la même manière que la détection des données sensibles. Le décodage est le meilleur effort : les blobs qui ne peuvent pas être décodés ou qui dépassent la limite de taille sont omis. La sélection utilise le type de média (mimeType) déclaré par le serveur MCP. Un type de média manquant ou vide est traité comme du texte, et les blobs déclarés comme non textuels sont exclus. L'évaluateur ne récupère pas les Link de Ressource.

La fonction Jailbreak sur un service MCP filtre les appels d'outils (tools/call) et leurs résultats. Les descriptions d'outils renvoyées par tools/list ne sont pas filtrées.

Lors de la phase d’entrée des services de modèle et de fournisseur de modèles, l’évaluateur reçoit également une fenêtre contenant les tours de conversation récents afin de détecter les schémas qui se construisent au fil d’une conversation, comme une escalade progressive. Lorsque vous créez une politique dans le formulaire de politique, la fenêtre de conversation est définie par défaut sur les 10 derniers tours. Vous pouvez modifier le nombre, le définir sur 1 pour évaluer uniquement le dernier message ou sélectionner Évaluer l’intégralité de la conversation . Une politique pour laquelle aucune fenêtre de conversation n’est définie n’évalue que le dernier message.

Contrat de sortie

Databricks ajoute automatiquement un contrat de sortie JSON à l'invite de politique, de sorte que l'évaluateur renvoie une décision structurée au lieu d'un texte libre. L'évaluateur renvoie :

• flagged (booléen) : true si le contenu enfreint les critères de la politique.
• confidence (flottant, 0.0 à 1.0, facultatif) : la confiance de l'évaluateur dans la décision.
• reason (chaîne) : brève explication des raisons pour lesquelles le contenu a été signalé. Retourné lorsque flagged est true.

Lorsque l'évaluateur renvoie flagged: true, Databricks bloque l'interaction default. Sur un service MCP, une politique configurée pour demander suspend la requête pour obtenir une approbation humaine avant l'exécution de l'outil. Puisque Databricks applique le contrat pour vous, les politiques de service intégrées ne nécessitent aucune configuration au-delà de la phase et du rang.

Un évaluateur OpenJev n’utilise pas ce contrat. Il répond plutôt à une question de type indicateur ou autorisation et ne renvoie aucun reason. Consultez Utiliser OpenJev comme évaluateur.

L’évaluateur est un modèle, de sorte que ses verdicts ne sont pas déterministes, et le paramètre reason correspond à un texte libre court plutôt qu’à des données structurées. Pour voir quelles politiques ont été exécutées lors d’une requête et ce que chacune a décidé, utilisez la table de traces unifiée. Pour afficher également le paramètre confidence d'un juge ainsi que le contenu exact qu’il a évalué, activez une table d’inférence sur le service de modèle de l’évaluateur. Consultez la section Déboguer et auditer une décision de politique.

Coût de l'évaluation

Databricks ne facture pas de frais distincts pour les politiques de service intégré. Chaque évaluation est facturée comme tout autre appel au service de modèle d'évaluateur, de sorte que le coût dépend de la manière dont ce modèle est servi. Les jetons facturés pour chaque évaluation couvrent l'invite de la politique, le contrat de sortie, le message extrait et la réponse de l'évaluateur. Pour limiter les frais généraux, maintenez un petit nombre de politiques par phase et préférez un modèle d'évaluateur à faible latence.

Politiques de service externe

Une stratégie de service externe applique les décisions d'un fournisseur de barrières de sécurité tiers, comme un service de sécurité IA ou de prévention des pertes de données. Vous l'attachez avec le type de barrière de sécurité Externe et l'orientez vers une connexion HTTP Unity Catalog qui stocke l'endpoint du fournisseur et les identifiants machine-à-machine OAuth. À chaque évaluation, Databricks envoie le contenu évalué au fournisseur, qui retourne un verdict avec une raison facultative, et Databricks applique le résultat.

Le fournisseur doit implémenter l'API de politique externe Databricks. Les politiques de service externe renvoient ALLOW ou DENY, ou ASK pour maintenir un appel d'outil MCP en attente d'approbation de l'utilisateur. Ils ne peuvent pas supprimer de contenu. Ils échouent par défaut ; un endpoint de fournisseur inaccessible ou lent refuse donc l'appel. Consultez Appliquer une garde-fou de partenaire avec une politique de service externe.

Services pris en charge

Vous pouvez associer des stratégies de service aux objets sécurisables du service Unity Catalog suivants :

• Services MCP: serveurs MCP gérés, externes et personnalisés.
• Services de modèle: endpoints LLM hébergés et externes.
• **Services de fournisseur de modèles** : fournisseurs de modèles externes gouvernés.

Comportement de basculement en mode sécurisé

L'évaluation de la politique de service utilise une sémantique de fail-closed. Lorsque vous attachez une politique via Unity Gateway, Databricks la valide au moment de l’attachement, et toute erreur lors de l’évaluation entraîne DENY. Les erreurs incluent les erreurs utilisateur dans la fonction de politique, les erreurs système, les champs manquants dans le contexte de la requête et les délais d’attente. Pour une politique de service externe, les erreurs incluent également un endpoint de fournisseur qui est inaccessible, renvoie une erreur ou renvoie un verdict autre que ALLOW, DENY ou ASK.

Une politique mal configurée ou défectueuse bloque l'interaction au lieu de la permettre.

Une politique en mode Logs n’est pas appliquée. Il enregistre ce que la politique aurait décidé sans bloquer l'interaction, de sorte que même un DENY potentiel laisse la requête se poursuivre. La validation des requêtes s'applique toujours, y compris la validation des tags de requête.

Limitations

Les limitations suivantes s’appliquent :

• Transformation : les politiques de service renvoient une décision (ALLOW, DENY ou ASK) et ne transforment pas le contenu de la requête ou de la réponse. La seule exception est la politique intégrée system.ai.detect_sensitive_data, qui peut masquer les valeurs correspondantes sur les services de modèle.
• Stratégies de service externe : une stratégie de service externe retourne ALLOW ou DENY, ou ASK lors d'un appel d'outil MCP, et prend en charge uniquement l'authentification machine-à-machine OAuth. Voir Limitations des politiques de service externe.
• Services pris en charge : Les politiques de service s'appliquent aux services MCP, aux services de modèle et aux services de fournisseur de modèle. Les Services aux agents ne sont pas pris en charge.
• Model provider service passthrough : On a model provider service, Databricks does not evaluate service policies on passthrough requests, which Unity Gateway forwards to the provider unchanged when you enable Forward all URL paths . Policies apply only to the provider's supported API paths.
• Fenêtre de conversation : seule l’évaluation des entrées sur les services de modèle et de fournisseur de modèles peut utiliser une fenêtre de conversation. L'évaluation des sorties et les services MCP jugent un seul message, un appel d'outil ou un résultat d'outil. Voir Comment fonctionnent les stratégies de service intégrées.
• Évaluation imbriquée : Si le service de modèle d'évaluateur que vous sélectionnez pour une politique de service intégré possède ses propres politiques attachées, Databricks les ignore lors de l'exécution de l'évaluation. Cela empêche la récursion.

Étapes suivantes

• Créer et associer une politique de service
• Exemples de politiques de service
• Détectez les données sensibles avec une politique de service
• Appliquez un garde-fou de partenaire avec une politique de service externe
• Référence de la fonction de politique de service
• Tutoriel : ajouter des garde-fous de politique de service à un service de modèle