règles de service pour les objets sécurisables d’IA
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.
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 mettre en œuvre des garde-fous pour les services d'IA. Si vous cherchez à ajouter des garde-fous, tels que le blocage des PII, l'injection de prompt ou le contenu dangereux, les politiques de service sont le mécanisme : Databricks dispose de garde-fous intégrés pour les risques courants, et vous pouvez écrire des politiques personnalisées pour les règles spécifiques à votre organisation.
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 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 GRANT ABAC relèvent du contrôle d’accès ; les politiques de filtrage de lignes, de masquage de colonnes et de services sont des politiques de contenu , qui régissent ce qui se passe après qu’un principal a obtenu l’accès. À l’instar d’un filtre de lignes ou d’un masque de colonnes, une politique de service 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, 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_policyde haut niveau contient les détails structurés, y compris le blocreason. 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
ASKpour 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 est une fonction SQL définie par l'utilisateur (UDF) qui reçoit l'événement d'interaction (qui inclut l'acteur et le contenu de la requête ou de la réponse) et renvoie un résultat de 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 personnalisée s'exécute aux deux points. Elle inspecte la phase actuelle (event:type) et décide de la marche à suivre, de sorte qu'une seule politique peut régir la demande, la réponse, ou les deux. Pour agir sur une seule phase, effectuez un Branch sur event:type dans le corps de la fonction. Les politiques intégrées sont limitées par une option phases, et certaines ne s'exécutent que dans une seule phase (par exemple, la détection de jailbreak ne s'exécute que sur la phase d'entrée et la détection d'hallucination uniquement sur la phase de sortie).
Ordre d'évaluation
Vous pouvez attacher plus d'une politique de service à un service. Chaque pièce jointe possède un rang (priorité), et la chaîne s'arrête au premier DENY. Databricks évalue les politiques par ordre de rang 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). 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 :
- Les politiques bloquantes LLM-as-a-judge s'exécutent en parallèle. Ces politiques sont intégrées et bloquent les contenus (
DENY), tels que la détection de contenu dangereux. Comme il s'agit des vérifications basées sur le modèle, les exécuter simultanément signifie que leur latence ajoutée est approximativement celle de l'évaluation unique la plus lente, et non leur somme. - Les politiques restantes s'exécutent ensuite de manière séquentielle , mais uniquement si chaque politique parallèle de la première étape a autorisé l'interaction. Cette étape couvre les politiques SQL personnalisées et les politiques qui utilisent
ASK, évaluées dans l'ordre où vous les avez associées.ASKinterrompt un appel d'entrée uniquement pour les services MCP. Pour les services de modèles et les services de fournisseur de modèle,ASKbloque la requête ou la réponse.
L'évaluation est court-circuitée au premier DENY de l'une ou l'autre des étapes, de sorte que les politiques ultérieures à ce rang et à tous les rangs supérieurs ne s'exécutent pas. Comme Databricks parallélise les vérifications lentes effectuées par les modèles, l'ajout de plusieurs garde-fous bloquants sur un service ne multiplie pas leur 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: refuse les requêtes qui tentent de contourner les instructions de sécurité du modèle.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.
Pendant la version bêta, 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 de l’explorateur de catalogue. Vous les sélectionnez et les attachez par leur nom via l’interface utilisateur de Unity Gateway, comme décrit dans Créer et attacher 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 qui contient le contenu en cours d'évaluation : pour l'entrée, le dernier message utilisateur sur un service de modèle ou l'appel d'outil et ses arguments sur un service MCP ; pour la sortie, la réponse du modèle.
L'évaluateur ne voit que cet élément extrait unique. Il ne voit pas l'invite système du service protégé ni le contenu image et audio. By default, chaque évaluation est limitée à un seul message ; ainsi, une politique de service intégrée ne peut pas détecter les modèles s'étendant sur plusieurs messages, comme une escalade progressive au cours d'une conversation.
Pour l'évaluation des entrées sur les services de modèle et de fournisseur de modèle, vous pouvez augmenter cette fenêtre. Lorsque vous associez la politique, définissez le nombre de tours de conversation récents que l'évaluateur reçoit ; il voit ainsi cette fenêtre de tours au lieu du dernier message uniquement. Ceci s'applique uniquement à l'entrée et n'est pas disponible sur les services MCP.
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) :truesi 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é lorsqueflaggedesttrue.
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 étant un modèle, ses verdicts sont non déterministes et le reason est un texte libre court plutôt que des données structurées. Pour voir et auditer un verdict spécifique, y compris ses confidence et reason, activez une table d’inférence sur le service de modèle d’évaluateur. Consultez 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.
Services pris en charge
Pendant la version bêta, vous pouvez attacher des politiques de service aux objets sécurisables de 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 fermeture en cas d’échec (fail-closed). Lorsque vous joignez une politique via Unity Gateway, Databricks la valide au moment de la jointure, 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 (timeouts).
Une politique mal configurée ou défectueuse bloque l'interaction au lieu de la permettre.
Une stratégie en mode Logs n’est pas contraignante. Elle enregistre ce que la stratégie aurait décidé sans bloquer l’interaction, de sorte que même un éventuel DENY n’empêche pas la requête de poursuivre son traitement.
Limitations
Les limitations suivantes s'appliquent pendant la bêta :
- 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 pendant la version bêta. 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. - 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.
- Évaluation d'un message unique : par default, une stratégie de service intégrée évalue un message à la fois. Pour l'évaluation des entrées sur les services de modèle et de fournisseur de modèle, vous pouvez augmenter la fenêtre à un certain nombre de tours de conversation récents. L'évaluation de la sortie et les services MCP restent limités à un message unique. Consultez 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.