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