このテーマを今提示する理由
AIエージェントが単独でAPIを呼び出し、ファイルを読み書きし、外部サービスへ命令を送る「自律型AI」の業務利用が急拡大しています。その一方、権限設計の甘さに起因するインシデント報告も増えています。OWASP LLM Top10（2025年版）では「Excessive Agency1（過剰な権限）」が上位リスクとして明示され、エージェントが意図しない操作を自律実行するリスクが業界共通の課題として認識されるようになりました。今週は、安全なエージェント設計の共通言語となりつつある10の原則を整理します。
10原則の解説
原則1：最小権限
エージェントに付与する権限は、タスク完了に必要な最小限にとどめます。「とりあえず管理者権限」は後からはく奪しにくく、侵害時の被害範囲を最大化します。権限付与前に「このエージェントが絶対に触らないリソース」を明示的にリストアップする習慣が有効です。
原則2：タスクスコープ限定
単一セッションで使える権限をそのタスクのスコープ（例：「受注データの読み取りのみ」）に絞ります。汎用サービスアカウントを使い回すと、一つのエージェントが侵害された際に全データへの横展開が可能になります。
原則3：人間承認ゲートの設置
削除・送信・決済など不可逆・高インパクトな操作には、自律実行を許可せず必ず人間の承認を挟む設計にする必要があります。LangGraphやOpenAI Swarmといったフレームワークでは「interrupt」ステップとして実装できます。エラーより停止を選ぶ（fail-safe）設計思想が基本です。
原則4：権限の時間制限
エージェントに発行するトークン・APIキーには有効期限を設けます。長命なクレデンシャルは漏洩後の被害が長引くため、タスク単位または日次でローテーションする運用が求められます。OAuth 2.0のアクセストークン有効期間を短く設定するだけでも効果があります。
原則5：読み取りと書き込みの分離
読み取り専用エージェントと書き込み可能エージェントを別ロールとして定義します。情報収集フェーズと実行フェーズを明確に分けることで、プロンプトインジェクション2攻撃でエージェントが「読んで即書き換える」サイクルに乗るリスクを下げられます。
原則6：ツール呼び出しの監査ログ必須化
エージェントが呼び出したツール名・引数・実行結果・呼び出し元セッションIDを完全にログします。セキュリティ運用の観点からは、エージェントのツール呼び出しはユーザー操作ログと同等の記録義務があると考えるべきといえます。ログがなければ事後調査も改善も不可能です。
原則7：サンドボックス実行環境
エージェントのコード実行・シェル操作は隔離環境（コンテナ・仮想マシン等）で行います。ホスト環境への直接アクセスを許すと、悪意ある入力から生成されたコードがシステム破壊に直結するリスクがあります。gVisorやFirecrackerのような軽量サンドボックス3が選択肢です。
原則8：ロール別エージェント分離
「調査エージェント」「承認エージェント」「実行エージェント」など機能ごとに別エージェントID・別権限セットを割り当てます。単一の万能エージェントは攻撃面を最大化し、侵害時の爆発半径も最大になります。
原則9：シークレット管理の外部化
APIキー・パスワードなどはAWS Secrets ManagerやHashiCorp Vaultなどの専用ストアに格納し、プロンプト・コード・環境変数にハードコードしません。LLMのコンテキストウィンドウにシークレットが入り込むと、ログや外部ツール経由で漏洩するリスクがあります。
原則10：異常行動の検知と自動遮断
通常オペレーションを定義し、逸脱したツール呼び出しパターン（深夜の大量ファイルアクセス、普段呼ばれないAPIへの突然のリクエスト等）を自動検知・遮断する仕組みを持ちます。人間が気づく前にシステムが止める設計が理想です。SIEMへの統合や、エージェント専用のポリシーエンジン（例：OPA4）の活用を検討する価値があります。
どう活用するか
この10原則は、次の2つのシーンで活用できます。
- 新規エージェント導入時のレビュー観点として — 設計書・実装方針に対し、10原則を網羅できているかを確認するレビューチェックポイントとして使います。全原則を一度に満たせなくても、どの原則を意図的に後回しにしているか、リスクを受容した根拠を記録しておくことが重要です。
- 既存エージェントの権限棚卸しとして — すでに稼働中のエージェントに付与された権限を棚卸しする際の軸として使います。特に原則1（最小権限）・原則6（監査ログ）・原則9（シークレット管理）の3点から着手すると優先度がつけやすくなります。
一枚要約
自律型AIエージェントの普及により、権限設計の不備が従来のサービスアカウント侵害と同等以上の被害をもたらすリスクが現実化しています。エージェントは「動くコード」ではなく「自律的に意思決定するアクター」として権限設計を考える必要があります。最小権限・監査ログ・シークレット外部化の3点から即座に着手し、新規エージェント導入時はこの10原則をレビュー基準として組み込むことを推奨します。
今日着手できる3アクション
- シークレットのハードコード確認：既存のエージェントコードリポジトリで `grep -rn “sk-\|api_key\|password” .` を実行し、クレデンシャルが直書きされていないか確認します。発見した場合は即座に当該キーをローテーションし、AWS Secrets Manager（`aws secretsmanager create-secret`）やGitHub Secretsへの移行を計画します。
- OWASP LLM Top10の「Excessive Agency」を読む：OWASP LLM Top10 公式サイトにアクセスし、LLM08（Excessive Agency）の項目を精読します。対策のベースラインとして社内のエージェント設計ガイドに引用できる粒度です。
- 稼働中エージェントのIAMロール棚卸し：AWSを使用している場合は `aws iam list-roles –query ‘Roles[?contains(RoleName, `agent`) || contains(RoleName, `bot`)]’` でエージェント用ロールを抽出し、`aws iam list-attached-role-policies` でアタッチ済みポリシーを確認します。「AdministratorAccess」や「PowerUserAccess」が付いているロールがあれば即座に見直しの対象です。
AI×セキュリティの観点
AIエージェントが普及することで、攻撃者は「人間を騙す」フェーズを省略し、エージェント自体を踏み台にする手法に移行しつつあります。プロンプトインジェクション攻撃でエージェントに悪意ある命令を注入し、正規の権限を使って内部システムを操作する「間接インジェクション」は、従来のSQLインジェクションと構造的に近く、対策なしで導入したエージェントは格好の標的になります。防御側からは、EU AI Actが高リスクAIシステムに求めるログ保持・人間監視要件が原則6・3と直接接続しており、規制対応と技術的安全性が一体で求められる時代に入っています。
次に読むべきトピック
- OWASP Top 10 for LLM Applications（公式） — Excessive Agency（LLM08）を含むLLMリスクの業界標準リスト
- NIST Artificial Intelligence — AI Risk Management Framework — AIシステムのリスク管理フレームワーク。エージェント設計のガバナンス軸として参照できます
- HashiCorp Vault ドキュメント — シークレット管理の外部化（原則9）を実装する際の実践的リファレンス
用語ミニ解説
- Excessive Agency（過剰な権限） — AIエージェントが必要以上の権限を持つことで、誤作動・侵害時に広範な被害が生じるリスク。OWASP LLM Top10（2025年版）で上位に挙げられている。 ↩
- プロンプトインジェクション — 外部入力（Webページ・メール・ドキュメント等）にLLMへの命令を埋め込み、エージェントの動作を乗っ取る攻撃手法。間接型（Indirect Prompt Injection）は人間を介さず自動で実行される点が危険。 ↩
- サンドボックス — 本番環境から隔離された実行環境。エージェントが生成・実行するコードをホストシステムに影響させないための技術的分離策。 ↩
- OPA（Open Policy Agent） — ポリシーをコードとして管理するオープンソースのポリシーエンジン。エージェントのツール呼び出し可否をポリシーとして定義・強制するために活用できる。 ↩
- Human-in-the-Loop — 自動化プロセスの特定ステップに人間の判断・承認を組み込む設計思想。高インパクト操作を自律実行させない安全弁として機能する。 ↩
コメント