🛡️

AI Boundary Layer: AIエージェントの脅威モデル

に公開
AI
AIエージェント
tech

AIエージェントの脅威モデル

前提

AIエージェントは従来のソフトウェアとは本質的に異なる脅威特性を持つ。ただし、多くの脅威は「信頼境界を超えたコード実行」という古典的問題でもあり、従来の対策が応用可能な領域も存在する。

本文書では、AIエージェント特有の脅威をAI Boundary Layer（境界層） の積層構造として体系化する。

1. AIエージェント特有の根本問題：不変性の欠如

従来のソフトウェアとの決定的な違い

従来のソフトウェアセキュリティは決定論的な前提に立っていた：

  • 関数 f(x) は常に f(x) = y を返す
  • 同じ入力には同じ出力
  • 検証可能性（verifiability）が担保される

AIエージェントではこの前提が崩壊する：

要因 影響
出力の確率的揺らぎ 同じプロンプトでも異なる結果
モデル更新による非互換 昨日安全だったものが今日危険に
外部状態への依存 MCP、検索結果等で挙動が変化
コンテキスト依存性 会話履歴により判断が変わる

セキュリティ上の含意

  • 脅威分析が安定しない: 「この入力は安全」という判定が時間的に不変ではない
  • 回帰テストの限界: 従来のセキュリティテストが機能しない
  • 認証・認可の前提崩壊: 「このエージェントは信頼できる」という判定自体が揺らぐ

これがAIエージェントセキュリティの根底にある困難であり、以降の全ての議論の前提となる。

2. 脅威の二軸構造：ベクトルと権限

AIエージェントへの脅威は、直交する二つの軸で理解できる：

                    権限（できること）
                         ↑
                         │
        低権限だが         │      高権限かつ
        方向を変えられる    │      方向を変えられる
                         │      ⇒ 最も危険
    ─────────────────────┼─────────────────────→ ベクトル
        低権限かつ         │      高権限だが        （行動の方向性）
        方向も固定         │      方向は固定
        ⇒ 最も安全         │
                         │

ベクトル（方向性）を変える脅威

  • プロンプトインジェクション: 行動目標の書き換え
  • マルチエージェント干渉: 他エージェントからの汚染
  • コンテキスト汚染: 会話履歴や外部データによる誘導

権限（能力）を与える要素

  • MCP: ツール実行能力
  • OSアクセス: ファイル、プロセス、環境変数
  • ネットワークアクセス: LAN、インターネット

二軸の相互作用

ベクトル単体では致命傷にならない。エージェントの方向性を変えても、権限がなければ実害は限定的。

権限単体も即座には危険ではない。正しい方向に向いている限り、権限は正当に使われる。

両者が組み合わさると壊滅的になる：

プロンプトインジェクション（ベクトル変更）
    ↓
MCP経由でのツール悪用（権限行使）
    ↓
ホスト/ネットワークへの侵害
    ↓
データ流出 / 第三者攻撃

この構造から、防御戦略はベクトルの固定化と権限の最小化の両面が必要となる。

3. モデル特性に起因する脅威：攻撃者不在の攻撃

AI固有の特性

特性 説明
幻覚（Hallucination） 確信を持って間違える
推論過程の非透明性 なぜその結論に至ったか不明
説明可能性の欠如 事後的な検証が困難
忠実性の低下 指示に従っているつもりで逸脱

「攻撃者不在の攻撃」

これらは直接的な脆弱性ではないが、攻撃面の拡大に寄与する。

特に危険なのは幻覚 × 権限の組み合わせ：

  • 敵意がなくても幻覚で破壊的コマンドを発行できる
  • 存在しないAPIを呼ぼうとして予期しない副作用を起こす
  • 「攻撃者」が存在しないため、従来の脅威モデルで捉えられない
幻覚による誤判断
    ↓
MCP経由で破壊的コマンド発行
    ↓
システム破壊（攻撃者不在）

防御上の含意

  • インジェクション対策だけでは不十分
  • 権限の最小化が幻覚リスクへの防御にもなる
  • 破壊的操作には追加の確認層が必要

4. AI Boundary Layer（境界層）モデル

AIエージェントのセキュリティは、4つの境界層の積層構造として理解できる：

┌─────────────────────────────────────────┐
│         External Boundary               │ ← インターネット、LAN
│              (Network)                  │
├─────────────────────────────────────────┤
│         Runtime Boundary                │ ← OS、Docker、プロセス
│           (Host/Runtime)                │
├─────────────────────────────────────────┤
│          Tool Boundary                  │ ← MCP、関数呼び出し
│              (MCP)                      │
├─────────────────────────────────────────┤
│         Prompt Boundary                 │ ← role、コンテキスト
│           (LLM I/O)                     │
└─────────────────────────────────────────┘

各境界層での防御が、上位層への攻撃伝播を防ぐ。

5. Prompt Boundary（プロンプト境界）

本質

  • 様々な攻撃の起点となる、最も根本的な脆弱性
  • 原理的限界: 「正規の指示か悪意ある指示か」の判定は、意図の解釈を要するため、決定不能問題に近い
  • 入力検証・出力フィルタリングは2023年以降ほぼ進歩しておらず、これは怠慢ではなく原理的限界を示唆

roleの境界としての機能

role 特性 リスク
system インジェクション時に最も深刻 徹底した透明化が必須
user 正規/悪意の判別が本質的に困難 最も取り扱いが厄介
assistant AI出力として明確 出力汚染のリスク
tool ツール結果として文脈的に明確 指示オーバーライドへの耐性あり

現実的な防御アプローチ

  • ガラス張り（透明化）が最も誠実なアプローチ
  • 事前検出より**事後検証可能性（オブザーバビリティ）**を重視
  • 特化型エージェント設計により、正規用途外の指示を判別しやすくする

6. Tool Boundary（ツール境界 / MCP）

本質

  • 現時点で最も危険な攻撃面
  • ベクトル変更と権限行使を接続する層

構造的問題

  • 配布方法の脆弱性: 監査可能性が低く、サプライチェーン攻撃への耐性がない
  • 過剰な権限設計: デフォルトでOSレベルのフルアクセスが可能
  • プラクティスの未確立: Zero Trustの概念適用が必要だが、標準化されていない

対策方針

  • 認証: バージョン含めて設定ファイルに定義されたものだけを使用
  • 認可: エージェント毎にMCPクライアントを割り当て、pick/omitによる割当制限
  • ライフサイクル管理: MCPサーバーを環境内に立ち上げない
  • Capability-based security: 必要な権限のみを明示的に付与

7. Runtime Boundary（ランタイム境界）

攻撃面

  • エージェントが呼ぶツールを通じたホストへのアクセス
  • 対象: OS、Dockerランタイム、言語別ランタイム、エージェントFW自体
  • 特に危険: 環境変数、ファイルシステム、プロセスI/O

トレードオフ

  • ランタイムアクセスを完全遮断 → 生成のみ可能、実用性なし
  • ランタイムアクセスの必要性は非逆進的（今後も高まる一方）

対策

  • 従来のサンドボックス技術が応用可能
  • コンテナ化、権限分離、プロセス隔離

8. External Boundary（外部境界）

問題の本質

外部アクセスの種類やリスクについて、開発者間で明確な認識共有がされていない

アクセス種別とリスク

種別 必要性 リスク
LLMプロバイダーへのリクエスト 必須 機密情報の意図しない送信
LAN内他ホストへのアクセス ツール経由 攻撃例として既に顕在化
インフラ内マネージドサービス ツール経由 同上
インターネットアクセス 一部FWで暗黙的に許可 リスク高い

脅威モデルとしての特性

  • 完全に新しい脅威モデルであり、ベストプラクティスが存在しない
  • 従来の境界防御モデルでは対応困難
  • 本質的にネットワークアクセス自体が脅威度高い

9. 防御策の分類

積極的防御（効果限定的）

対策 現状 限界
入力検証 進歩停滞 意図判定の原理的困難さ
出力フィルタリング 同上 同上
プロンプトエンジニアリング 一定の効果 不変性の欠如により不安定

消極的防御（現実的なアプローチ）

対策 効果
オブザーバビリティ（ガラス張り） 事後検証、異常検知
監査ログ フォレンジック、責任追跡
権限最小化 被害範囲の限定、幻覚リスク軽減
サンドボックス化 境界層間の隔離強化

認可設計

  • Capability-based securityの適用
  • エージェント毎の権限定義
  • 動的な権限昇格の制御

10. Human-in-the-Loopの位置づけ

本質

  • 技術的セキュリティ対策ではない
  • 社会実装上の妥協点（法的・社会的責任の帰属先確保）

問題点

  • AIエージェントの最終目標が完全自律である以上、過渡期の手段に過ぎない
  • 責任主体のすり替えであり、本質的な防御にはならない
  • 「セキュリティ対策です」として売ることの欺瞞性

適切な認識

  • 技術的限界を社会的に補完する仕組み
  • セキュリティではなくガバナンスの領域

まとめ

AIエージェント脅威の本質

  1. 不変性の欠如が従来のセキュリティモデルを根底から覆す
  2. 脅威はベクトル（方向性）× 権限（能力） の二軸で理解する
  3. 攻撃者不在の攻撃（幻覚×権限）という新しい脅威カテゴリが存在する

AI Boundary Layerによる防御

境界層 主な脅威 防御方針
Prompt インジェクション 透明化、オブザーバビリティ
Tool (MCP) 権限濫用 Zero Trust、Capability-based
Runtime ホスト侵害 サンドボックス、権限分離
External データ流出、横展開 ネットワーク分離、監査

設計原則

  1. ベクトルの固定化: 特化型設計、用途の明確化
  2. 権限の最小化: 各境界層での権限制限
  3. ガラス張り: 事後検証可能性の確保
  4. 境界層の隔離: 攻撃チェーンの遮断

未解決の課題

  • ベストプラクティスは未確立
  • 不変性の欠如に対する根本的解決策はない
  • 継続的な知見の蓄積と共有が必要

Discussion