代理店の過剰な脆弱性を軽減する

OWASP リスクの説明

過剰なエージェンシーは、大規模言語モデル(LLM)に他のシステムとやり取りするための不必要または過度に寛容な権限が付与された場合に発生する脆弱性です。LLM が外部ツール、プラグイン、関数(「エージェンシー」)を呼び出すことができる場合、この脆弱性により、意図しない、承認されていない、潜在的に有害なアクションを実行する可能性があります。攻撃者は、プロンプト インジェクションやその他の操作手法を使用して LLM をだまし、付与されたエージェンシーを悪意のある目的で使用することで、この脆弱性を悪用できます。根本的な問題は、LLM がアクションを実行できることだけでなく、アクションの範囲が広すぎ、制御が不十分であることです。

Android デベロッパーが注意すべき理由

Android アプリケーション内で LLM に過剰なエージェンシーを付与すると、重大なセキュリティ インシデントにつながる可能性があります。

  • システムへの不正アクセス: 関数呼び出しを通じてデバイスのファイル システムとストレージ リソース、またはネットワーク呼び出しを実行する機能がモデルに公開されている場合、攻撃者はプロンプト インジェクションを使用して、デバイス上のファイル(ユーザー ドキュメント、アプリデータなど)や接続されたネットワーク リソースにアクセスしたり、変更したり、削除したりする可能性があります。
  • データ引き出し: アプリが関数呼び出しを使用して、LLM にローカルデータ(Room データベース、SharedPreferences、内部 API など)へのアクセス権を付与する場合。悪意のあるプロンプトにより、モデルが機密情報を取得して、メールやネットワーク リクエスト関数などの外部ツールに渡してしまう可能性があります。
  • 他の機能/システムの侵害: LLM が他の機能(SMS の送信、通話の発信、暗黙的インテントを使用したソーシャル メディアへの投稿、システム設定の変更、アプリ内購入など)を制御している場合、攻撃者はこれらの機能を乗っ取ってスパムを送信したり、誤った情報を拡散したり、不正な取引を行ったりする可能性があります。これにより、直接的な金銭的損失やユーザーへの危害が生じる可能性があります。
  • サービス拒否: LLM がデータベース クエリやネットワーク リクエストを公開する関数呼び出しと統合されている場合、悪意のあるプロンプトによってこれらのアクションが繰り返しトリガーされる可能性があります。これにより、バッテリーの過度の消耗、データ超過、ローカル リソースの枯渇など、システムの健全性が低下する可能性があります。

Android アプリ デベロッパー向けの緩和策

Android アプリにおける過剰なエージェンシーの緩和は、LLM がアクセスまたはトリガーできるすべてのツールと機能に最小権限の原則を適用することに重点を置いています。

AI のツールボックスを制限する(粒度の細かい関数とオープン エンドの関数)。

  • 最小限のツールを提供する: LLM は、アプリ内でタスクを実行するために絶対に必要となる特定のツール(関数、API、インテント)にのみアクセスできるようにします。ウェブの閲覧やメールの送信が必要ない場合は、それらの機能を公開しないでください。
  • シンプルな単一目的のツールを使用する: 範囲が限定的で具体的なツールを設計します。たとえば、複数のデータソースにアクセスするためにオープン エンドのパラメータを受け入れる汎用ツールではなく、特定のタイプのユーザー設定のみを読み取るツールを提供します。モデルがコマンドや引数を定義できるようにすることで、Runtime.getRuntime().exec() などの強力なシステムレベルの API を LLM に公開しないようにします。

AI の能力を制限する

  • きめ細かい Android 権限: LLM によってトリガーされた関数が Android システム リソースや他のアプリとやり取りする場合、アプリがリクエストして保持している Android 権限が、必要最小限のものだけであることを確認します。
  • ユーザーごとの権限: LLM がユーザーに代わってアクションを実行する場合は、そのユーザーの特定の権限とコンテキストを使用して実行する必要があります。LLM が行うアクションは、特定のユーザー コマンドに対する直接的な応答でなければなりません。

人間が責任を負う(重要なアクションに対するユーザーの同意)

  • ユーザーの承認を必須にする: LLM が提案または実行しようとする重要なアクションやリスクの高いアクション(データの削除、アプリ内購入、メッセージの送信、重要な設定の変更など)については、常に UI の確認ダイアログを使用して、人間による明示的な承認を必須にします。これは、重要な決定にマネージャーの承認が必要な場合を想定したものです。

信ぜよ、されど確認せよ(入出力の検証と堅牢なバックエンド)

  • バックエンドのセキュリティ: アクションが許可されるかどうかを LLM に判断させるだけにしないでください。LLM によってトリガーされる関数が接続するバックエンド サービスまたは API には、すべてのリクエストを二重にチェックし、正当で想定されるパラメータ内にあることを確認するための、独自の堅牢な認証、認可、入力検証が必要です。
  • データをクリーンアップする: 他の脆弱性と同様に、LLM に入力される入力と、関数呼び出しのために LLM によって生成されるパラメータの両方をサニタイズして検証し、アクションが実行される前に悪意のある命令や予期しない出力を検出することが重要です。

概要

過剰なエージェンシーは、LLM が他のシステムや関数とやり取りするための権限を広範囲に持ちすぎている重大な脆弱性です。この脆弱性により、有害なアクションを実行するように騙される可能性があります。これにより、Android アプリケーションで不正なデータアクセス、システム侵害、金銭的損失、ユーザーへの危害が発生する可能性があります。緩和策は最小権限の原則に大きく依存しています。LLM で使用できるツールと Android 権限を厳しく制限し、各ツールに最小限の特定の機能があることを確認し、影響の大きいすべてのオペレーションに人間の承認を必要とします。

参考情報