生成AIチャットボット・エージェントの安全性確保アプローチ

データを取り込み、埋め込み、ベクトルデータベースにインデックスを作成するためには、ソース文書を平文に解析し、チャンクとして分割し、埋め込み、メタデータを追加する必要があります。

• ユーザーのクエリをベクトル表現に変換し、ベクトルデータベースの検索やナレッジグラフの横断に使用できるようにします。
• 高度な戦略では、検索結果を最適化するためにクエリを書き換えることができます。

• クエリベクトルやグラフパスに基づき、関連するデータスニペットを検索し、生成プロセスへの情報提供に使用します。
• メタデータやその他の情報が特定されたのち、データ検索は、構造化クエリや半構造化クエリとともに、構造化フィルタリングと組み合わせることができます。

• この段階では、LLMは検索段階から返されたデータを使用して、ユーザーの元のクエリに対する回答を生成します。
• プロンプトエンジニアリングに依存します。

• 応答のキャッシング
• ガードレール
• メモリー管理
• コンテキスト・ウィンドウの管理

RAGアプリケーションに関する主な方策は以下の要素を含みます

• 安全・安心な運用をサポートするシステムプロンプトのデザイン（詳細は後述）
• ユーザーによる入力の検証とサニタイズ
  • 敵対的攻撃、脱獄（jailbreak）、誤用等の防止
  • クエリの検証と有害なクエリのデータベースへの到達を防止
• データベースへのインプットの検証とサニタイズ
  • 間接的プロンプトインジェクション攻撃、個人情報漏洩、機密情報の漏洩の防止
  • データの匿名化
• アプリケーションに接続されたデータベースが検索のみを許可する適切な制御
• アプリケーションに接続されたデータベースのアプリケーション、ユーザ毎の適切なアクセス制御
  • ベクトルデータベースとナレッジグラフへのアクセスコントロール
  • 機密性の高い文書や情報に対するRBAC
• 静的な状態で暗号化されたデータベース
  • 現時点では各種のベクトルデータベースプラットフォームではサポートされていない方法です。
• 出力のフィルタリングとコンテンツモデレーションによる有害な応答のユーザーへの到達の防止
• ログ管理とモニタリング
• HTTPS、SSL/TLSなどのセキュアなプロトコルを通じた要求と応答
• 認証とアクセスコントロールの導入

RAGアプリケーションのシステムプロンプトは、システムの使用目的によって多種多様になり得ます。例えば、商品検索に使用する場合、RAGシステムは特定の商品リストに関する情報をRAGデータベースから取得するための特化した、または強化された検索エンジンとして機能し、その場合は会話履歴が重要ではないかもしれません。一方で、ITヘルプデスクの場合、LLMが役立つ応答を提供するために会話履歴は非常に重要です。

‍

すべてのタイプのRAGアプリケーションにおいて、適切に設計されたシステムプロンプトは安全性とセキュリティを強化します。RAGアプリケーションのシステムプロンプトを設計する際には、以下の安全対策を考慮してください。

‍

上記のような安全なシステムプロンプトを使用することは、セキュリティ実現への第一歩です。アプリケーションをより完全に保護するためには、次のセクションに記載された対策を実装してください。

• データの完全性攻撃: 大元のデータが改ざんされ、データソースが破損する可能性があります。
  • 対策:
    • アクセス制御と監査を実装して、データの変更を監視する
    • 暗号学的ハッシュを使用して、データ処理の各段階でデータの完全性を確認する
• データの汚染:
  情報抽出プロセス中に悪意のあるデータがシステムに取り込まれ、出力が損なわれる可能性があります。
  • 対策:
    • データ処理パイプラインに入る前に、入力データをフィルタリングして悪意のある入力を特定および除去する
    • 新しい種類の敵対的入力を認識するためにシステムを定期的に更新する
• データ漏洩:
  機密データが誤ってデータセットに含まれ、プライバシー侵害を引き起こす可能性があります。
  • 対策:
    • データの取り込みおよび処理段階でデータの匿名化技術と厳格なプライバシー制御を使用する
    • すべての個人識別子を削除または抽象化する

• 不正アクセス:
  攻撃者がベクトルデータベースにアクセスし、ベクトル表現を取得または変更する可能性があります。
  • 対策:
    • 多要素認証、暗号化、定期的な脆弱性の更新を通じてデータベースのセキュリティを強化する
• データの流出:
  攻撃者がデータベースにアクセスし、機密データを盗む可能性があります。
  • 対策:
    • ネットワークのセグメンテーションと監視を導入して、異常なアクセスパターンやデータ移動を検出する
    • データ転送におけるエンドツーエンド暗号化を使用してデータを保護する
• インジェクション攻撃:
  攻撃者がデータベースクエリを操作するためのインジェクション攻撃を行う可能性があります。
  • 対策:
    • データベースクエリで使用されるすべての入力データをサニタイズして、インジェクション攻撃やその他のクエリ操作技術を防ぐ
    • パラメータ化されたクエリを実装する

• 中間者攻撃（MitM）:
  攻撃者がクエリや転送中のデータを傍受して、情報を変更または盗聴する可能性があります。
  • 対策:
    • 不正アクセスに悪用される可能性のある脆弱性を軽減するために、ストレージシステムを定期的に更新し、パッチを適用する
• 応答の改ざん:
  攻撃者が応答生成プロセスを操作して、不正確または有害な応答を生成させる可能性があります。例えば、間接的なプロンプトインジェクションやインコンテキスト学習の汚染などの方法があります。
  • 対策:
    • アプリケーションへのすべてのユーザー入力をフィルタリングして、攻撃や敵対的手法を検出しブロックする
    • LLMからの応答がエンドユーザーに送信される前に、その完全性を確認する
    • 応答が論理的で期待される結果と一致していることを確認するための一貫性チェックを実施する

• モデルの改ざん:
  モデルが改ざんされ、偏った応答や予測された応答を生成する可能性があります。
  • 対策:
    • モデルの保存およびデプロイ環境を保護し、チェックサムを使用してモデルファイルが改ざんされていないことを確認する
    • モデルの動作を定期的に監査し、バイアスを検出および修正するための更新メカニズムを実装する
• 敵対的攻撃:
  LLMが悪意を持って作成された入力を受け取り、不適切または無意味な応答を引き起こす可能性があります。
  • 対策:
    • 敵対的入力を検出しブロックするための入力検証を実装する
    • 有害または悪意のある内容がユーザーに返されないように出力のフィルタリングを実施する

• 情報漏洩:
  システムが応答の中で私的な情報を誤って公開する可能性があります。
  • 対策:
    • LLMの応答内における機密情報の使用を制御する厳格なデータガバナンス方針を適用する
    • 機密データが回答に含まれていれば検出し流出を防止するために出力フィルタリングを使用する
• 応答の改ざん:
  ‍攻撃者が応答を傍受し、エンドユーザーに到達する前にそれを変更する可能性があります。
  • 対策:
    • メッセージ認証コード（MAC）やデジタル署名を使用して、ユーザーに配信される応答の完全性と真正性を確保する

このセクションでは、タスク指向のエージェントに焦点を当てます。タスク指向のエージェントは、ある程度自律的な動作でタスクを完了するように設計されたアシスタントです。会話をしたり、推論をしたり、記憶を保持したり使用したりすることに重点を置いている前節までで扱ったチャットボットとは異なるものです。

LLMエージェント（以下「エージェント」）はLLMベースのアプリケーションで、ゴールを達成するために必要なステップを計画し、ゴールを達成するためにステップを実行するために外部ツールを使ったり、コンテキスト内で推論を行ったりすることで、複雑なタスクを自律的に実行することができます。ユーザはプロンプトを入力するか、達成したい最初のゴールを入力すると、そこからLLMがタスクを計画、編成、実行する「頭脳」として機能します。

• リサーチのアシスタント
• コーディングのアシスタント
• セキュリティのペネトレーションテストのアシスタント

• LLMモデル
  • 関数呼び出しサポート
• 基盤となるエージェント開発フレームワーク
  • ‍https://github.com/langchain-ai/langchain‍
  • https://github.com/run-llama/llama_index‍
  • https://github.com/deepset-ai/haystack‍
  • https://github.com/langgenius/dify‍
  • https://github.com/joaomdmoura/crewAI‍
  • https://github.com/cpacker/MemGPT‍
  • https://github.com/Significant-Gravitas/AutoGPT
• ベクトルデータベース
  • FAISS、HNSW、ChromaDB、Pinecone、LanceDB、Qdrant、Weaviateなど
• プロンプトエンジニアリング
• HITL（Human-in-the-Loop）による支援
• カスタムツール

計画のメカニズムには次のものが含まれます。

• 目標をより小さな、より管理可能なタスクに分解する
  • Chain of thought(CoT): プロンプトとして事例を与える際、思考過程を同時に入力する手法
  • Tree of thoughts(ToT): 複数のLLMを用いて複数のアイデアや解決策を同時に生成し、それらを評価する手法
• 過去のやりとりから学ぶ「Self-reflection（自己反省）」
  • 過去のアクション決定を精緻化する、失敗を修正するなどの反復的な改善‍
    • ReAct methodology (推論とアクション)
    • Reflexion framework
  • Self-critique（自己批判）
  • Chain of thought(CoT)による結果の一貫性をレビューする

• 短期記憶: コンテキスト内でのラーニング
• 長期記憶: ベクトルのストレージ及び伝統的なデータベース

• 自動的に接続されたツールを使えるようにする
• (Optional) カスタムツールを構築・使用できるようにする

• https://github.com/zilliztech/GPTCache などを用いたキャッシング
• リアルタイムの監督など、HITL（Human-in-the-Loop）による支援
• https://github.com/NVIDIA/NeMo-Guardrails や https://github.com/microsoft/guidance を含むガードレールメカニズム

• 認証および外部コンポーネントのためのセキュリティ対策
  • 各ツールにおける接続するサービスへの最小権限のアクセス設計
  • エージェントツールおよび接続されたサービスに対する委任された認可
  • 接続サービスにアクセスするツールのレート制限
  • コンポーネントの隔離
  • セキュリティとプライバシー
  • マルチエージェント環境におけるエージェント間の認証
• LLMおよび内部コンポーネントのためのセキュリティ対策
  • 入力の検証
    • ユーザーからの入力
    • ツールを介した信頼されていない接続サービスからの入力（ウェブブラウジング、信頼性が混合的なソースなど）
  • 出力フィルタリング
    • エージェントからユーザーへの出力
    • エージェントからエージェントへの出力
  • エージェントのステップに対する透明性
    • ログの監査
    • 人間の介入（HITL（Human-in-the-Loop））
  • 信頼性と一貫性のための技術的対策

技術とベストプラクティスは急速に進化しており、AIエージェントの導入も同様に進化しています。技術の進化に伴い、エージェントのプロンプト設計も進化するべきです。それでもなお、以下のような高レベルのガイドラインは、チャットボットの設計ガイドラインと同様に従うべきです。

高レベルでは、システムデプロイヤーによってエージェントに対して複数のプロンプトが提供されます。これには、システムプロンプトとエージェントプロンプトが含まれます。

「エージェントプロンプト」は、ツールに対する計画、推論、および内部応答を行うための一連のプロンプトを指します。例えば、ReActやReflexionは、広く使用されている一般的なエージェントプロンプトアプローチです。

システムプロンプトは、「チャットボットのシステムプロンプト設計」で述べたパターンに従うべきです。システムプロンプトには（1）ペルソナ、（2）具体的な指示、および（3）例を含める必要があります。

チャットボット用のプロンプトとエージェント用のプロンプトの重要な違いは、ツールの使用に関する点です。ツールはエージェントがチャットボットにはできないタスクを実行できるようにしますが、コストがかかる（例：APIを呼び出す可能性がある）およびより危険な（例：データ漏洩のリスクがある）可能性があります。したがって、エージェントベースのアプリケーションのシステムプロンプトでは、ツールが安全な方法でのみ使用されるようにペルソナおよび具体的な指示を調整する必要があります。

同様に、エージェントプロンプトもその基本バージョンを超えて安全性を促進するように修正できます（例：すべての外部コンテンツを信頼されていないものと見なす）。

• 不正アクセス: 攻撃者がツールにアクセスした場合、それを悪意のある目的で使用する可能性があります。
  • 対策:
    • 厳格なアクセス制御と認証を実施し、許可されたユーザーのみが接続されたツールにアクセスできるようにする
    • 認証に使用されるAPIトークンやその他の認証情報がバックエンドで安全に保管され、LLM自体に共有されないようにする
    • 可能であれば、ツールを分離して、他のネットワークシステムに影響を及ぼすことを防ぐ（例: 限定権限のDockerコンテナ）
• 悪意のあるツールの実行: 攻撃者がツールの脆弱性を悪用してエージェントに有害な操作を実行させる可能性があります。
  • 対策:
    • 接続されたツールが最小権限アクセスを持つように厳密に範囲を設定します。
    • 接続されたツールの認証をユーザーおよびエージェントごとに実施し、潜在的な悪用を防止および追跡します。
    • 接続されたツールを定期的に更新およびパッチ適用して既知の脆弱性を修正します。
• データ漏洩: カレンダーや検索機能などのツールが機密情報を誤って漏洩する可能性があります。
  • 対策:
    • LLM接続ツールによる機密情報漏洩を防ぐために、匿名化技術を使用します（機密データ、ユーザー情報などを削除またはダミーデータに置き換えます）。
    • データアクセスと使用を追跡するために包括的なログ記録と監視を実施します。
    • 機密データにアクセスする前に認証と認可を強制します。

• 入力操作: 攻撃者が細工された入力を提供し、エージェントに意図しない行動を取らせる可能性があります。
  • 対策:
    • エージェントが処理する前に悪意のあるユーザー入力を検出してブロックするための入力フィルタリングを実施します。
    • ユーザー入力、関連するエージェントのステップ、および下流のアクションを監視し、悪用を特定します。
• モデル改ざん: エージェントの基盤モデルが改ざんされ、その行動や意思決定が変更される可能性があります。
  • 対策:
    • モデルの保存および展開環境を保護し、チェックサムを使用してモデルファイルが改ざんされていないことを確認します。
    • モデルの動作を定期的に監査し、バイアスや脆弱性を検出および修正するための更新メカニズムを実装します。
• データ流出: エージェントが悪用され、システムから機密データを抽出する可能性があります。
  • 対策:
    • 機密データを明らかにしようとする攻撃を検出してブロックするための入力フィルタリングを実施します。
    • 機密データにアクセスする前に認証と認可を強制します。
    • チャットボットの応答に機密データが含まれないように出力フィルタリングおよびモデレーションを実施します。

• 計画ロジックの不正: 計画ロジックの欠陥が悪用され、望ましくない行動を引き起こす可能性があります。
  • 対策:
    • エージェントのコンテキストにロジックステップを注入しようとする攻撃を検出するための入力フィルタリングを実施します。
    • 計画ロジックが堅牢で悪用可能な欠陥がないことを確認するための厳密なテストおよび検証プロセスを実装します。
    • 行動を取る前にエージェント内で追加の反射を実施し、計画内のすべてのステップが正当なソースから生成されていること、ロジックが意図された使用ケースと一致していること、悪用につながらないことを確認します。
• 計画データの操作: 計画コンポーネントで使用されるデータが損なわれると、エージェントの行動が有害になる可能性があります。
  • 対策:
    • 計画に使用されるデータの完全性をチェックし、バージョン管理を使用してデータが改ざんされていないことを確認します。
    • データソースをスキャンし、敵対的攻撃やその他の悪用を1）データストアに入る前、2）LLMエージェントパイプラインに入る前に検出します。

アプリケーションの短期および長期メモリに影響を与える脅威には以下が含まれます。

• メモリの改ざん: 不正なメモリの変更がデータの破損や漏洩を引き起こす可能性があります。
  • 対策:
    • メモリ作成前にユーザー入力をスキャンして敵対的攻撃やその他の悪用を検出するための入力フィルタリングを実施します。
    • メモリストレージの暗号化およびアクセス制御メカニズムを実装します。
    • メモリデータを定期的にバックアップし、検証して改ざんを検出および修正します。
• 機密情報の漏洩: メモリに保存された機密データが露出する可能性があります。
  • 対策:
    • 機密データがメモリに保存されている場合、不正アクセスを防止するためにデータ匿名化および厳格なアクセス制御を使用します。
    • 機密データがアプリケーションやユーザーに返されないように出力フィルタリングを実施します。

LLMベースのエージェントは、反射、自己批評、思考の連鎖、およびサブゴール分解などの推論および自己改善技術に依存しています。これにより、以下の脅威が発生します。

• ロジックの悪用: これらのコンポーネントには脆弱性が含まれており、エージェントの行動を変更するために悪用される可能性があります。例えば、攻撃者がエージェントの自己評価や意思決定に影響を与える可能性があります。
  • 対策:
    • エージェントのコンテキストにロジックステップを注入しようとする攻撃を検出するための入力フィルタリングを実施します。
    • ロジックコンポーネントが堅牢で悪用可能な欠陥がないことを確認するための厳密なテストおよび検証プロセスを実装します。
    • エージェントが行動を取る前に追加の反射を実施し、計画内のすべてのステップが正当なソースから生成されていることを確認します。

• アクションの操作: 攻撃者がアクションコンポーネントを制御すると、エージェントに悪意のあるタスクを実行させる可能性があります。
  • 対策:
    • エージェントの行動をターゲットとする悪意のある入力を検出および防止するための入力フィルタリングを実施します。
    • アクションは常にLLM自体によって生成され、ユーザー入力から直接生成されないようにします。
    • 下流のアクションを監視し、使用が期待される行動と一致していることを確認します。
    • 高い特権を必要とするアクションや機密システム、データ、またはその他のリソースにアクセスするアクションには、ヒューマン・イン・ザ・ループを実装します。
    • アクション操作の影響を最小限に抑えるために、接続されたすべてのシステム/サービスに対して最小権限の原則を強制します。
• 特権の昇格: エージェントが適切なチェックなしに高い特権を必要とするアクションを実行する可能性があります。
  • 対策:
    • デフォルトで最小権限の原則を強制します。
    • 高い特権を必要とするアクションには明示的な認可を要求します。

Robust Intelligenceは、AIリスク研究や国際的なリスク標準策定への関与を通じて、最新の脆弱性・コンプライアンスに対応した自動化されたAIリスクの検証・軽減ツールを提供しています。当社のソリューションは大きく2つの構成要素からなり、AIの開発時から運用時までを通じたリスクマネジメントを可能にします。

• AI Testing: AIのモデル・ファイル・データに対してセキュリティおよびセーフティの観点から、包括的かつ多数の自動化されたレッド・チーミングテストを実行し、Robust Intelligenceの最新のAIリスク知見に基づく攻撃手法に対する脆弱性を検証、リスクの未然の軽減を支援します。
• AI Firewall: AIアプリケーションをラップするような形で適用可能な保護ツールで、LLM駆動のシステムをプロンプトインジェクション、個人情報漏えい、その他の有害な操作やコンテンツから守ります。Robust Intelligenceの脅威インテリジェンスの知見に基づきルールをアップデートし、リアルタイムで入出力を検証、望ましくない入出力に対してブロック・アラートなどの対応が可能です。

サンフランシスコに本社を置き、アメリカにおいてはJPモルガン・チェース、エクスペディア、米国防総省など、日本国内においては東京海上ホールディングス、楽天グループ、LINEヤフー、NEC、リクルート、損保ジャパンなどの業界リーダーから信頼を得ています。

弊社の生成AIのリスク軽減ソリューションにご関心をお持ちの場合は、是非ともデモのリクエストでお問い合わせください。