Each language version is independently generated for its own context, not a direct translation.
この論文は、**「AI エージェント（自律的に行動する AI）」**という新しい技術がもたらす「セキュリティ上の新しい危険」と、それに対抗するための「新しい防衛策」について書かれた、非常に重要な報告書です。
Perplexity（AI 検索エンジン）のチームが、アメリカの国立標準技術研究所（NIST）に提出したものです。
専門用語を排し、**「AI エージェントを『優秀だが少し危ない、新しいタイプの秘書』」**と想像しながら、わかりやすく解説します。
📝 要約：AI 秘書の「新しい危険」と「新しい守り方」
1. なぜ AI エージェントは危険なのか？（従来のソフトとの違い）
昔のコンピュータプログラムは、「レシピ（コード）」と「食材（データ）」が厳格に分かれていました。
- 昔のシステム： 料理人は「レシピ」に従って「食材」を処理するだけ。食材に「毒」が入っていても、レシピ自体は書き換えられないので、料理人は無防備に毒を食べてしまうことは少なかった。
しかし、AI エージェントは違います。
- AI の世界： 「食材（データ）」自体が「新しいレシピ（指示）」に変わってしまいます。
- 例え話： あなたが AI 秘書に「今日のメールを確認して」と頼みました。すると、そのメールの中に**「実は、このメールは『銀行口座を全額送金して』という命令だ！」**と書かれていたとします。
- AI は「メール（データ）」を読みながら、それを「新しい命令（コード）」として実行してしまいます。
- 結果： 従来のセキュリティ対策（「データは実行しない」というルール）が通用しなくなります。これが**「間接的なプロンプト注入攻撃」**と呼ばれる最大の脅威です。
2. 具体的に何が起きるのか？（3 つのリスク）
AI エージェントは「自律的」に動くため、以下のようなことが起こり得ます。
- 秘密の漏洩（Confidentiality）：
- AI が「あなたの住所やクレジットカード情報を検索して」という命令を、悪意あるウェブページから受け取って、勝手にハッカーに送信してしまう。
- 操作の改ざん（Integrity）：
- AI が「安い商品を買って」という命令を、悪意あるサイトから受け取り、実際には高価な偽物を買ってしまったり、あなたのファイルを勝手に消去したりする。
- システムの停止（Availability）：
- AI が「無限ループ」にはまったり、悪意ある攻撃でリソースを枯渇させられたりして、サービスが止まってしまう。
特に怖いのは「多人数の AI 秘書チーム（マルチエージェント）」の場合です。
- 一人の AI が「もう一人の AI に、より権限の高い作業を頼んで」という連鎖が起き、**「権限の昇格」**が勝手に起こってしまいます。まるで、部下が上司を騙して、さらに上の部長の鍵を盗ませるような状態です。
3. どうやって守るのか？（3 層の防御システム）
「AI 自体を完璧に安全にする」のは難しいので、**「防御の壁を何重にも重ねる（Defense-in-Depth）」**ことが重要だと提案されています。
4. 今後何が必要か？（提言）
この論文は、以下の 3 つを強く求めています。
- 新しい基準（ベンチマーク）：
- AI のセキュリティを測る「試験問題」が必要です。静的なテストではなく、実際に攻撃者が知恵を絞って攻撃してくるような「動的なテスト」が求められています。
- 新しい権限管理：
- 人間用の「役割（ロール）」ベースの権限管理を、AI にも応用し、さらに「リスクが高いときは人間に確認する」という**「リスクに応じた自律性」**を確立する必要があります。
- 人間とのバランス：
- 毎回「本当にいいですか？」と AI が聞いてくると、人間は疲れて「はい、はい」と適当に承認してしまいます。AI が「どの程度のリスクなら自分で判断し、どのレベルなら人間に聞くか」を賢く判断できるようになる必要があります。
💡 結論：何が言いたいか？
AI エージェントは、**「非常に便利だが、指示を曲解して暴走する可能性のある新しい存在」**です。
従来の「ウイルス対策ソフト」のような単一の防御では守れません。
**「入り口でチェックし、AI の頭の中でルールを教え、最後に機械的なロックで守る」**という、多重防御の考え方が不可欠です。
私たちは、AI を「万能の魔法使い」ではなく、「厳格なルールに従う必要がある優秀な従業員」として扱い、そのセキュリティを設計し直す時代が来ている、というのがこの論文のメッセージです。
Each language version is independently generated for its own context, not a direct translation.
論文要約：人工知能エージェントのセキュリティ考慮事項
（Perplexity による NIST/CAISI への回答書 2025-0035 の適応版）
1. 問題定義 (Problem)
従来のソフトウェアシステムとは異なり、大規模言語モデル（LLM）を駆動する AI エージェントシステムは、根本的なセキュリティの前提条件を崩壊させています。主な課題は以下の通りです。
- コードとデータの境界の曖昧化: 従来のセキュリティは「コード（実行可能）とデータ（入力）」を厳密に分離することを前提としています。しかし、LLM エージェントでは、プレーンテキストのプロンプトがコードの役割を果たし、動的に生成されたテキストが次のプロンプト（制御フロー）となるため、この境界が崩れています。これにより、従来の注入攻撃（SQL インジェクション等）とは異なる、より深刻な脆弱性が生じます。
- 非決定論的かつ予測不可能な自動化: 従来のソフトウェアは事前に定義されたワークフローに従いますが、AI エージェントは高レベルの目標に基づいて動的にステップを決定し、ツールを呼び出します。この非決定論的な性質により、到達可能な状態の推論、望ましくない動作の列挙、システムの安全性の形式的検証が困難になっています。
- 既存のセキュリティメカニズムとのミスマッチ: 従来のセキュリティ（サンドボックス、権限管理など）は、人間のユーザーを前提とした設計や、狭い範囲で決定論的な動作を前提としています。AI エージェントは機械の速度で権限を行使し、自律的に行動するため、既存の防御策では不十分です。
- マルチエージェントシステムの複雑性: 複数のエージェントが協調する場合、暗黙的な委任（Confused Deputy 問題）や権限の昇格、共有状態を介した攻撃の伝播など、単一エージェントにはない新たなリスクが発生します。
2. 手法と分析アプローチ (Methodology)
本論文は、Perplexity が数百万人のユーザーおよび数千の企業向けに運用している汎用エージェントシステムの運用経験と、研究データを基に、以下のアプローチで分析を行っています。
- 脅威モデルの構築: CIA（機密性、完全性、可用性）の観点から、エージェントシステム特有のリスクを特定。
- 攻撃面のマッピング: ツール、コネクタ、ホスティング境界、マルチエージェント協調など、システム全体の攻撃対象領域を特定。
- 階層的防御の提案: 入力レベル、モデルレベル、システムレベルの 3 層構造による防御策（Defense-in-Depth）を提案し、各層の成熟度と限界を評価。
- 実証事例の分析: OpenClaw（オープンソースエージェントプラットフォーム）などの具体例を用いて、アーキテクチャ選択がセキュリティに与える影響を分析。
3. 主要な貢献 (Key Contributions)
A. 固有の脅威と脆弱性の特定
- 間接プロンプトインジェクション (Indirect Prompt Injection): エージェントが取得した信頼できないコンテンツ（Web ページ、メール、カレンダー等）に悪意のある指示を埋め込む攻撃。LLM は信頼できる指示と信頼できないデータを区別できないため、エージェントの行動を乗っ取られます。
- 混乱した代理人 (Confused Deputy) 問題: ユーザーの代理として動作する外部エージェントが、操作され、より高い権限を持つ内部エージェントに意図しない操作を実行させる脆弱性。
- カスケード障害: 長期的なワークフローにおいて、単一コンポーネントの失敗が連鎖し、システム全体の可用性を損なうリスク。
B. 階層的防御アーキテクチャの提案
セキュリティを単一の対策ではなく、以下の 3 層で構成する「防御の深さ（Defense-in-Depth）」を推奨しています。
- 入力レベルの防御 (Input-Level Defenses):
- プロンプトインジェクションの検出、悪意のあるコンテンツの除去、入力の変更（Spotlighting など）。
- 課題: 偽陽性（False Positive）の多さ、計算コスト、リアルタイム処理の難しさ。
- モデルレベルの防御 (Model-Level Defenses):
- 指示の階層構造（System > User > Assistant）の強化、埋め込みレベルでの役割の区別。
- 課題: LLM 自体にコードとデータの厳密な分離メカニズムがなく、学習された慣習に過ぎないため、確実な保証にはならない。
- システムレベルの防御 (System-Level Defenses):
- サンドボックス実行: 不確実なコードやツールを隔離された環境で実行。
- 決定論的な最終防衛線 (Deterministic Last Line of Defense): LLM の出力に関わらず、許可リスト/禁止リスト、レート制限、正規表現検証など、検証可能な従来のコードで重要なアクションをブロックする。これが最も成熟しており、信頼性の高い層である。
C. マルチエージェントおよびアーキテクチャに関する知見
- エージェントのアーキテクチャ（ツールの選択ロジック、共有ワークスペース、プラグイン供給連鎖）がセキュリティ特性を決定づける。
- 分散型権限管理の難しさと、マルチエージェント間での権限昇格リスクを指摘。
- ホスティング環境（クラウド、オンプレミス、エッジ）によって、攻撃対象領域（ネットワーク露出 vs 内部設定リスク）が変化する。
4. 結果と評価 (Results)
- 単一防御の限界: 入力検出やモデルの堅牢化だけでは、適応的な攻撃に対して十分な保護を提供できないことが確認された。
- 決定論的制御の重要性: LLM の非決定論的な性質を補完するため、ツール呼び出しの許可リストや人間による確認（Human-in-the-loop）など、検証可能な決定論的制御層が不可欠である。
- ベンチマークの不足: 現在のセキュリティ評価は静的なテストスイートに依存しており、動的で適応的な敵対者（Adversary）を想定した評価が不足している。
- 標準化の遅れ: MCP や A2A などの通信プロトコルは存在するが、委任制御や権限管理などの高次なセキュリティ課題に対する規定は未成熟である。
5. 意義と提言 (Significance)
本論文は、AI エージェントのセキュリティを確立するための重要な指針を提供しています。
- NIST/CAISI への提言:
- レイヤード防御の参照アーキテクチャの開発。
- 動的で適応的なセキュリティベンチマークの確立（静的テストではなく、リアルな多段階ワークフローでの評価）。
- アクセス制御モデルの研究：従来の RBAC（ロールベースアクセス制御）に、リスク適応型アプローチを組み合わせた、エージェント特有の権限管理モデルの確立。
- 人間とエージェントのガバナンス: 過度な確認要求によるユーザー疲労を防ぎつつ、リスクに応じた自律性を許容する「リスク認識型自律（Risk-aware autonomy）」の手法開発。
- 業界への影響: エージェント開発者が、モデル能力だけでなく、アーキテクチャ、デプロイ方法、ホスティング環境を総合的に評価し、セキュリティを設計に組み込む必要性を強調しています。
結論として、AI エージェントのセキュリティは、確率的な AI モデルの特性を前提としつつ、従来のセキュリティ原則（最小権限、完全な仲介、防御の深さ）を適応的に適用し、特に「決定論的な最終防衛線」を備えたシステム設計が不可欠であると述べています。