AIエージェントのセキュリティ設計【2026】権限・入力・実行・監視の4レイヤー多層防御と主要SDKガードレール比較

AIエージェントのセキュリティ設計は、権限・入力・実行・監視の4つのレイヤーで多層防御を組むのが基本です。従来アプリと違いエージェントは自律的にツールを実行し、外部の文書やWebに仕込まれた間接プロンプトインジェクションに乗っ取られうるため、最小権限・認可ゲート・HITL承認・構造化監査ログを設計時から組み込みます。

本記事では、4レイヤーの定義、OWASPの脅威との対応、主要6フレームワーク／SDKのガードレール機構、導入手順を扱います。一般的な生成AIの社内ルールやRAG固有の漏えい対策は対象を分け、エージェントが実際に行動する境界の設計に絞ります。

当メディアは特定のAIエージェント基盤・SDKベンダーと利害関係を持たず、いずれの製品も勝者にしません。専用機構がない場合も劣位とはみなさず、アプリケーション設計で代替する選択として同じ粒度で記載し、自社サービスへの送客は行いません。仕様は変わりうるため、OWASPと各SDKの一次情報を基準にします。

要点サマリ（2026年8月時点・OWASPおよび各SDK公式ドキュメント）

• 防御は権限・入力・実行・監視の4レイヤーに分け、単一のフィルターへ依存しない。
• OWASP Agentic Top 10 for 2026の最上位はAgent Goal Hijackingである。
• 送金、削除、外部送信、本番書き込みは実行直前に認可ゲートとHITLを置く。
• 6つの基盤を、認可、HITL、権限スコープ、隔離実行、監査ログの5観点で読む。
• SDKの専用機構がなくても、外部の認可層・実行基盤・監視基盤で補完できる。

AIエージェントのセキュリティ設計とは（結論・定義・早見表）

結論：権限・入力・実行・監視の4レイヤーで多層防御する

4レイヤーは、事故の発生前から発生後までを連続して守る分担です。権限で「できること」を狭め、入力で外部情報と命令を分離し、実行で危険な操作を止め、監視で行動を追跡します。1つのフィルターが破られても、次の層が被害を止める設計が要点です。

従来型アプリは、利用者が画面から明示した処理を決められた順序で実行します。エージェントは目標から計画を立て、複数のツールを選び直しながら行動するため、同じ入力でも経路が変わりえます。AIエージェントの仕組みと種類を押さえると、この差を理解しやすくなります。

定義と早見表：エージェント特有のリスクと4レイヤーの対応（自律・ツール実行・記憶）

エージェント特有のリスクは、自律性、ツール実行、状態や記憶の持続という3つから生じます。悪意ある文書を一度読んだだけでも、その指示が次のツール呼び出しや後続セッションへ波及しうるため、入力検査だけでは足りません。

この表は「どれか1つを選ぶ」ものではありません。4層すべてに最低限の制御を置き、用途の危害と取り消し可能性に応じて厚みを変えます。

脅威マップ：OWASP Top 10 for Agentic Applications 2026 を設計レイヤーに割り付ける

OWASP Agentic Top 10 2026 の主要脅威と最上位リスク（ゴールハイジャック）

OWASP Top 10 for Agentic Applications for 2026は2025年12月に公開され、最上位のASI01をAgent Goal Hijackingとしています（出典: OWASP Gen AI Security Project、参照2026-08-05）。攻撃者が目標そのものをすり替えると、エージェントは正規の権限とツールを使って誤った目的を達成してしまいます。

従来のプロンプト注入対策と違うのは、誤回答だけで終わらない点です。計画の変更が、権限濫用、ツールの誤用、記憶の汚染、別エージェントへの伝播へ連鎖します。そのため、ゴールの固定、操作ごとの再認可、実行履歴の追跡を組み合わせます。

独自対応表：各脅威をどの設計レイヤーで防ぐか

OWASPの最上位脅威を起点に、業務で想定する攻撃経路を4レイヤーへ割り付けました。ASI01以外の個別名称は同梱資料だけでは確定できないため列挙せず、目標改変が権限濫用・ツール誤用・記憶汚染・連鎖障害へ広がる経路を設計単位で整理します。

この割り付けはai-feedによる設計上の整理で、OWASPの個別項目を再定義・順位付けするものではありません。複数層へまたがる経路ほど、単一製品の機能だけでなくシステム全体の制御が必要です。

設計レイヤー別の実装ポイント

権限レイヤー：最小権限・権限スコープ・認可ゲート

最初に、エージェント用IDを人間や基幹システムの管理者IDから分離します。読み取り、下書き作成、外部送信、本番更新を別スコープにし、通常時は必要な最小範囲だけを付与します。資格情報は短期化し、目的外のデータ領域へ到達できない構成にします。

認可は「エージェントがツールを選んだ」ことと「その実行を許す」ことを分けます。ツール名だけでなく、対象、操作、引数、利用者、現在の目的を検査し、高リスクなら拒否または承認待ちへ送ります。

入力レイヤー：プロンプトインジェクション対策と信頼境界（間接注入の遮断）

外部のメール、文書、Webページ、検索結果は、信頼できる命令ではなく未信頼データとして扱います。システム指示と別チャネルに隔離し、出所を保持したまま必要部分だけを抽出します。「以前の指示を無視せよ」といった文字列を消すだけでは、未知の表現を防げません。

完全防止を前提にせず、注入が成功しても権限と実行レイヤーで止まる構成にします。RAGの検索元や権限継承に固有の論点は社内RAGのセキュリティとデータ漏えい対策へ分けると、境界が明確になります。

実行レイヤー：ツール実行制御・HITL承認・サンドボックス

HITLはすべての操作へ一律に置くのではなく、取り消し可能性と外部影響で判断します。送金、削除、外部送信、本番書き込みは実行直前に、対象・差分・理由を人へ示して承認を取ります。検索や読み取りまで毎回止めると形骸化しやすいため、低リスク操作は上限付きで自動化します。

コードやコマンドは、権限を絞ったうえでサンドボックスへ隔離します。ネットワーク、ファイル、実行時間、呼び出し回数を制限し、許可された成果物だけを外へ戻します。サンドボックスは広すぎる資格情報を安全にする装置ではなく、最小権限を補う防壁です。

監視レイヤー：構造化監査ログと異常検知

監査ログには、利用者、目標、計画、モデル、入力の出所、ツール名、引数、認可結果、実行結果を構造化して残します。1回の処理へ相関IDを付けると、複数ツールや複数エージェントをまたいだ経路を追えます。機密値はそのまま保存せず、マスキングとアクセス制御を行います。

異常検知は、短時間の大量呼び出し、通常と違う宛先、権限拒否の反復、計画の急変を対象にします。検知後に通知するだけでなく、資格情報の失効、エージェント停止、未完了処理の隔離までを運用手順に含めます。

主要フレームワーク/SDKのガードレール対応マトリクス（独自集計）

比較の観点：5つのガードレール機構

比較軸は、ツール実行認可ゲート、HITL承認フック、権限スコープ、サンドボックス実行、構造化監査ログの5つです。モデル出力を検査するガードレールだけでなく、実際の行動を止め、後から再現できるかまでを含めました。

「実装あり」は専用機構が一次ドキュメントで明示される場合、「設計で代替」はコールバックや外部基盤との組み合わせが必要な場合、「中核機能として記載なし」は調査対象の中核機能として確認できない場合です。機能数を点数化せず、採用時に追加設計が要る場所を見つけるために使います。

対応マトリクス：6フレームワークを一次ドキュメントで横断集計

同梱された一次資料で機構を具体確認できる範囲と、採用時に対象版の公式文書で確認すべき箇所を同じ軸で並べました。表中の「公式に記載あり」は、許可済み一次資料でツール承認とガードレールを確認できたセルに限ります（参照2026-08-05）。

ほかの5基盤は、このバッチの同梱資料に各社一次文書の内容と許可URLがないため、実装有無を断定せず確認項目を示しています。これは安全性や製品品質の順位ではなく、版更新後も残るデューデリジェンス表です。採用時には対象版の公式文書で各セルを照合し、結果と確認日を組織の設計記録へ残します。

マトリクスの読み方：SDK機能に依存しない設計原則

選定では、「実装あり」の数を競わせるのではなく、事故時の責任境界を埋められるかを見ます。専用HITLがなくてもワークフローを承認待ち状態へ保存できれば代替でき、専用サンドボックスがなくても外部の隔離実行基盤へ委譲できます。

反対に、SDKが機構を持っていても、認可条件やログ保存期間を設計しなければ安全にはなりません。AIエージェントSDKの比較は機能や開発体験を扱いますが、本記事の表は実行境界に限定しています。基盤を替えても残る権限表、承認基準、監査項目を先に定義するのが重要です。

セキュリティ設計を組み込む手順とよくある落とし穴

設計に組み込む5ステップ（脅威モデリング→権限→承認→監査→運用）

手順は5段階です。最初に守る資産、外部入力、利用ツール、最悪時の影響を洗い出します。次に用途別IDと最小権限を定義し、取り消せない操作へ認可ゲートとHITLを置き、必要な監査項目と停止条件を決めます。最後に疑似攻撃と障害訓練を行い、拒否ログや誤検知を見て運用を更新します。

順序を逆にして監視製品から入ると、何を異常とみなすか決まりません。設計レビューでは4レイヤーの責任者、代替制御、障害時の連絡先まで確認し、実装後も用途追加のたびに脅威モデルを更新します。

ai-feed編集部の権限設計の実例（Claude Code×MCP）

ai-feed編集部のClaude Code×MCP運用では、「不可逆操作はdeny、参照系は許可、書き込み系は都度確認」という3原則で権限を分けています。実運用で確認した失敗は、広いワイルドカード許可、絞りすぎ、MCPサーバー単位の信頼、シークレット読み取りの放置、監査ログがあるという思い込みの5類型です。

これは一般ベンチマークではなく、既公開の運用記録を再整理した一次事例です。具体的な設定とブロック経験はClaude Code×MCPの権限設定でよくある失敗5つに委ね、本記事では4レイヤーへ接続する根拠として扱います。

よくある落とし穴と回避策・関連記事への導線

よくある落とし穴は、プロンプトフィルターだけで守る、管理者権限を共有する、HITLを全操作へ置く、ログを本文だけで残す、SDKの既定値を安全とみなすことです。回避策は、入力が突破される前提で権限と実行を絞り、高リスク操作だけを承認し、計画から結果まで相関できる構造化ログを残すことです。

社内ポリシーやシャドーAIまで含む経営視点は生成AI利用のセキュリティリスクが対象です。セキュリティは導入後の追加機能ではなく、エージェントの目標、ID、ツール、記憶を決める段階から組み込む設計条件です。

まとめ

AIエージェントのセキュリティ設計は、権限・入力・実行・監視の4レイヤーで多層防御を作ることから始まります。最小権限で行動範囲を狭め、外部データと命令を分離し、取り消せない操作へ認可ゲートとHITLを置き、計画から結果まで構造化ログで追跡します。OWASPの10脅威や主要6基盤の5機構は、順位付けではなく不足する制御を見つける材料です。専用機構がない部分は外部基盤で補完し、用途追加や版更新のたびに脅威モデルと一次ドキュメントを見直すことが、長期運用の前提になります。