Databricks上のAIエージェントに対するプロンプトインジェクションのリスクを軽減する

概要

2024年にDatabricks AIセキュリティフレームワーク（DASF）をリリースして以来、AIに対する脅威の状況は劇的に変化しました。AIは、典型的なチャットボットから、ほとんど、あるいはまったく介入なしで、ユーザーに代わって推論し、ツールを使用し、アクションを実行できるエージェントへと変貌を遂げました。セキュリティチームは、もはやユーザーとモデルのインタラクションについて考えるだけでなく、自律的に行動し、MCPを介してサービスとインタラクションし、独自にインターネットを探索するインテリジェントエージェントの群れについても考える必要があります。

プロンプトインジェクションは推論時代には既知のリスクでしたが、その影響は主にユーザーのリクエストとレスポンスに限定されていました。自律的にアクションを実行できるエージェントの登場により、リスクは指数関数的に増加しています。

サードパーティのAPIを呼び出すスクリプトを作成するタスクをAIエージェントに課すデータ専門家を考えてみましょう。エージェントはインターネットでドキュメントを検索し、コードを作成してランします。ユーザーが気づいていないのは、そのドキュメントページには悪意のあるプロンプトが埋め込まれており、それがエージェントにユーザーのコンピュート環境からWebhookに認証情報を漏洩させるよう指示していたことです。このような攻撃は、実際には十分に文書化されています。しかし、それらがいつ、なぜ成功するのかを推論するのに役立つフレームワークがあります。

Metaの「Agents Rule of Two」やSimon Willisonの「Lethal Trifecta」のような類似モデルを含む最近の業界調査では、プロンプトインジェクション攻撃が成功する条件が明らかにされています。これらのパターンは、Databricks AIセキュリティフレームワーク（DASF）で定義されている制御と密接に一致しており、これはエンタープライズデータ上で動作するAIエージェントを保護するための実用的なモデルを提供します。

両者は同じ結論に至ります。AIエージェントは、以下の3つの特性をすべて備えている場合にプロンプトインジェクションに対して脆弱になり、リスクを軽減するためには、そのうちの2つのみを許可する必要があります。

• 機密システムまたはプライベートデータへのアクセス
• 信頼できない入力へのエクスポージャー
• 状態を変更したり、外部と通信したりする機能

実際には、これらのリスクは、データアクセス、モデルとのインタラクション、運用の実行にわたってAIセキュリティを体系化するDatabricks AIセキュリティフレームワーク（DASF）で定義されている多層防御コントロールに直接マッピングされます。以下のセクションでは、Databricks Platform上のネイティブコントロールを使用してこれらのリスクを軽減する方法を示します。

AIエージェントのコアリスクを理解する

概要で述べたように、Metaの「エージェントの2つのルール」フレームワークは、AIエージェントをプロンプトインジェクションに対して脆弱にする中核となる柱を分析するのに役立ちます。

1. 機密システムまたはプライベートデータへのアクセス：エージェントは、機密性の高いユーザーデータを読み取ったり、操作したりできます。
2. 信頼できない入力を処理する: エージェントは、外部または攻撃者が制御するソースから提供されたコンテンツを消費する可能性があります。
3. 状態の変更または外部との通信：エージェントは、HTTPリクエストの作成や外部システムの変更など、ローカル環境の外部でアクションを実行できます。

3つの柱がすべて存在する場合、システムはすでに機密システムまたはプライベートデータにアクセスしており（第一）、攻撃者は信頼できない入力を介して悪意のある命令を注入し（第二）、エージェントがそのデータを外部に持ち出す（第三）ことができます。このセクションでは、これらがそれぞれ Databricks のコンテキストでどのように適用されるかを見ていきます。

柱 1: 機密システムまたはプライベートデータへのアクセス

攻撃者が価値のあるものを外部に送信するには、まずエージェントがそれにアクセスする必要があります。これは「エージェントの2つのルール」の第一の柱であり、実際にはほとんどの場合、不可欠です。エージェントが最も役立つのは、現実の価値の高いデータを扱えるときです。顧客からのフィードバックに対する感情分析、需要予測、不正検出、コード支援といったタスクに、エージェントの利用が増えています。これらのエージェントが効果的に機能するためには、顧客記録、取引履歴、専有文書、または大規模な内部コードベースへのアクセス権が意図的に付与されます。言い換えれば、組織に競争上の優位性をもたらすデータこそ、攻撃者が最も関心を寄せるデータでもあるのです。

統合データおよびインテリジェンスプラットフォームとして、Databricksは組織の最も価値のあるデータセットを一元化して処理するように設計されています。プラットフォーム上で実行されるアプリケーションとエージェントは、設計上、機密情報の近くで動作しています。これは、多くの実際のデプロイメントにおいて、「Agents Rule of Two」の第一の柱は、仮説的な懸念として扱われるのではなく、存在するものと想定されるべきであることを意味します。

柱 2: 信頼できない入力の処理

Agents Rule of Twoの第2の柱は、信頼できないデータがどのようにシステムに入るかに焦点を当てています。最も単純なケースでは、このリスクは明らかです。LLMチャットインターフェースは、悪意のある指示を含むユーザー入力を直接受け入れることができます。これは直接的なプロンプトインジェクションであり、攻撃者はインタラクションの一部としてペイロードを明示的に提供します。

しかし、リスクは直接的なユーザー入力だけにとどまりません。エージェントとLLM搭載アプリケーションは、データベース、ドキュメント、API、ナレッジベースなどの外部ソースからデータを取得して処理することがよくあります。このような場合、悪意のある命令が、一見正当なコンテンツ内に埋め込まれており、エージェントがそのデータを読み取ったり推論したりしたときにのみ表面化することがあります。これが間接的なプロンプトインジェクションです。最新の LLM は自然言語、構造化データ、特殊文字、画像、エンコードされたペイロードなど、幅広い入力を解釈するように設計されているため、課題はさらに複雑になります。この多様性により、従来の入力検証技術を使用して悪意のある命令を検出することが困難になります。

Databricksプラットフォームでは、データソースの多様性により、これは特に関連性が高くなります。1つのUnity Catalogテーブルには、注文管理システムからのトランザクションレコード、スタッフと顧客間のサポート会話、またはWebフォームを介して送信された製品フィードバックが含まれている場合があります。エージェントにそのデータへのアクセスが許可された場合、シンプルでありながら重要な質問をすることが重要です。このデータのいずれかの部分が外部のアクターによって影響を受けた可能性はありますか？

答えが「はい」の場合、Agents Rule of Twoの第2の柱はすでに整っています。

実際には、この評価はめったに単純ではありません。多くの場合、データを元のソースまで遡って追跡し、悪意のある指示が埋め込まれる可能性のある、コメント、フリーテキストフィールド、メタデータ、添付ファイルなどのあまり目立たないインジェクションポイントを考慮する必要があります。通常のビジネスデータに見えるものも、エージェントの観点から見ると、実行可能なガイダンスである可能性があります。

第三の柱：状態の変更または外部との通信

「エージェントの2つのルール」の最後の柱は、エージェントに実際に許可されていること、ひいては攻撃の影響範囲がどれほど大きくなり得るかに焦点を当てています。初期のLLMアプリケーションでは、モデルは実質的に読み取り専用でした。ユーザーがプロンプトを提供し、モデルが応答を生成し、その応答がただ表示されるだけでした。攻撃者がモデルの出力に影響を与えたとしても、モデルにはプライベートなランタイムデータへのアクセスやアクションの実行能力がなかったため、その影響は一般的にユーザーに表示されるテキストに限定されていました。

現代のエージェントは根本的に異なります。これらはもはやテキストの生成に限定されず、Pythonコードの実行やSQLクエリーの実行といったアクションを通じて状態を変更したり、APIsを呼び出したり、モデルコンテキストプロトコル（MCP）などのメカニズムを介してシステムと対話したりすることで、外部と通信することもできます。

Databricksプラットフォームでは、AI機能を搭載して構築されたエージェントを、MCPサーバー、ユーザー定義関数、または外部APIに簡単に接続できます。設計フェーズでは、これらのツールの意図された使用法だけでなく、その潜在的な誤用についても考慮することが重要です。ツールがエージェントに外部との通信やテーブルの上書きを許可する場合、「エージェントの2つのルール」の最後の柱が有効になります。

他の柱と同様に、エージェントの能力の全体像を把握することは必ずしも容易ではありません。一見無害に見えるツールでも、予期しない方法で使用される可能性があります。そのため、開発者は、エージェントが実行するように設計されたタスクだけでなく、敵対的な影響下で何ができるかという意味で、実質的な能力の観点から考える必要があります。

考察

個別に見ると、3つの柱はそれぞれ管理可能に見えるかもしれません。エージェントが機密データにアクセスできなければ、プロンプトインジェクションの懸念は小さくなります。エージェントがデータに基づいて行動する能力を持たない場合、機密データへのアクセスはそれほどリスクになりません。そして、エージェントが信頼できる入力のみを処理するのであれば、強力なツールも危険性は低くなります。これらの要因が重なり合うと、リスクは重大なものになります。そのような状況下では、攻撃者はエージェントの意図された用途を超えてその行動に影響を与え、一見すると日常的なやり取りを、現実世界に影響を及ぼすセキュリティインシデントに変えてしまう可能性があります。

防御の観点から、これは私たちに実用的な設計原則を与えてくれます。つまり、3つの柱を分断することです。ほとんどの現実世界のAIアプリケーションでは、いずれか1つの要素を完全に取り除くことは困難です。エージェントが有用であるためには、データが必要であり、多様な入力を処理する必要があり、多くの場合、タスクを自動化するためのツールが必要です。それでも、各柱に関連するリスクを封じ込めるための具体的な方法があります。

多くの AI プラットフォームでは、これらのリスクは、ID システム、ネットワーク制御、モデルゲートウェイ、データガバナンスソリューションにまたがる場当たり的なツール群によって対処されています。Databricksは異なるアプローチを取ります。データ、AI モデル、アプリケーションは Unity Catalog と Agent Bricks によって管理される統合プラットフォーム上で実行されるため、組織は、新たなセキュリティサイロを生み出すことなく、データアクセスからモデルのインタラクション、ランタイム実行に至るまで、AI システム全体にわたって階層的な制御を適用できます。

Databricks プラットフォームはこれらの各レイヤーでコントロールを提供しており、これについては以降のセクションで、新しい AI エージェントである Social Gauge という実例を使って見ていきます。

柱別のAIエージェントにおけるプロンプトインジェクションのリスクに対する制御

プロンプトインジェクションを緩和する最も効果的な方法は、3つの柱の1つを完全に取り除くことである、という点は今でも変わりありません。しかし実際には、ほとんどのエージェントは、機密データへのアクセス、外部入力への接触、行動を起こす能力という3つの要素すべてをある程度必要とします。そのため、柱を取り除く代わりに、それぞれを強化してアタックサーフェスを縮小することが目標となります。

ここでは、実行例としてSocial Gaugeを使用して、3つの柱すべてにわたる9つのコントロールを順に説明します。Social Gaugeは、ソーシャルメディアやニュースソースからデータを取得し、そのデータをUnity Catalogによって管理されている既存の顧客レコードと組み合わせる、Databricks Appに組み込まれたエージェントです。製品の発売に関するセンチメントを追跡するマーケティングチーム、四半期ごとのカバレッジを統合する財務チーム、通信社のサービスをモニタリングするニュースルームなどを考えてみてください。このウォークスルーでは、Social Gaugeを使用して新製品に関するユーザーのセンチメントを追跡する小売顧客に焦点を当てます。

その文脈を踏まえ、3つの柱のそれぞれを検討するにあたり、次の攻撃シナリオを念頭に置いてください。

1. Social Gaugeは、その意図された用途に必要な範囲を超えて、機密性の高い財務データにアクセスできます。
2. 悪意のある指示を埋め込んだプロンプトインジェクションを含むソーシャルメディアの投稿が取り込まれます。
3. これらの指示は、エージェントに対し、範囲外の財務データを取得し、外部に漏えいさせるか、あるいは下流の意思決定に影響を与えるために内部スキーマ内でデータを変更するように指示します。

各セクションで説明する制御は、さまざまな段階でこの攻撃チェーンを遮断、緩和、または監視するように設計されています。

第1の柱：機密システムまたはプライベートデータへのアクセス - コントロール

この柱はほぼ避けられません。エージェントが役立つのは、まさに実際のデータ上で動作するからです。Social Gaugeは、「1月の製品売上が落ち込んだ理由はありますか？」といった質問に答えるために、Unity Catalogを通じて顧客レコードをクエリーする必要があります。顧客のセンチメントと何か関係がありますか？」そのアクセスがなければ、エージェントは真の知見を提供できません。

我々の攻撃シナリオでは、第一の柱のリスクは、Social Gaugeがその意図された用途に必要な範囲を超えて財務データにアクセスできることであり、これによりエージェントは、この範囲外のデータを取得するように指示する間接的なプロンプトインジェクションに対して脆弱になります。この柱を排除することはできないため、リクエストを行うユーザーに関連するデータのみにSocial Gaugeのアクセス範囲を限定し、制約したいと考えます。

Databricksは、AIエージェントがUnity Catalogを介して管理されたエンタープライズデータ上で直接操作するため、このリスクを軽減する上で独自の立場にあります。これにより、組織は、人間のユーザーとAIエージェントの両方にわたって、きめ細かいアクセス制御、ポリシー適用、およびデータ保護メカニズムを一貫して適用できます。

ユーザー代理認証:
AIエージェントとのインテグレーションを構築する際、顧客はDatabricks APIsに対してユーザー代理（OBO）認証を使用することを選択できます。これは、基盤となるSDKがデータにアクセスするために呼び出されると、エージェント自体に関連付けられたサービスプリンシパルではなく、エージェントと対話しているエンドユーザーの権限が使用されることを意味します。

これは、あらゆるAIアプリケーションを構築する際の最初のステップであるべきです。これにより、権限が本質的に制限され、過剰な権限を持つエージェントが単一の侵害ポイントになるのを防ぎます。

Unity Catalog - 詳細なアクセス制御リスト:
OBO 認証が効果を発揮するためには、顧客は Unity Catalog で詳細なアクセス制御リストを設定し、どのユーザーやワークスペースもアクセスすべきでないデータにアクセスできないようにする必要があります。

保護可能なオブジェクトに対する権限は、ほとんどの顧客がよくご存知のアクセス制御です。これらは、Unity Catalog の保護可能なオブジェクト（カタログ、スキーマ、テーブル、ボリュームなど）に対してユーザーが実行できるアクションを規定します。多くの顧客にとって、これらの設定はガバナンス戦略の一環としてすでに導入されています。権限管理の詳細については、Unity Catalog のベストプラクティスに関するドキュメントをご覧ください。

Unity Catalog - 属性ベースのアクセス制御 (ABAC):
きめ細やかなアクセス制御は、ユーザーがデータエンジニア、アナリスト、ビジネスユーザーなどの明確に定義されたグループに分類される場合にうまく機能します。しかし、さまざまな事業部門で働くビジネスユーザーや、異なる地域に拠点を置くユーザーについてはどうでしょうか？そこで ABAC の出番です。

ABACでは、一度定義したポリシーをカタログ、スキーマ、テーブルなどに横断的に適用できます。ポリシータイプは 2 種類あります。行フィルターポリシーは、ユーザーの属性に基づいてテーブルを自動的にフィルターします。たとえば、ユーザーがEMEAを拠点としている場合、テーブルはその地域のレコードのみに縮小されます。列マスクポリシーは、ユーザーが特定のグループに属していない限り機密性の高い列をマスクし、PIIの漏えいを減らすための簡単な方法を提供します。

AI ガードレール - PII 検出:
上記の制御は、誰が何にアクセスできるかを制限することに重点を置いています。しかし、エージェントによって実際に何が返されるかを監視することも同様に重要です。多くの顧客が、AIアクセス用の中央ガバナンスレイヤーとしてMosaic AI Gatewayを利用しています。AI Gatewayは、統合モデルアクセス、ルーティング、使用状況の追跡、レート制限に加え、PII検出のようなガードレールを提供し、モデルの入出力のどこに現れてもセンシティブなデータを自動的にブロックまたはマスキングします。これにより、エージェントが操作されて、本来表示すべきでないデータを表示してしまうようなシナリオから保護します。

概要: 機密システムまたはプライベートデータへのアクセスに関する制御
これらの制御を導入することで、Social Gauge のエクスポージャーは根本的に異なります。たとえプロンプトインジェクション攻撃によってエージェントが操作されたとしても、エージェントは、要求元ユーザーがすでにアクセス権を持ち、そのリージョンにスコープが限定され、機密性の高い列はマスクされ、出力時にPIIが監視されるデータにしかアクセスできません。エージェントを侵害した攻撃者は、万能の鍵を手に入れるわけではありません。ドアを監視する警備員がいる状態で、単一ユーザーの権限を継承するだけです。

第2の柱：信頼できない入力の処理 - コントロール

Databricksは、MFAを使用したSSO、コンテキストベースのイングレス制御、フロントエンドPrivateLink、IP ACLなど、不正な外部ユーザーへの露出を軽減する多くのプラットフォーム制御を提供しています。しかし、信頼できない入力にさらされるリスクは、ログイン画面で終わりではありません。

Social Gaugeの中核機能は、消費者向け製品に関するソーシャルメディアの投稿やニュース記事をインターネットで検索することです。その機能は、間接的なプロンプトインジェクション、つまり一見正当なウェブコンテンツに埋め込まれた悪意のある指示に対して脆弱になります。したがって、未承認のユーザーはSocial Gaugeのインターフェースに直接アクセスできませんが、間接的な攻撃対象領域は依然として存在します。

内部関係者によるリスクもあります。つまり、ジェイルブレイク技術を試みて、本来見るべきではないデータにアクセスしたり、Social Gauge を意図しない目的で再利用したり、分析を操作したりする（例：「私の製品が素晴らしいというソースをでっち上げろ！」）ユーザーです。

私たちの攻撃シナリオでは、柱2のリスクとは、プロンプトインジェクションを含むソーシャルメディアの投稿が取り込まれ、埋め込まれた悪意のあるコンテンツがエージェントによって正当な指示として解釈されてしまうことです。このリスクは、信頼できない入力に対するエージェントの処理を強化するコントロールによって軽減できます。

AIガードレール：コンテンツの安全性とプロンプトインジェクション：

これまで見てきたように、Mosaic AI Gatewayには、安全性フィルタリングやPII検出など、適用可能な組み込みのガードレールがいくつかあります。これらのガードレールは、エージェントの入力または出力（あるいはその両方）に適用できます。これらの組み込みガードレールに加えて、Mosaic AIモデルサービングにカスタムモデルをデプロイして活用することもできます。例えば、最新のLlama Protectionモデルは、プロンプトインジェクション、有害なコンテンツ、またはコードインタープリターの悪用を検出するようにファインチューニングされた特殊なLLMです。これらのモデルは、エージェントの周りの防御層として機能し、インタラクションがインシデントに発展する前に検査することができます。

これらのガードレールの有効性を把握するため、私たちは小規模なエクスペリメントを行いました。私たちは、自動化されたLLMセキュリティテストのためにDatabricksと簡単に統合できる、NVIDIA開発のオープンソースツール「Garak脆弱性スキャナー」から、数百の悪意のあるプロンプトを収集しました。このデータセットから、3 つの一般的な攻撃カテゴリを選択しました。

1. プロンプトインジェクション：ウェブサイト、翻訳タスク、Eメールなどのコンテキストに隠された悪意のある指示で、モデルを操作して意図しない動作をさせるように設計されています。
2. ジェイルブレイク：アライメントの安全対策をバイパスし、有害または制限された出力を引き出すことを目的として、巧妙に作成されたプロンプト。
3. ダウンストリームインジェクション攻撃：別のシステムによって解釈された場合にのみ危険となるコンテンツをモデルに生成させようとするプロンプト。例えば、アプリケーションによって実行される悪意のあるSQLステートメントや、HTMLとしてレンダリングされたときに機密データを抜き出す、巧妙に作られたMarkdown画像タグなど。

次に、これらの攻撃の成功率をベースラインモデル（この場合はLlama-4-Maverickのデプロイメント）に対して測定しました。結果は明白でした。ガードレールがない場合、悪意のあるプロンプトのかなりの部分が、標的とされた動作を正常に引き起こしました。カスタマイズされたガードレールモデル（プロンプトインジェクションとジェイルブレイク用のPrompt Guard 2、ダウンストリームインジェクション用のllama guard 3-8b）をモデルの前に配置したところ、3つのカテゴリすべてにおいて成功率が90%以上低下しました。

追加のガードレール技術、オープンソースのアプローチ、または最新のPII検出モデルの調査にご興味がある場合は、Databricksの担当者にお問い合わせいただき、カスタムのガードレール展開に関する詳細をご確認ください。

プロンプトレジストリ:
巧妙に作成されたシステムプロンプトは、攻撃が成功するかどうかの分かれ目になることがあります。専用の検出モデルほど堅牢ではありませんが、正しく設定する価値はあります。MLflowプロンプトレジストリは、GenAIアプリケーションのプロンプトエンジニアリングと管理を合理化し、組織全体でプロンプトをその場しのぎで寄せ集めるのではなく、バージョン管理、追跡、テスト、再利用を可能にします。

概要：信頼できない入力を処理するための制御
Social Gaugeは依然としてオープンなインターネットから読み取りますが、それがそのコア要件です。しかし、攻撃者が悪用できる攻撃対象領域は大幅に狭まりました。Webコンテンツに埋め込まれた悪意のあるプロンプトは、エージェントに到達する前にファインチューニングされた検出モデルを通過する必要があり、システムプロンプトはその場しのぎで作成されるのではなく、バージョン管理されテストされます。これらの制御はいずれも単独では完璧ではありませんが、積み重ねることで、完全に開かれた攻撃対象領域を、攻撃者が悪用するためにはるかに多大な労力を要するものに変えます。

第3の柱: 状態の変更または外部との通信 - コントロール

攻撃シナリオの最終段階における「第 3 の柱」のリスクは、プロンプトインジェクションが処理された後、エージェントが、データを外部に流出させたり、内部スキーマ内でデータを変更して下流の意思決定に影響を与えたりすることによって、悪意のある指示を実行する能力を持ってしまうことです。

Social Gaugeは、製品のパフォーマンスを調査するユーザーのために、既存のデータをサードパーティのデータで拡張します。これは、カタログ、スキーマ、テーブル、およびその他のオブジェクトに本質的に書き込む必要があることを意味します。基礎となる状態は変化しています。ここでは、アウトバウンドネットワークアクセスの制限、外部ストレージへのアクセスの制限、Unity Catalog内の状態変更の制限という3つのコントロールに焦点を当てます。

Serverless Egress Controls - インターネットのロケーション:
たとえプロンプト インジェクションがエージェントによって処理されたとしても、Databricks のネットワーク ポリシーを通じて serverless エグレス コントロールを適用することで、結果として生じる影響範囲を大幅に縮小できます。これらにより、管理者はサーバーレスワークロード（Databricks Appsを含む）からのアウトバウンド接続に対してデフォルトで拒否する設定を定義し、その後、エージェントが実際に必要とする信頼できる宛先のみを明示的に許可できます。

Social Gaugeのようなエージェントを実行しているワークスペースに制限付きネットワークポリシーをアタッチすることで、エージェントが任意のインターネットEndpointに到達する能力を制限し、間接的なプロンプトインジェクションの攻撃対象領域を縮小し、未知の宛先へのデータ漏洩のリスクを低減します。

Serverless Egress Controls - Unity Catalogオブジェクト:
FQDNフィルタリングを介して既知のエンドポイントへのアクセスを制限することに加えて、Serverlessエグレスコントロールの2番目の機能は、S3バケットのようなクラウドストレージの場所へのアクセスを制限する機能です。ワークスペースに関連付けられたバケット、システムテーブル、サンプルデータセットはデフォルトで読み取り専用のままですが、このコントロールはさらに進んでおり、AIエージェントが承認されていないバケットに書き込むのを防ぎ、最も一般的なデータ持ち出し経路の1つを遮断します。

Unity Catalog - ワークスペースバインディング：
ワークスペースとカタログのバインディングにより、顧客は特定のワークスペースからのカタログへのアクセスを制限できます。これは、開発者が複数の環境にわたってデータにアクセスできるものの、そのデータが開発の境界を越えるべきではない場合に重要です。データエンジニアは本番運用データを読み取る権限を持っているかもしれませんが、開発ワークスペースからそれを行うべきではありません。

Social GaugeはOBO資格情報で動作するため、ワークスペースのバインディングにより、開発環境での運用中にエージェントが誤って本番運用の状態を変更する可能性が軽減されます。

まとめ：状態の変更または外部との通信のためのコントロール
アウトバウンド接続に対してdefaultで拒否の姿勢を強制し、外部ストレージをロックダウンするserverlessエグレスコントロール、および環境の境界を強制するワークスペースバインディングにより、最も明白な漏洩および状態操作の経路を遮断しました。次に、すり抜けてしまうものをどのようにキャッチするかについて話しましょう。

AIエージェントのセキュリティリスクのモニタリング

上述の通り、顧客はMosaic AI Gatewayを使用して、企業全体のすべてのAIモデルとエージェントへのアクセスを管理および統制でき、この統合は可観測性とモニタリングにも及びます。AI Gatewayを使用すると、推論テーブルを介して、組織全体のAIモデルおよびエージェントへのすべての入力と出力を一元的にLogsに記録できます。このデータを使用して、AIリクエストの監視と監査、モデルのパフォーマンスとセキュリティの強化が可能になります。

推論テーブル

以下のクエリーを使用して 推論テーブル を監視し、組み込みの ガードレール のいずれかがTriggerされたかどうかを確認できます。このクエリーは、トリガーされたガードレール（入力または出力）と、検出された有害なカテゴリを抽出します。もちろん、セキュリティに関しては、事後対応よりも事前対応の方が常に優れています。そのため、クエリーを検証したら、追加のステップを実行して アラート として設定し、調査が必要になる可能性のある事態が発生したときに、あなたまたはセキュリティオペレーションセンター（SOC）に自動的に通知するようにする価値は十分にあります。

システムテーブル
推論テーブル に加えて、Databricks の システムテーブル には、Databricks で発生している重要なイベントに関する豊富な知見が含まれています。当社では 過去のブログ で、潜在的なセキュリティの脅威や侵害の痕跡（IoC）をプロアクティブに監視してアラートを出すために、これらをどのように活用できるかについて説明しました。これは、AI エージェントのコアセキュリティリスクにも拡張できます。たとえば、以下のクエリーを使用すると、サーバーレスのエグレス制御を監視し、誰か（または何らかのエージェント）が外部と通信するためにそれらをバイパスしようとしているかどうかを確認できます。

審査員としての AI
審査員としての AI の使用は、エージェントおよび人工知能の分野全般で広く普及しています。実際、ほとんどのガードレールモデルは、基本的に、その特定の目的を果たすためにファインチューニングされた、および/または特定のシステムプロンプトによって誘導された LLM です。前述のとおり、Mosaic AI モデルサービングにカスタムモデルをデプロイするのは簡単です。また、Databricks 上に Llama Guard 4 や Llama Prompt Guard 2 といった最新かつ最高のガードレールモデルのほとんどをデプロイする例も用意しています。カスタムガードレールとしてデプロイするだけでなく、MLflowの汎用的なmlflow.pyfuncフレーバーでモデルをログに記録すれば、さまざまな方法で活用できることが、Databricksのオープンでプラガブルなアーキテクチャの利点の1つです。例としては、バッチ Spark ワークフローまたは Spark 宣言型パイプラインとしてデプロイしたり、SQL を介して ai_query で呼び出したり、さらには Spark Structured Streaming を使用して、ほぼリアルタイムまたはマイクロバッチのシナリオで適用したりすることなどが挙げられます。

場合によっては、すべてのリクエストまたはレスポンスにガードレールを適用することが現実的でないことがあります。ガードレールが、エージェントが操作しているビジネス目標や対象ドメインを妨げる可能性があるというのは、完全に妥当なシナリオです。ガードレールが適用されていなくても、推論テーブルとバッチまたはストリーミングパイプラインを使用して潜在的に有害なコンテンツを分類することで、エージェントの安全性を監視できます。

その他のリソース

この投稿で紹介した制御は、最終目標ではなく出発点です。エージェントの能力が向上するにつれてプロンプトインジェクションのリスクも進化するため、目標はそれに歩調を合わせる反復可能なセキュリティプログラムであり、これは一度きりの強化策ではありません。

これらのエージェントのセキュリティパターンは、Databricks AIセキュリティフレームワークの次の進化も形成しています。DASFの今後のアップデートでは、フレームワークが拡張され、自律型AIエージェント、ツールの使用、新たなプロンプトインジェクションのリスクに対処し、組織がモデルだけでなく完全なAIシステムを保護できるよう支援します。

最も関連性の高いリソースを3つのフェーズに整理しました。

定義：

• Databricks AIセキュリティフレームワーク (DASF) 2.0は、AIシステムの12のコアコンポーネントにわたる包括的なリスク分析を提供し、MITRE ATLAS、NIST、OWASP、HITRUSTなどの標準にマッピングされています。これは、プロンプトインジェクション、ジェイルブレイク、データエクスフィルトレーションなどのリスクを軽減するための67の実用的なコントロールを提供します。このブログで説明するDASFのコントロール:
  • DASF 5: データおよびその他のオブジェクトへのアクセス制御
  • DASF 64: AIモデルとエージェントからのアクセスを制限する
  • DASF 57: 属性ベースのアクセス制御（ABAC）を使用する
  • DASF 58: フィルターとマスキングでデータを保護する
  • DASF 54: AIガードレールの実装
  • DASF 62: ネットワークセグメンテーションの実装
  • DASF 37: モデルのモニタリングとデバッグのための推論テーブルの設定
  • DASF 49：LLM評価の自動化
  • DASF 73: プロンプトを登録する
  • DASF 55: 監査logsを監視する
• Databricks AIガバナンスフレームワーク（DAGF）は、設計、開発からデプロイ、モニタリングに至るまで、ライフサイクル全体にわたって組織がAIシステムをどのように統制すべきかを定義します。
• Databricksセキュリティベストプラクティスガイド (AWS、Azure、GCP向け) は、セキュリティ意識が最も高い顧客とのパートナーシップにおける実績に基づき、標準的で高度にセキュアな環境向けに推奨する主要なセキュリティコントロールの詳細な概要を提供します。

デプロイ

• Databricksセキュリティリファレンスアーキテクチャ - Terraform Template（SRA）は、セキュリティのベストプラクティスで構成されたDatabricksワークスペースとクラウドインフラストラクチャのデプロイを可能にします。

モニタリング

• セキュリティ分析ツール（SAT）は、セキュリティチームとプラットフォームチームがDatabricksワークスペースのセキュリティ体制を迅速に評価するのに役立ちます。
• Databricks Detection Toolは、ワークスペースでのアクティビティの監視に役立つ、一連のオピニオネイテッドな検出機能を使いやすいノートブックにまとめたものです。

これらのリソースをまとめることで、チームは、特定時点での単一エージェントの強化から、イノベーションと進化する脅威の状況の両方に対応できる、Databricks 上の AI のための反復可能でスケーラブルなセキュリティプログラムへと移行するための実用的な方法を得ることができます。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事