AIセキュリティ保護対象のサービスポリシー
ベータ版
この機能はベータ版です。アカウント管理者は、アカウント コンソールの [プレビュー] ページからこの機能へのアクセスを制御できます。 Databricksのプレビューを管理するを参照してください。
サービスポリシーにより、Unity Catalogに登録されたAIサービスとのやり取りのコンテンツ（Databricksがホストするものだけでなく、 外部 のMCPサーバーやあらゆるプロバイダーのモデルを含む）を管理できます。Unity Catalogの付与は、プリンシパルがサービスを呼び出すことが できるかどうか を決定します。サービスポリシーは、リクエストと応答のコンテンツ、および呼び出しを行っているユーザーに基づいて、そのやり取りが どのように 進むかを管理します。
サービスポリシーは、AIサービスのガードレールを実装するために使用するメカニズムです。PIIのブロック、プロンプトインジェクション、安全でないコンテンツのブロックなどのガードレールを追加する場合、サービスポリシーがそのメカニズムとなります。Databricksには一般的なリスクに対する組み込みのガードレールが用意されているほか、組織固有のルールに合わせてカスタムポリシーを作成したり、外部サービスポリシーを使用してサードパーティのガードレールベンダーの決定を適用したりすることができます。
これは、エージェントがユーザーに代わって動作する場合に最も重要になります。エージェントはユーザーがアクセスできるすべてのものを継承し、サービスは外部システムにアクセスすることがよくあります。サービスポリシーを使用すると、そのアクティビティにガードレールを設定できます。たとえば、MCPサービスを介してエージェントがGitリポジトリにコードをプッシュする前にユーザーの同意を要求したり、個人を特定できる情報（PII）が含まれるモデルレスポンスを拒否したり、安全ではないコンテンツをブロックしたりできます。
Custom ポリシー can also check and enforce the presence or absence of caller-supplied request タグ.See Require an eligible project and the request タグ reference.
サービスポリシーは、Unity Catalog における 3 種類の属性ベースのアクセス制御（ABAC）ポリシーの 1 つです。
- ABAC GRANT ポリシーは、管理タグが条件に一致するセキュリティ保護可能なオブジェクトに対して Unity Catalog の権限を付与します。これらは、プリンシパルがオブジェクトに到達できるかどうかを制御します。
- 行フィルターと列マスクのポリシーは、プリンシパルがテーブル内のどの行と列を表示できるかを制御します。
- サービスポリシーは、AIサービスへの各リクエストおよびレスポンスのコンテンツを管理し、それを許可または拒否します。MCPサービスでは、ポリシーによって承認のために入力リクエストを保留することもできます。
ABACのGRANTポリシーはアクセス制御です。行フィルター、列マスクの各ポリシーおよびサービスポリシーは コンテンツ ポリシーであり、プリンシパルがアクセスした後の動作を制御します。行フィルターや列マスクと同様に、カスタムSQLサービスポリシーは、ガバナンスロジックを含むUnity Catalog関数を参照し、それをセキュア可能オブジェクトにアタッチします。
サービスポリシーがUnity Catalogの付与を補完する方法
Unity Catalogの権限とサービスポリシーは、異なるガバナンスの課題に対応し、異なる適用ポイントで運用されます。
観点 | Unity Catalog の権限 | サービスポリシー |
|---|---|---|
質問への回答 | このプリンシパルはこのサービスを呼び出すことができますか？ | このインタラクションはどのように進行すべきですか？ |
入力 | プリンシパルの識別情報と付与された権限 | リクエストコンテンツ、レスポンスコンテンツ、リクエストタグ、ツールアノテーション、およびアクターコンテキスト |
適用ポイント | リクエストがサービスに到達する前に | サービスが呼び出される前（入力フェーズ、ON CALL）およびサービスが応答した後（出力フェーズ、ON RESULT） |
粒度 | プリンシパルごと、セキュリティ保護可能なオブジェクトごと | リクエストごとに、コンテンツとコンテキストに基づいて |
サービスポリシーはUnity Catalogの権限を置き換えるものではありません。プリンシパルは、サービスを呼び出すためにまず適切なUnity Catalog権限を持っている必要があります。サービスポリシーは、各インタラクションのコンテンツを評価し、追加のガバナンスルールを適用します。
ポリシー決定
サービスポリシーはリクエストまたはレスポンスの内容を評価し、次の3つの結果のいずれかを返します。
- 許可 ：インタラクションが進行します。
- DENY : ポリシーがインタラクションをブロックします。Databricksはエラー ステータスの代わりに、成功（HTTP 200）レスポンスを返します。アシスタントのターンにはブロックの原因となったサービスポリシーを示す短いメッセージが含まれ、最上位の
databricks_service_policyオブジェクトにはブロックreasonを含む構造化された詳細情報が含まれます。ブロックを通常のターンとして返すことで、コーディングエージェントのように履歴全体を再送信する会話型クライアントが、その後のすべてのターンで同じブロックを再Triggerすることを防ぎます。 - ASK ：MCPサービスの場合、ツールがランする前に、ポリシーによってユーザーの承認を求めるリクエストが停止される。破壊的なMCPツール呼び出しなど、ユーザーが機密性の高い操作を承認する必要がある場合に、このアクションを使用します。MCPサービスを呼び出す外部エージェントの場合、承認プロンプトはMCP URLモード・エリシテーションを通じて配信されます。カスタムのSQLまたはPythonポリシーがモデルサービスまたはモデルプロバイダーサービスに対して
ASKを返す場合、Databricksはユーザーに承認を求めることができないため、リクエストまたはレスポンスをブロックします。決定ポリシーの記述をご覧ください。
カスタムポリシーは、インタベーショングイベント（アクター、リクエストまたはレスポンスの内容を含む）を受信して決定結果を返すSQLユーザー定義関数（UDF）、または自然言語で記述した基準に基づいてコンテンツを分類するLLM-as-a-judgeポリシーのいずれかです。組み込みポリシーは Databricks によって管理され、外部サービスポリシーによってコンテンツがサードパーティのガードレールサービスに送信され、決定結果が返されます。
評価ポイント
Databricks は、すべてのインタラクションで 2 つの点でサービス ポリシーを評価します。
- 入力 (ON CALL): Databricks がサービスを呼び出す前、リクエストに対して。このフェーズを使用して、リクエストが基盤となるサービスに到達する前に検査します。例えば、破壊的な MCP ツールを呼び出すリクエストをブロックしたり、PII を含むプロンプトがモデルに到達する前に拒否したりします。
- 出力（ON RESULT）：サービスが応答した後、その応答に対して実行されます。このフェーズを使用して、応答が呼び出し元に返される前に検査します。例えば、幻覚コンテンツや機密データを含むレスポンスをブロックします。
カスタム SQL ポリシー関数は、両方のポイントでランされます。現在のフェーズ（event:type）を検査して対処方法を決定するため、単一のポリシーでリクエスト、レスポンス、またはその両方を管理できます。1つのフェーズのみで処理を行うには、関数本体内で event:type に Branch します。組み込みポリシーおよびカスタム LLM-as-a-judge ポリシーは、代わりに Phase 設定のスコープを持ち、一部の組み込みポリシーは1つのフェーズのみで実行されます（たとえば、ジェイルブレイク検出は入力フェーズでのみ実行され、ハルシネーション検出は出力フェーズでのみ実行されます）。外部サービスポリシーもフェーズによってスコープが設定されます。アタッチする際に、入力フェーズ、出力フェーズ、またはその両方を選択します。
評価順序
1つのサービスに複数のサービスポリシーをアタッチできます。各添付ファイルには ランク （優先度）があり、特定のランクの DENY によって、それ以降のすべてのランクの評価が停止されます。Databricks は、 入力 フェーズ（ON CALL、ランクが最も低いものが最初）では昇順で、 出力 フェーズ（ON RESULT）では逆順でランクを評価します。同じランクのポリシーは、両方のフェーズでアタッチした順序を維持します。ランクを使用して、最初に実行するチェックを制御します。
ランク内の評価
Databricksは、同じランクのポリシーを2つのステージで評価します：
- Blocking LLM-as-a-judge ポリシー ラン in parallel. これらは、不安全なコンテンツの検出など、(
DENY) コンテンツをブロックする組み込みおよびカスタムの LLM-as-a-judge ポリシーです。これらはモデルベースのチェックであるため、並行して実行しても、追加のレイテンシーは合計ではなく、最も遅い単一の評価のレイテンシーと同等になります。 - その後、残りのポリシーが順番に実行されます が、これは第 1 ステージのどのポリシーでも
DENYが返されなかった場合に限ります。このステージでは、カスタム SQL ポリシー、外部サービスポリシー、system.ai.detect_sensitive_dataの組み込みポリシー、および承認のために一時停止するポリシー（ASK）を取り上げます。これには、ブロックする代わりに確認を行うように設定された LLM-as-a-judge ポリシーセットも含まれます。これらは、ポリシーの種類による固定された順序はなく、アタッチした順序で実行されます。ASKは MCP サービスに対する入力呼び出しのみを停止します。モデルサービスおよびモデルプロバイダーサービスの場合、ASKはリクエストまたはレスポンスをブロックします。
並列ステージ内のDENYは、シーケンシャルステージをスキップします。シーケンシャルステージはDENYで停止しません。その中のすべてのポリシーは、1つがDENYを返した後でも実行されます。例えば、リクエストを拒否するカスタムSQLポリシーは、同じランクにある後続の外部サービスポリシーがそのコンテンツをベンダーに送信することを停止しません。複数のポリシーが拒否する場合、呼び出し元にはアタッチ順序で最初のDENYからの理由が表示されます。どちらかのステージのDENYは後続のすべてのランクを停止するため、別のポリシーが拒否したときにポリシーをスキップするには、拒否するポリシーを最初に評価されるランクに配置します。
Databricksでは、処理の遅いモデルベースのチェックが並列処理されるため、サービスに複数のブロッキングガードレールを積み重ねても、そのレイテンシが乗算されることはありません。
次の図は、2つのフェーズがサービスの周囲にどのように配置されているか、そして各決定が何をするかを示しています。
特定のサービスにアタッチされているポリシーとその実行順序を確認するには、サービスの[ ポリシー ]tabを開き、[ 実行フローを表示 ]をクリックします。
組み込みサービスポリシー
Databricks は、system.ai 名前空間の下で組み込みのサービスポリシーを提供します。これらは、カスタム SQL を使用せずに一般的なガバナンスシナリオをカバーします。Databricks AI ガードレール は、組み込みのサービスポリシーです。これは、カスタムポリシーと同じ方法でアタッチできる、事前構成済みの Databricks 管理ポリシー（安全でないコンテンツやジェイルブレイクの検出など）です。
system.ai.block_unsafe_content: 安全でない、または有害なコンテンツを含むインタラクションを拒否します。system.ai.block_jailbreakモデルの安全指示を回避しようとするリクエストを拒否します。system.ai.block_hallucination：ハルシネーションを含む応答を拒否します。system.ai.detect_sensitive_data：構造化された機密データ（クレジットカード番号や社会保障番号など）を検出し、インタラクションをブロックするか、一致した値を編集（redact）します。他とは異なり、これは決定論的（パターンベースであり、評価器モデルを使用しない）であり、ブロックするだけでなく編集（redact）も可能です。サービスポリシーによる機密データの検出を参照してください。
組み込みポリシーを使用するには、それをサービスにアタッチします。ターゲットサービス上でMANAGEが必要です。
組み込みのポリシーは Databricks によって管理されており、Catalog Explorer の system.ai スキーマで参照できる関数としては表示されません。サービスポリシーの作成とアタッチで説明されているように、Unity Gateway UI を使用して名前で選択し、アタッチします。
組み込みサービス ポリシーの仕組み
組み込みサービスポリシーはLLM-as-a-judgeチェックであり、それぞれがDatabricksがキュレートするプロンプトを評価者モデルに対して実行し、コンテンツがポリシーに違反するかどうかを判断します。
評価者モデルサービス
各組み込みサービスポリシーは、コンテンツを判定するモデルである 評価器モデルサービス 上でプロンプトを実行します。Databricksによってdefaultの評価器が事前選択されるため、セットアップは不要です。別のモデルを使用するには、ポリシーをアタッチするときに 詳細オプション を展開して選択します。選択したモデルサービスに対するEXECUTEと、そのカタログおよびスキーマに対するUSE CATALOGおよびUSE SCHEMAが必要です。モデルサービスへのアクセスを許可するを参照してください。Databricksはポリシーのアタッチ時にこのアクセスを確認するため、保護されたサービスの呼び出し元が評価器へのアクセス権を持つ必要はありません。評価器は保護しているサービスとは別個のものであるため、ポリシーでは、評価器として別のモデルを使用して、1つのモデルサービスへのリクエストを評価できます。
Databricksは、読み取り専用であるポリシーのプロンプトを管理しています。評価者が適用する正確な基準を確認するには、ポリシーをアタッチした際に プロンプト の下でご覧いただけます。
評価器が受け取るもの
組み込みサービスポリシーが実行されると、Databricksは評価器に2つの部分からなるリクエストを送信します：機会
- ポリシープロンプトと出力コントラクト（次のセクションで説明）を含む システムメッセージ 。
- 評価対象コンテンツを含む ユーザーメッセージ 。入力フェーズでは、モデルまたはモデル・プロバイダー・サービスに対する最新のユーザーメッセージと、直近の会話ターンの一部（下記参照）、またはMCPサービスに対するツール呼び出しとその引数です。出力フェーズでは、モデルの応答です。
評価者は画像や音声コンテンツを確認できません。出力フェーズおよびMCPサービスでは、その抽出された1つの項目のみを判定します。
モデルおよびモデルプロバイダーのサービスの入力フェーズでは、評価者は直近の会話のやり取りのウィンドウも受け取るため、段階的なエスカレーションなど、会話全体で蓄積されるパターンを検出できます。ポリシーフォームでポリシーを作成すると、 会話ウィンドウ はdefaultで直近10ターンに設定されます。数を変更して、1に設定すると最新のメッセージのみを判定できます。または、 会話全体を評価 を選択します。会話ウィンドウが設定されていないポリシーでは、最新のメッセージのみが判定されます。
出力コントラクト
DatabricksはポリシープロンプトにJSON出力コントラクトを自動的に追加するため、評価者はフリーテキストではなく構造化された決定を返します。評価者は以下を返します。
flagged(Boolean)：コンテンツがポリシーの基準に違反している場合はtrue。confidence（浮動小数点数、0.0～1.0、オプション）：評価器がその決定に抱く信頼度。reason（文字列）：コンテンツにフラグが立てられた理由の短い説明。flaggedがtrueの場合に返されます。
評価者がflagged: trueを返した場合、Databricksはdefaultでそのインタラクションをブロックします。MCPサービスにおいて、承認を求めるように構成されたポリシーは、ツールがランする前に人間による承認のためにリクエストを一時停止します。Databricksが契約を自動的に適用するため、組み込みのサービスポリシーにはフェーズとランク以外の構成は必要ありません。
OpenJev 評価器はこの契約を使用しません。代わりに flag-or-allow の質問に回答し、reason を返しません。OpenJev を評価器として使用するをご覧ください。
評価器はモデルであるため、その判定結果は非決定論的であり、reasonは構造化データではなく短い自由テキストです。リクエストに対してどのポリシーがランされ、それぞれがどう判定したかを確認するには、統一トレーステーブルを使用します。また、ジャッジのconfidenceとそれが評価した正確なコンテンツを確認するには、評価器モデルサービスで推論テーブルを有効にします。「ポリシー決定のデバッグと監査」を参照してください。
評価コスト
Databricksは、組み込みのサービスポリシーに対して別途料金を請求しません。各評価は、評価モデルサービスへの他の呼び出しと同様に課金されるため、コストはそのモデルが提供される方法によって異なります。各評価で課金されるトークンには、ポリシープロンプト、出力コントラクト、抽出されたメッセージ、および評価者の応答が含まれます。オーバーヘッドを制限するため、フェーズあたりのポリシー数を少なく保ち、低レイテンシの評価モデルを推奨します。
外部サービスポリシー
外部サービスポリシーは、AIセキュリティやデータ損失防止（DLP）サービスなどのサードパーティ製ガードレールベンダーの決定を強制します。これを External ガードレールタイプでアタッチし、ベンダーのEndpointとOAuthのマシン間認証情報を格納するUnity Catalog HTTP接続を指定します。Databricksは評価のたびに、評価対象のコンテンツをベンダーに送信します。ベンダーはALLOWまたはDENYを任意の理由とともに返し、Databricksはその結果を適用します。
ベンダーは Databricks 外部ポリシー API を実装する必要があります。外部サービスポリシーが返すのは ALLOW または DENY のみです。承認のために呼び出しを保留したり、コンテンツをマスクしたりすることはできません。これらはフェイルクローズするため、到達不能または低速なベンダーの Endpoint は呼び出しを拒否します。外部サービスポリシーによるパートナーガードールの適用をご覧ください。
サポートされているサービス
サービスポリシーは、以下のUnity Catalogのサービスセキュリティ保護可能オブジェクトにアタッチできます。
- MCPサービス：マネージド、外部、およびカスタムのMCPサーバー。
- モデルサービス：ホストされているLLMエンドポイントおよび外部LLMエンドポイント。
- モデルプロバイダーサービス：統制された外部モデルプロバイダー。
フェイルクローズド動作
サービスポリシーの評価では、fail-closedセマンティクスが使用されます。Unity Gatewayを介してポリシーをアタッチすると、Databricksはアタッチ時にそれを検証し、評価中のエラーはDENYとなります。ポリシー機能におけるユーザー エラー、システム エラー、リクエスト コンテキスト内のフィールドの欠落、タイムアウトなどがエラーに含まれます。外部サービス ポリシーの場合、エラーには、到達不能なベンダー Endpoint、エラーを返すベンダー Endpoint、または ALLOW や DENY 以外の判定を返すベンダー Endpoint も含まれます。
誤って設定された、または破損したポリシーは、インタラクションを通過させるのではなくブロックします。
A ポリシー in Log mode is non-enforcing.It records what the policy would have decided without blocking the interaction, so even a would-be DENY lets the request proceed.Request validation still applies, including request-タグ validation.
制限事項
次の制限が適用されます：
- Transformation ：サービスポリシーは決定（ALLOW、DENY、または ASK）を返しますが、リクエストまたはレスポンスの内容は変換しません。唯一の例外は、モデルサービス上で一致した値を非編集（またはマスク）できる組み込みの
system.ai.detect_sensitive_dataポリシーです。 - 外部サービスポリシー : 外部サービスポリシーは
ALLOWまたはDENYのみを返し、OAuth マシン間認証のみをサポートします。外部サービスポリシーの制限事項を参照してください。 - サポートされているサービス : サービスポリシーは、MCPサービス、モデルサービス、モデルプロバイダーサービスに適用されます。エージェントサービスはサポートされていません。
- モデルプロバイダーサービスのパススルー ：モデルプロバイダーサービスにおいて、Databricks はパススルーリクエストに対してサービスポリシーを評価しません。これは、 すべての URL パスの転送 を有効にすると、Unity Gateway が変更せずにプロバイダーに転送するものです。ポリシーは、プロバイダーのサポートされている API パスにのみ適用されます。
- 会話ウィンドウ ：モデルサービスおよびモデルプロバイダーサービスでの入力評価のみが、会話ウィンドウを使用できます。出力評価サービスおよびMCPサービスは、単一のメッセージまたはツール呼び出しを評価します。組み込みサービスポリシーの仕組みをご覧ください。
- ネストされた評価：組み込みサービスポリシー用に選択した評価モデルサービスに独自のポリシーがアタッチされている場合、Databricksは評価の実行時にそれらをスキップします。これにより再帰が防止されます。