AIエージェントは、試験導入から本番へ進むほど接続先と権限が増えます。読み取りだけだったメール連携へ送信権限が加わり、一時的な管理scopeが残り、担当変更後も例外が継続する。これが権限ドリフトです。対策は初回のleast privilegeだけでは足りません。「付与した理由」「実際に使った権限」「継続を承認した人」「失効日」を同じ台帳で定期確認する必要があります。
人・エージェント・接続先を分ける
権限台帳には、依頼した利用者、実行するエージェント、接続する業務システム、認可方式、scope、環境、有効期限を記録します。利用者本人の権限と、エージェントサービスの権限を一行にまとめません。代理実行では「誰のために」「どの実行体が」「何へ」アクセスしたかを監査できる形にします。
NIST SP 800-207は、ネットワーク位置だけで暗黙に信頼せず、resource accessごとに主体と装置を評価する考え方を示します[1]。AIエージェントでも、社内ネットワークにあることを広い権限の理由にしません。MCPやAPI接続の追加時には、目的、入力、出力、副作用、承認者を登録します。
付与権限と利用権限を比較する
Microsoftは、unused permissionやより小さくできるreducible permissionをoverprivilegedとし、定期監査と撤回を推奨しています[2]。台帳のscopeと、一定期間の実行ログで実際に呼ばれたoperationを比較します。
使われていない権限が見つかっても、直ちに障害とみなして放置しません。季節業務、緊急時、月次処理など利用周期を確認し、必要なら短命の昇格や申請式アクセスへ置き換えます。「将来使うかもしれない」は恒久権限の根拠にせず、再付与の手順を整えます。
ログは成功呼び出しだけでなく、拒否、承認待ち、scope不足、管理者上書きを含めます。エージェントが権限不足を理由に別toolへ迂回していないかも確認します。promptやAIの説明だけを監査根拠にせず、認可サーバーと接続先の記録を正本にします。
レビュー対象と判断者を固定する
レビューは、所有者、業務責任者、セキュリティ担当の役割を分けます。所有者は用途が残っているか、業務責任者は副作用を許容するか、セキュリティ担当はscope・token・ログを確認します。Microsoft Entraのaccess reviewsも、groupやapplication accessについてreviewerが継続可否を判断し、未回答時の処置を設定できます[3]。
判断は「継続」「縮小」「期限付き継続」「失効」「不明」に分けます。不明を自動承認にしない一方、即時削除で業務を壊さないため隔離期間と再確認期限を設定します。例外は理由、期限、代替統制を必須にします。
変更イベントで臨時レビューする
四半期などの定期レビューに加え、tool追加、scope変更、モデル更新、owner異動、token漏えい、重大インシデント、利用停止をトリガーにします。OAuth token exchangeを使う場合も、発行時のaudience、scope、subjectと、現在の利用目的が一致するか確認します[4]。
特に管理者同意で全利用者へ付与された権限は、個人の同意画面だけで可視化できません。管理者同意の記録、サービスプリンシパル、資格情報の期限、利用者別の実行ログを結びます。MCP serverや外部toolの更新で要求scopeが増えたときは、差分を自動承認せず再審査します。
失効をテストしてから完了にする
レビュー表で「削除」と書くだけでは権限は残ります。consent撤回、role削除、token無効化、secret rotation、接続設定削除を実行し、エージェントが操作できないことをnegative testで確認します。監査ログには、誰が、何を、なぜ、いつ失効し、どのテストで確認したかを残します。
関連するMCP OAuth認可、代理実行ID、tool検証と認可も参照してください。
AIエージェントの権限レビュー設計を相談する
最小のレビュー証跡
レビューごとに、対象エージェント、owner、接続先、現行scope、直近利用日、利用operation、判断、理由、期限、実施した変更、確認テストを残します。表の承認だけでなく、identity providerと接続先の現在値を取得して差分を確認します。台帳と実設定が違う場合は、どちらかを推測で正本にせず、発行元と実行ログを突き合わせます。
緊急権限は通常権限と別にし、発行時点で自動失効時刻を持たせます。インシデント対応後に「念のため残す」のではなく、必要になれば再申請できる経路を用意し、恒久化を例外審査へ送ります。
適用限界
権限棚卸しは、prompt injection、脆弱なtool実装、漏えい済みcredentialを単独で解決しません。認証、入力検証、runtime分離、監視、インシデント対応と組み合わせます。
一次情報と確認範囲
確認日：2026年9月18日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。