新たに提唱されたフレームワークは、AIペネトレーションテストが従来型のインフラ侵害の測定にとどまらず、攻撃者がAI搭載システムを本来の運用目的に反する形で動作させられるかどうかを評価すべきだと主張しています。
従来のペネトレーションテストでは、不正アクセス、権限昇格、データ窃取、サービス妨害、持続的侵入といった結果を通じて侵害を測定するのが一般的でした。
こうした結果は、APIやクラウドプラットフォーム、ID管理、データストア、コンテナ、モデルリポジトリ、そしてソフトウェアサプライチェーンに依存し続けるAIアプリケーションにおいても、依然として重要な指標です。
しかし同フレームワークは、機械学習モデルが意思決定や推奨、ツール呼び出し、自動化ワークフローを駆動するシステムにおいて、最も深刻な障害を説明するにはリソース侵害だけではもはや不十分だと主張しています。
提案された定義は、「敵対的な影響経路」「AIが制御する挙動」「運用目標の違反」という3つの要素からなる連鎖に焦点を当てています。
このアプローチでは、攻撃者が侵入を達成するために認証情報を盗んだりモデルの重みを改ざんしたりする必要はありません。
攻撃者が制御する入力によって、エージェントやアシスタント、分類器、意思決定支援システムをその使命に反する挙動へと誘導できるのであれば、運用上の意味においてセキュリティ境界はすでに突破されているといえます。
プロンプトインジェクションはその代表例です。Webページやメール、チケットのコメント、ログのフィールド、検索で取得したドキュメント、ツールの出力、ナレッジベースのエントリなどに埋め込まれた悪意あるプロンプトが、信頼できないデータではなく指示として解釈されてしまう可能性があります。
検索拡張生成（RAG）やエージェント型ワークフローでは、モデルが企業のツールやAPIへのアクセス権を保持したまま外部コンテンツを取り込む機会が増えているため、この曖昧さが特に危険なものとなります。
同フレームワークはまた、間接的なプロンプトインジェクションを重要な侵入経路として位置づけています。攻撃者はチャットボットに直接やり取りする代わりに、AIシステムが後で取得・要約・分類・処理対象とする成果物の中に敵対的なコンテンツを仕込むことがあります。
攻撃者の狙いは、アラートを抑制すること、推奨内容を改ざんすること、ワークフローを操作すること、不正なツール利用を引き起こすこと、あるいは人間のオペレーターの判断に影響を与えることなどが考えられます。
Arxivの研究者らによると、このモデルは侵入の成功を、明示的な脅威モデルの下で定義された運用目標に違反するAI制御の挙動を実現可能な形で誘導できることと再定義しています。
SOC(セキュリティ・オペレーション・センター)向けアシスタントは、その実践的な例といえます。SOCプラットフォームやモデルの重み、アナリストのアカウントに一切アクセスできない外部の攻撃者であっても、トリアージの過程で取り込まれるログやフィッシングの痕跡、ドメイン、URL、外部脅威インテリジェンスのコンテンツには影響を及ぼせる可能性があります。
ネットワークセキュリティ
指示のように見えるコンテンツによって、アシスタントが重大インシデントの深刻度を引き下げたり、侵害の痕跡(IoC)を省略したり、チケットのクローズを推奨したり、アナリストへのエスカレーションを遅らせたりした場合、攻撃者は基盤となるインフラを侵害することなく、使命に関わる障害を誘発したことになります。
AIペネトレーションテスト
同論文は、この種の結果を単なるハルシネーションや個別の分類エラーとは区別しています。モデルが不正確な回答を生成したからといって、それが自動的にペネトレーションテストの検出事項となるわけではありません。
AIを介した侵入として認定されるには、その挙動が現実的な影響経路を通じて敵対的に誘導されたものであり、あらかじめ定義された運用目標に違反している必要があります。
この区別は、過剰報告を防ぐと同時に、行動面のリスクを測定可能かつ対処可能なものにすることを意図しています。
このテストモデルはまず、不正アクセスの防止、重大インシデントの確実なエスカレーション、安全な推奨内容の維持、承認なしでの破壊的なツール操作の阻止といった、ミッションレベルの目標を定義することから始まります。
その後テスト担当者は、これらの目標に影響を与えるAI制御下の挙動をマッピングし、直接的・間接的な影響経路を特定し、行動面での失敗基準を確立した上で、制御された攻撃シナリオを実行し、再現性のある証拠を記録します。
AIの挙動には確率的な側面があるため、同フレームワークでは一度の意外な出力に頼るのではなく、繰り返し試行を行った上で成功率を測定することを推奨しています。
テストの証拠には、脅威モデル、使用したプロンプトや成果物、モデルおよびアプリケーションの設定、検索の状態、ツールの権限、試行回数、成功頻度、観測された動作、そして運用上の影響を記録する必要があります。
是正措置は4つの層にわたる必要があります。すなわち、従来型のリソース保護策、入力や検索結果に対する悪意ある影響を軽減するための制御、ツール利用のガードや出力検証といった行動面での制御、そして人間による確認・エスカレーションルール・独立検証・フェイルセーフのデフォルト設定を含む目標レベルでの保護策です。
セキュリティチームは、攻撃者がAI環境に侵入できるかどうかだけでなく、その挙動を操作することで、そのシステムが保護するために導入されたビジネス上、安全上、あるいはセキュリティ上の目標を損なうことができるかどうかについても検証すべきです。
𝗔𝗜 𝗦𝗢𝗖 𝘃𝘀 𝗠𝗗𝗥 𝘃𝘀 𝗠𝗦𝗦𝗣 2026年、どちらが最適か? コスト、自動化、対応力を比較: 無料ガイドをダウンロード
翻訳元: https://gbhackers.com/ai-penetration-testing/
