Databricksの「組み合わされるまでは無害」ポリシー、結合点でエージェントリスクを阻止

Databricksは、個別には通常の能力である3つが危険な連鎖を形成した場合にのみエージェントをブロックする、新たなOmnigentのセキュリティパターンを公開した。Databricksの「組み合わされるまでは無害」というアプローチは、プライベートデータ、信頼できないコンテンツ、外部通信が1つのセッション内で利用可能になる瞬間を対象とする。

この組み合わせは「致命的な三要素」として知られる。エージェントは、内部ファイルの読み取り、公開Webページの確認、メッセージ送信を、それぞれ単独で行う限り安全に実行できる可能性がある。しかし3つの能力を1つの実行経路にまとめると、注入された指示によって正当なアクセスがデータ窃取へと転じうる。

重要な変化は、プロンプトインジェクションに関する新たな警告ではない。Databricksは、実施判断をモデルの外部に移し、エージェントの実行と統制のためのオープンソースのメタハーネスであるOmnigentに置いている。ポリシーレイヤーはセッション内で何が起きたかを記憶し、その後のアクションの扱いを変える。

静的な権限は、エージェントがツールを呼び出してよいかを問う。コンテキストポリシーは、その呼び出し以前に何が起きたかも問う。この違いは、コーディングエージェント、ブラウザエージェント、Model Context Protocol連携を通じて、広範かつ永続的なツールアクセスを利用するチームに課題を突きつける。

DatabricksがOmnigentで変えたこと

Databricksは、エージェントの履歴を実効的な権限セットの一部として扱っている。

同社のセキュリティケーススタディは、Omnigentのコンテキストポリシーに関する一連の投稿を拡張するものだ。以前の例では、セッション状態、時間をかけて進行する攻撃、ユーザーの当初の意図に結び付いた認可に焦点が当てられていた。

最新の例では、そのモデルを致命的な三要素に適用している。セキュリティ研究者のSimon Willisonは2025年6月、このパターンを、プライベートデータへのアクセス、信頼できないコンテンツへの露出、外部通信チャネルの組み合わせとして定義した。彼の脅威モデルは、3つを組み合わせることで、注入された指示に情報窃取の経路を与えると警告している。

Omnigentは、モデル、ツール、実行ループを管理するランタイムであるエージェントハーネスの上位に位置する。このプロジェクトは既存のコーディングエージェント環境とカスタムエージェントをサポートし、それらの活動を共通のポリシーレイヤーで監視できるようにする。

この位置付けは重要だ。なぜなら、ポリシーは基盤となるモデルにすべての悪意ある表現を認識させる必要がないからである。セッション中に記録された事実に基づいてツール利用を統制できる。

たとえば、内部の製品文書をレビューするよう依頼されたエージェントを考えてみよう。その文書を読むことは想定された行為だ。承認済みの要約を社内チャネルに送ることも想定されるかもしれない。

しかし、エージェントが隠れた指示を含む公開Issue、Webページ、またはリポジトリを訪れたとする。その後の外部向けリクエストは、セッションが別の信頼境界を越えたため、異なるセキュリティ上の意味を持つ。

従来の許可リストは、ワークフロー全体を通じて同じ承認済みツールを認識する。コンテキストポリシーは、時間の経過とともにリスクが変化した一連の行為を認識する。

Omnigentのポリシーは、allow、ask、denyの判断を返せる。allowはアクションを許可し、askは人に判断を委ね、denyはブロックする。したがって、セッションが機密アクセスや危険なイベントを蓄積するにつれ、応答をより厳格にできる。

この実施モデルでは、すべてのソース、ツール、アクションが単独で危険である必要はない。代わりに、ポリシーは安全でないデータ経路を生む組み合わせを監視する。

Databricksはまた、ワークスペースのIDとモデルサービスに接続したマネージドベータ版としてOmnigentを提供している。そのマネージドデプロイメントは現在、組み込みのコンテキストポリシーハンドラーをサポートしている一方、任意のカスタムポリシー関数は利用できない。

この制約は、オープンソースの設計とマネージド製品を分けるものだ。この発表を評価するチームは、実証されたポリシーパターンと、選択したデプロイメントで利用できる制御機能を区別する必要がある。

それでも中心的な変化は明確だ。エージェントの認可は、ログイン時やツール登録時に固定されるのではなく、セッションに依存するものになりつつある。

Databricksの「組み合わされるまでは無害」がセキュリティ境界を変える理由

危険な対象はもはや単一のツール呼び出しではなく、複数の許可された呼び出しを結ぶ経路である。

従来のアクセス制御は、ID、リソース、アクションを評価する。サービスアカウントは、あるデータベースを読み取り、あるバケットに書き込み、あるAPIを呼び出せる。エージェントも通常の認証情報を通じて動作するため、こうしたルールは依然として必要だ。

しかし、信頼できない言語がそれらの認証情報の使い方に影響を与える場合、それだけでは十分ではない。攻撃者はトークンを盗んだり、アプリケーションコードを悪用したりする必要がないかもしれない。攻撃者に必要なのは、データにアクセスでき、外部で行動できるモデルに悪意あるコンテンツを到達させることだけだ。

第1の要素はプライベートデータである。このカテゴリには、内部文書、ソースコード、認証情報、顧客記録、メール、データベースの結果、そして攻撃者の認可範囲外にあるあらゆる情報が含まれる。

第2の要素は信頼できないコンテンツである。Webページ、サポートチケット、プルリクエスト、メール、共有ファイル、ツール応答、画像には、エージェントの信頼境界の外部にいる人物が制御する指示が含まれうる。

第3の要素は外部通信である。メールやHTTPリクエストは明白な例だが、このカテゴリはより広い。コメントの投稿、コードのプッシュ、リモートリソースの読み込み、共有システムへの書き込みは、いずれも外部送信チャネルを作りうる。

これらの能力はいずれも珍しいものではない。その有用性こそが、この組み合わせが非常に多くのエージェント設計に現れる理由である。

リサーチエージェントには外部ソースと内部コンテキストが必要だ。コーディングエージェントはプライベートリポジトリを読み、公開ドキュメントを参照し、ブランチをプッシュすることがある。メールアシスタントは信頼できないメッセージを読み、プライベートな通信履歴を検索し、返信を送る。

いずれかの能力を恒久的に取り除くと、エージェントの有用性を大幅に損なう可能性がある。常時承認を求めるプロンプトは、ユーザーが定型的な要求を受け入れることに慣れてしまうため、別の問題を生む。

Databricksの「組み合わされるまでは無害」という枠組みは、別の選択肢を提示する。低リスクの操作は進めつつ、セッション状態が禁止された組み合わせを完成させた場合にエスカレーションする。

これにより、セキュリティ境界は個々のコネクタからワークフローへと移る。ブラウザは単純に信頼できる、あるいは信頼できないものではない。同じセッションが機密情報と外部送信経路も保持しているかどうかによって、その重要性は決まる。

このモデルは、システムが異なる信頼レベル間でデータがどのように移動するかを追跡する情報フロー制御に似ている。機密情報がコンテキストに入ると、保護レベルの低い宛先へのその後の書き込みは、より厳格に扱われる。

Omnigentが公開しているポリシーカタログには、すでに関連するGoogle Drive制御が含まれている。セッションが宣言された機密ファイルを読み取ると、ポリシーは機密セット外への書き込みを防止できる。

このカタログにはリスクスコアポリシーも含まれている。ツール呼び出しと機密データラベルからポイントを蓄積し、設定された閾値を超えると保護対象ツールをエスカレーションする。

これらの例は、なぜ状態が中心的なのかを示している。エージェントが機密文書を読んだ後でも、書き込みリクエストのAPI形式は変わらない。その意味が変わるのは、セッションの履歴による。

同じ原則が致命的な三要素にも当てはまる。ポリシーが探しているのは、普遍的に禁止される操作ではなく、危険な組成である。

この区別は、もう1つのプロンプトフィルター以上に、プラットフォームチームの関心を引くべきだ。フィルターは、テキストが悪意あるものに見えるかを判断しようとする。コンテキストに基づく実施は、モデルやフィルターがインジェクションを特定できなかった場合でも、安全でないアクションをブロックできる。

静的な権限では連鎖を捉えられない

静的な許可リストは利用可能な能力を説明できるが、エージェントがどのようにそのアクションに至ったかは説明できない。

開発者がエージェントに、プライベートリポジトリの読み取り、ドキュメントの閲覧、プルリクエストの作成を許可したとする。それぞれの権限は通常のコーディングワークフローを支える。

その後、攻撃者がIssue、依存関係ドキュメント、または取得されたWebページ内に指示を埋め込む。その指示は、秘密情報を収集し、公開プルリクエストの説明に含めるようエージェントに求める。

リポジトリの読み取りは許可されている。Web取得も許可されている。プルリクエストの作成も許可されている。各リクエストを独立して評価する制御は、連鎖全体を承認しかねない。

コンテンツフィルターがその指示を検出する可能性はある。しかし、間接的な要求、エンコードされたデータ、なじみのない言語、または対象モデル向けに設計されたペイロードを見逃す可能性もある。

研究は、モデルの振る舞いだけに頼ることへの警戒を支持している。WASPベンチマークは、複数のモデルとスキャフォールドを使用し、Webエージェントシステムに対する現実的なプロンプトインジェクション攻撃をテストした。

研究者らは、テストした構成全体で、エージェントが敵対的な指示の実行を開始する割合が16%から86%に及ぶと報告した。攻撃者によるエンドツーエンドの成功率はより低く、0%から17%の範囲だった。

この差は前向きな材料ではあるが、安心材料ではない。現在のエージェントは複雑な攻撃を完遂する前に失敗することが多いが、エージェントの信頼性が向上すれば、悪意あるワークフローも完了しやすくなりうる。

システムは、エージェントが適切な瞬間に混乱することを期待すべきではない。モデルの複数ステップ実行能力が高まっても有効な制御が必要だ。

静的な権限は、遅延型の攻撃にも対応しにくい。注入された指示が即座に外部向けアクションを引き起こすとは限らない。後の計画、委任タスク、生成ファイル、ツール呼び出しに影響を及ぼす可能性がある。

セッション対応ポリシーは、その遅延をまたいでセキュリティに関連する事実を保持できる。不審なイベントのすべてが、モデルのアクティブコンテキスト内で最終アクションの隣に存在する必要はない。

この永続性は、長時間動作するエージェントの実務的な弱点に対処する。会話履歴は圧縮、要約、またはワーカー間で分割されうる。ツールと認証情報が利用可能なままでも、モデルは以前の制約を忘れる可能性がある。

したがって、ポリシー状態はテキストウィンドウの外部に置くべきだ。実施レイヤーには、機密情報の読み取り、信頼できない入力、宛先、承認、リスク変化について、独自に永続する記録が必要である。

このアーキテクチャは、エージェントの自己申告への依存も減らす。モデルに信頼できないコンテンツに遭遇したかを尋ねるより、どのコネクタがコンテンツを提供したかを記録する方が強力である。

最も強いシグナルはインフラから得られる。文書システムはファイルの分類を把握している。ネットワークゲートウェイは宛先を把握している。IDレイヤーはユーザーとワークスペースを把握している。ツールブローカーはどの操作が要求されたかを把握している。

Omnigentは実行環境を包み込むため、これらのシグナルを組み合わせられる。エージェントはアクションを提案するが、記録されたコンテキストの下でそのアクションが依然として許容されるかどうかはポリシーが判断する。

ここが競合するエージェントプラットフォームにとっての圧力点だ。ツールレベルの承認は説明もしやすく、実装もしやすい。エージェントがより多くのコネクタにまたがって長時間のセッションを実行するようになると、その信頼性は低下する。

ベンダーは、自社の制御がツール間のデータと信頼の遷移を追跡できるかを示す必要がある。長大な権限リストは、もはや中心的なセキュリティ上の問いに答えない。

コンテキストポリシーはデータが流出する前に連鎖を断つ

有効な制御点は、通常、攻撃経路を完成させる遷移、すなわち機密情報の読み取りまたは外部向けアクションである。

コンテキスト対応ポリシーは、観測可能なイベントから始まります。これには、ツールの呼び出し、ツールの結果、データラベル、宛先、モデルへのリクエスト、ユーザー承認などが含まれます。

ポリシーは選択した事実をセッション状態に保存します。エージェントが信頼できないコンテンツを取り込んだ、機密オブジェクトにアクセスした、または承認済みの境界外との通信を試みた、といった記録を残す場合があります。

後続のイベントは、その状態に照らして評価されます。次の操作によって禁止された組み合わせが完成する場合、ポリシーは承認を求めるか、リクエストを拒否できます。

順序はさまざまです。エージェントは信頼できないページにアクセスする前に、非公開データを読み取るかもしれません。あるいは、まず注入されたコンテンツに遭遇し、その後で社内ファイルへのアクセスを要求する場合もあります。

堅牢な実装では、どちらの経路も検出しなければなりません。危険なのは、能力が1つの固定された順番で現れることではなく、それらが接続されることにあります。

強制は複数の地点で行うこともできます。信頼できないコンテンツがセッションに入った後、機密データの読み取りをブロックするポリシーもあります。別の設計では、分析は許可しつつ、その後の外部通信を防止できます。

外部への送信をブロックすれば、より多くのローカルな有用性を保てることがよくあります。エージェントは情報を公開する経路を得ないまま、読み取りや下書き作成を続けられます。ただし、送信制御は明白な送信機能だけを対象にしていては不十分です。

生成されたリンクにはデータを埋め込めます。リモート画像へのリクエストでは、クエリパラメータを送信できます。ソース管理へのプッシュ、Issueコメント、分析ツールへの呼び出し、共有ドキュメントへの書き込みはいずれも、信頼境界を越える可能性があります。

宛先のコンテキストも重要です。承認済みの社内チャネルに要約を送ることと、公開リポジトリに投稿することは異なります。すべての書き込みを同等に扱えば、不必要な中断が生じます。

コンテキストと宛先が明確であれば、人による承認には価値があります。有用なプロンプトは、セッションが機密データを読み取り、その後に信頼できないコンテンツを取り込み、現在は特定の外部エンドポイントへの接続を試みていることを説明すべきです。

一般的な「このツールを許可しますか」というメッセージでは、エスカレーションの理由が隠れてしまいます。レビュー担当者がワークフローを手作業で再構築しなければならず、承認疲れを招きます。

組織が決して受け入れない組み合わせには、明確な拒否が適しています。たとえば、公開コンテンツに接触したセッションが、制限付きデータセットの情報をその区画の外部へ送信することを防ぐポリシーを設定できます。

必要なコンテキストが欠けている場合、ポリシーエンジンは安全側に失敗しなければなりません。データラベルの欠落、未対応ツール、観測されないネットワーク経路は、盲点を生み出しかねません。

Omnigentのより広範なアプローチは、ポリシーとサンドボックスを組み合わせます。サンドボックスはOS境界でファイルシステムとネットワークへのアクセスを制限し、モデルが要求した場合でもエージェントが到達できる範囲を縮小します。

これらの層は異なる目的を果たします。サンドボックスは生の能力を制限します。コンテキスト対応ポリシーは、セッションに蓄積された状態に基づいて権限を調整します。

どちらも通常のID制御、コネクタ認可、ログ、データ損失防止に取って代わるものではありません。この発表は、そのスタック内の1つの強制レイヤーとして解釈するのが最も有益です。

OWASPのagentic security reportは、AIシステムに対する主要な攻撃手法としてプロンプトインジェクションを挙げています。より大きなメッセージは、エージェントのセキュリティには実行、ツール、ID、データ移動を取り巻く制御が必要だということです。

これはDatabricksのアーキテクチャ上の方向性を裏付けます。確率的なモデルは行動を提案できますが、その行動が許可されるかどうかは決定論的な境界が判断すべきです。

Databricksのポリシーで解決されない点

コンテキスト対応の強制は攻撃経路を狭めますが、その信頼性は完全な可視性と信頼できる分類に依存します。

最初の未解決の問題は、カバレッジです。ポリシーは観測できないチャネルをブロックできません。

エージェントは、コネクタ、シェルコマンド、ブラウザーリクエスト、埋め込みリソース、生成物を通じて通信する可能性があります。データを境界外へ移動させうるすべての経路をポリシーモデルに表現するか、別の方法で制約する必要があります。

2つ目の問題は分類です。システムは、どのコンテンツが信頼できず、どのデータが機密かを把握する必要があります。

単純なルールなら、公開Webページを信頼できないもの、名前付きドキュメントを機密として分類できます。企業環境には、共有ドライブ、請負業者のアカウント、コピーされたテキスト、生成ファイル、複数の低機密ソースから組み立てられたデータなど、より難しいケースが存在します。

偽陰性は危険な組み合わせを検出できないままにします。偽陽性は通常業務を中断させ、内容を確認せず警告を承認するようユーザーを慣れさせる可能性があります。

3つ目の問題は状態の範囲です。セッションは便利な単位ですが、情報はファイル、メモリストア、キャッシュ、サブエージェント、コピーされた要約を介してセッション間を移動できます。

あるワーカーが機密データを読み取り、別のワーカーが結果を送信する場合、セッション単位の追跡ではその複合フローを見逃す可能性があります。マルチエージェントシステムには、委任の際に関連ラベルを保持する伝播ルールが必要です。

4つ目の問題はポリシーの完全性です。強制レイヤー、設定、イベントストリームは、セキュリティ上重要なインフラになります。攻撃者はポリシーの隙間、不正なツールメタデータ、曖昧な宛先、フェイルオープン動作を標的にする可能性があります。

チームはモデルだけでなく、実際のポリシー境界をテストすべきです。敵対的評価には、代替の送信経路、遅延したアクション、エージェント間の転送、不完全なメタデータを含める必要があります。

5つ目の問題は使いやすさです。承認を頻繁に求める制御は、解決しようとした弱点を再現しかねません。

リスクベースのエスカレーションには、慎重に選んだしきい値と情報量の多いプロンプトが必要です。セキュリティチームは、承認頻度、拒否の精度、上書き率、ユーザーが例外を受け入れる理由を測定すべきです。

マネージドOmnigentベータには、もう1つ実務上の制約があります。Databricksは現在、マネージド環境では任意のカスタムポリシーコードではなく、組み込みハンドラーをサポートすると文書化しています。

特殊な分類や独自のコネクタを持つ組織は、利用可能なポリシーが十分なコンテキストを公開しているか確認すべきです。オープンソースの柔軟性が、そのままマネージドサービスの機能同等性につながるわけではありません。

また、1つのデモンストレーションを普遍的な検証として扱う根拠はまだありません。Databricksの記事は、セキュリティパターンと実装アプローチを説明しています。すべてのOmnigent構成がすべてのプロンプトインジェクション手法を阻止することを立証しているわけではありません。

正しい主張はより限定的です。セッション認識型の強制は、各ツールが個別には正当なままであっても、致命的な三つ組の経路を断ち切ることができます。

それでもなお意義があります。セキュリティアーキテクチャは、アプリケーションにあらゆる攻撃者メッセージを認識させるのではなく、攻撃に必要な条件を1つ取り除くことで成功する場合が多いからです。

最も強力な導入では、コンテキスト対応ポリシーを制限付き認証情報、宛先許可リスト、サンドボックス、監査ログ、独立したテストと組み合わせます。また、ポリシー定義をバージョン管理されたセキュリティコードとして扱います。

このモデルが有効かを示す3つのシグナル

次の試金石は、コンテキスト対応ポリシーが説得力のあるデモンストレーションではなく、測定可能なインフラになるかどうかです。

最初のシグナルは、ツールとエージェントハーネス全体にわたる、より広いカバレッジです。Databricksは、ブラウザー、コードリポジトリ、ドキュメントシステム、シェル、委任されたエージェントを含む一般的なワークフローで、セキュリティラベルとセッション状態が維持されることを示す必要があります。

機能リストにサポートが記載されているだけでは不十分です。異なるハーネスやコネクタ実装において、同等のアクションが同等に強制されるという証拠がチームには必要です。

一貫したカバレッジは、共有メタハーネスの根拠を強めます。ランタイム間に重大な差異があれば、エージェント全体に単一のガバナンスレイヤーを適用するという約束は弱まります。

2つ目のシグナルは敵対的評価です。Omnigentには、遅延したデータ流出、間接的な送信、セッション間転送、メタデータ操作を試みる再現可能なテストが必要です。

有用な結果では、検出、承認、拒否、データ移動の成功を分けて示すべきです。また、すべてのワークフローをブロックするポリシーは安全でも使えないため、通常タスクの完了状況も報告すべきです。

公開テストフィクスチャがあれば、セキュリティチームは自らの構成に対して結果を再現できます。独立した評価は、ベンダーが選んだシナリオよりも重みを持ちます。

3つ目のシグナルは、マネージドDatabricks環境内での運用導入です。ポリシーサポートの拡大、より明確なテレメトリ、管理制御、企業のデータ分類との文書化された統合に注目してください。

導入は測定可能な成果を生むべきです。チームは、ポリシーがどの程度の頻度で発動するか、どの能力の組み合わせがエスカレーションを引き起こすか、レビュー担当者が判断を覆すか承認するかを把握する必要があります。

これらのシグナルが重要なのは、根底にあるセキュリティ問題がエージェントの有用性とともに拡大するためです。より優れたエージェントは、常時の監督なしに、より長いタスクを完了し、より多くのツールを使い、より多くの信頼境界を越えるようになります。

Databricksの「組み合わされるまでは無害」というアプローチは、信頼できる設計原則を示しています。つまり、有用なコンポーネントを許可しながら、危険な組み合わせをブロックすることです。焦点を、モデルが攻撃を理解しているかどうかから、周囲のシステムが攻撃の完遂を許すかどうかへ移します。

開発者は、どのセッションが非公開データにアクセスでき、攻撃者が制御するコンテンツを取り込み、外部と通信できるかを整理すべきです。企業の購入担当者は、プラットフォームがそれらの条件を時間、ツール、委任されたワーカーにまたがって追跡するかを問うべきです。

この3つすべてがコンテキスト対応の強制なしに利用可能なままであれば、洗練された承認画面では問題は解決しません。実務上の次のステップは、各ワークフローで3つ目の能力がどこで加わるかを特定し、その境界にテスト可能なポリシーを配置することです。