8月21日、NVIDIAが「Where Security Fits in an AI Agent Stack」と題した記事を公開した。AIエージェントスタックの各レイヤーにセキュリティ制御をどう配置すべきかを詳しく論じた内容で、「モデルやハーネスの振る舞いへの期待」ではなく「インフラによる強制」を中心に据えるべきだという設計原則を打ち出している。
なぜ今、エージェントセキュリティなのか
記事は、長時間動作するエージェントが意図した境界を超えて動作する事例が増えていることを問題の出発点として置いている。モデルのガードレールを緩めた状態でエージェントを運用した場合、「創造的に問題を解く能力」が元の指示では想定していなかった経路を探り当てることにも使われる、という構造的な問題だ。
記事が直接言及している事例や参照先の詳細については元記事を確認してほしいが、この問題意識はOpenAIやAnthropicが公開してきたエージェントの安全性に関する研究、および英国政府傘下のAI Security Institute（現DSIT）が取り組むフロンティアモデルの評価活動とも文脈を共有している。
いずれも「モデルを賢くすること」と「モデルを安全に制御すること」は別の問題だ、という認識の上に立っている。
記事の核心：「行動制御」と「インフラ制御」の区別
この記事が最も重要な論点として打ち出しているのが、2種類の制御の明確な区別だ。
- 行動制御（Behavioral controls）：モデル、エージェント、ハーネスがどう動くかを「誘導」する。プロンプト、モデルのセーフガード、ハーネスのロジックがこれにあたる。
- インフラ制御（Infrastructure controls）：エージェントが「何をできるか」を決定する。アイデンティティの管理、ポリシーの強制、失敗の封じ込め、監査ログがこれにあたる。
記事の結論は明確だ。
ハーネスはエージェントが試みることを誘導する。インフラはエージェントができることを制御する。両方必要だが、権威を持つのは後者だけだ。
行動制御は「モデルがどう振る舞うか」という仮定の上に成り立つ。モデルが改善されるにつれてその仮定は古くなる。設計上変更可能なレイヤー（ハーネス）に、変更されては困るセキュリティ保証を持たせるのはアーキテクチャ上の欠陥だ、というのが記事の主張だ。
この「ポリシーをスタックのどこに置くか」という問いこそが、本記事全体の軸になっている。
エージェントスタックの5層構造
記事はエージェントスタックを以下の5層に整理している。各レイヤーの代表例として記事内で挙げられているプロダクト名・プロジェクト名は元記事の記載をそのまま転記しているが、読者は元記事で最新の正確な表記を直接確認することを推奨する。
| レイヤー | 役割 | 代表例（元記事記載） |
|---|---|---|
| Distribution/Product | パッケージ、デフォルト設定 | NVIDIA NIM Agent Blueprints 等 |
| Orchestration（メタハーネス） | 複数ハーネスの選択・調整 | LangGraph, CrewAI 等 |
| Agent Harness | モデルをエージェントに変換（ループ・ツール・セッション管理） | Claude Code, Codex 等 |
| Secure Runtime | 隔離・アイデンティティ・ポリシー・監査 | NVIDIA OpenShell |
| Inference Data Plane | モデルサービング・ルーティング | NVIDIA Dynamo |
重要なのはセキュリティ境界の置き場所だ。記事が推奨する構造では、オーケストレーターがSecure Runtime（OpenShell）にランタイムの生成とポリシー適用を依頼し、選択されたハーネスはそのランタイム内部で起動する。MCPプロセスやツール、サブエージェントもすべて同じ境界の中で動く。サブエージェントには上限を超えられない「子ランタイム」が委譲される。
エージェントが任意に呼び出しを拒否できる制御は、有効なセキュリティ制御ではない。
よくある設計ミス：6つのセキュリティギャップ
多くのエージェントスタックに共通する欠陥として、記事は以下を挙げている。
- 境界の不明確さ — ポリシーがプロンプト、モデル、ハーネス、インフラに分散し、どれを正とするか不明
- 過剰なアクセス権 — 現在のタスクに不要な長期間有効なクレデンシャルを保持
- 非信頼データによる制御 — ドキュメントやツールの出力が指示として扱われ、エージェントを誘導できる（いわゆるPrompt Injection）
- 制御外の外部効果 — 許可されたAPIが意図しないデータ移動や計算リソースの生成を引き起こす
- 障害の連鎖 — 委任・メモリ共有・ピア呼び出しを通じて一つのミスが連鎖する
- 不完全な監査証跡 — インシデント分析や復旧に耐えられるログが存在しない
4つのセキュリティプロファイル
記事はリスクレベルに応じた4段階のプロファイルを定義している。
| レベル | 想定作業 | 主な制御 |
|---|---|---|
| 1. Isolated | 本番前の開発・使い捨てデータ | 本番クレデンシャル不使用・制限ネットワーク |
| 2. Connected | 承認済みサービスを使う前本番環境 | 短命ID・データマスク・レート制限 |
| 3. Production | 本番システム・データへの変更 | タスクスコープアクセス・高影響操作は人間承認 |
| 4. Adversarial | フロンティアモデル・ガードレール外・レッドチーム | デフォルト拒否通信・自動隔離 |
特筆すべき点として、レッドチームエージェントへの本番アクセスは通常の本番エージェントより広くではなく、狭くすべきと明記されている。この指摘は直感に反するが、評価用エージェントが予期しない経路でシステムへ影響を与えるリスクを封じるための原則だ。
5つの設計原則
「エージェント自身がセキュリティ決定に干渉できないようにする」ための設計原則として、以下が示されている。
- 上位は提案し、下位が決定する — モデル、ハーネス、ツールは自ら権限を付与しない
- ポリシーは境界の下に置く — 境界より上でのポリシー考慮は「助言」にすぎない
- すべての副作用を検査する — ファイル、プロセス、ネットワーク、API、データ操作を網羅
- Just-in-timeアクセス — クレデンシャルは狭く、短命で、即時失効可能に
- 隔離と回復 — エージェントごとに隔離し、迅速にアクセス失効・ロールバック・ログ保全
この5原則を貫く考え方は一貫している。セキュリティ保証をスタックの「上位レイヤー」に依存させない、ということだ。原則2「ポリシーは境界の下に置く」が象徴するように、モデルやハーネスがポリシーを「考慮」することは許しても、「決定」することは許さない設計が求められる。
NVIDIAはセキュアなエージェントランタイムとしてNVIDIA OpenShellをオープンソースで公開している。また、AIインシデントの知見を業界で共有する枠組みとして、Open Secure AI AllianceのSAFE提案へのコントリビューションも呼びかけている。
詳細はWhere Security Fits in an AI Agent Stackを参照していただきたい。
