Microsoft Entra Agent IDの次段階を解説 休眠エージェント権限が監査論点になる理由
Microsoft Entra Agent IDの方向性から見える監査論点
Copilot導入が進む企業で、次に問題になりやすいのは活用成果だけではありません。むしろ見落とされやすいのは、AIエージェントに与えたIDと権限が、利用停止後も残ることがある点です。
この記事では、Microsoft Entra Agent IDとして打ち出されている方向性を手がかりに、なぜ人アカウント管理では見えにくい「休眠エージェント権限」や不要OAuth同意が監査リスクになりやすいのかを整理します。IAM責任者、Microsoft 365管理者、SecOps担当者、内部監査担当者が、どこから棚卸しを始めるべきかまで分かるようにまとめます。
https://www.microsoft.com/en-us/security/business/microsoft-entra
Copilot導入後に休眠エージェント権限の監査リスクが顕在化しやすい理由
結論から言うと、Copilotや生成AIエージェントは、導入後の運用でもリスクが顕在化しやすいからです。最初は「何ができるか」が注目されますが、時間がたつほど「誰に、どの権限で, いつまで動作を許しているのか」という説明責任が重くなります。
特に企業では、PoCで作ったエージェント、本番化したエージェント、途中で使われなくなったエージェントが混在することがあります。この状態で棚卸しができていないと、監査では「不要な権限が残っていないか」「不要OAuth同意が残っていないか」「承認者は誰か」「停止済みなのになぜアクセス可能なのか」といった質問に詰まりやすくなります。
https://www.microsoft.com/en-us/microsoft-copilot
Microsoftが示す人以外のID管理の方向性
MicrosoftがAgent IDとして打ち出している方向性の重要点は、人間の従業員アカウントとは別に、人以外のID管理を見直す発想にあります。言い換えると、「人ではないが、業務上は何かを実行できる存在」を可視化しようとしているわけです。
従来もMicrosoft Entraでは、アプリ登録やサービスプリンシパル等を通じてワークロードIDを管理してきました。ただ、生成AIの普及で、自然言語から複数システムへまたがって処理する主体が増えると、設定の意味を現場が追いにくくなります。
ここで必要なのは、技術的な識別子を増やすことではなく、業務上の責任の所在を結び直すことです。人ではないIDにも、所有者、スポンサー、利用目的をひも付けて説明できる状態が望ましいです。
https://learn.microsoft.com/en-us/entra/agent-id/
https://learn.microsoft.com/en-us/entra/workload-id/
休眠エージェント権限が放置されやすい理由
本記事では、休眠エージェント権限とは、すでに使われていない、または利用頻度が極端に低くなったAIエージェントに、以前付与したアクセス権が残っている状態を指します。人事異動で担当者が変わった、PoCが終わった、業務フローが別製品へ移った、といった場面で起きやすい問題です。
放置されやすい一因は、エージェントには明確な「退職日」がないことです。人のアカウントなら入退社で見直す契機がありますが、AIエージェントには明確な「退職日」がありません。
その結果、作成時の権限やOAuth同意がそのまま残り、誰も現状を説明できない状態になりがちです。使っていないことと、安全であることは同義ではありません。
たとえば、会議要約用に作ったエージェントがSharePointやTeamsの広い閲覧権限を持ったまま停止していた場合、使っていないから安全とは言えません。認証情報や連携設定が残っていれば、内部統制上は「不要アクセスの存続」と見なされることがあります。
https://www.microsoft.com/en-us/security/business/zero-trust
監査で問われるのは設定の有無ではなく継続管理
監査で本当に問われやすいのは、導入時に設定ルールを作ったかどうかだけではありません。より重要なのは、その後も継続して棚卸しし、不要権限を除去し、例外を記録できているかです。
具体的には、例えば次のような点です。
- そのエージェントの最終実行日を把握できているか
- 保持権限とOAuth同意範囲に承認根拠と所有者があるか
- 停止条件と定期見直しの記録が残っているか
ここで厳しいのは、技術的に設定できていても、運用証跡がなければ説明不十分になりやすい点です。多くの監査では「実装したこと」より、「その状態を管理し続けられること」が見られます。
特にCopilot導入企業では、部門単位で小さなエージェントが増える場合には、中央管理の抜け漏れが発生しやすいでしょう。
https://learn.microsoft.com/en-us/security/benchmark/azure/
棚卸しを始めるときに先に見るべき3種類のエージェント
実務では、すべてを一度に精査しようとすると止まります。まずは対象を3種類に分けると動きやすくなります。
- 本番運用中のエージェント
現在も使われているため影響範囲が大きく、権限過多なら優先的に是正すべき対象です。利用部門、接続先、権限範囲、承認者を1枚で見える化すると整理しやすくなります。
- 停止済みまたはPoC終了済みのエージェント
ここは「消したつもり」の設定残りが見つかりやすい領域です。一例として、無効化、資格情報削除、接続解除、ログ保全の順で確認すると抜け漏れを減らせます。
- 所有者不明のエージェント
監査上、もっとも説明しにくいのがこの層です。誰が作ったか不明、どの業務のためか不明、でも権限は生きているという状態なら、原則は利用実態確認と停止判断を急ぐべきです。
https://learn.microsoft.com/en-us/entra/
AIエージェント増加を前提にした運用ルールの作り方
今後は、1社あたりのAIエージェント数が増える可能性が高まります。すると、個別に善意で管理する方法はすぐ限界に達します。
次段階で必要なのは、エージェントを作る時点から、申請、命名、権限付与、定期見直し、廃止までを運用ルールとして固定することです。
最低限のルールとしては、次のような設計が現実的です。
- 作成時に所有部門と責任者を必須化する
- 強い権限は期限付きにする
- 例として90日や180日ごとに利用実績を確認する
- 未使用なら自動的にレビュー対象へ回す
この運用では、AIエージェントごとに最終実行日、保持権限、OAuth同意範囲、停止条件を並べた休眠権限点検表を作成しておくと、初級の担当者でも確認観点をそろえやすくなります。
これは難しい統制というより、エージェントを「増やしても管理できる状態」にするための土台です。運用ルールを先に決めておくことで、休眠権限の蓄積を防ぎやすくなります。
Copilot時代の監査対応は休眠権限の説明力で差がつく
最後に一言でまとめると、一部では、Copilot時代の監査対応において「AIを使ったか」だけでなく「AIエージェントの権限を説明できるか」も重視されつつあります。特に問題化しやすいのは、使われなくなったエージェントに残り続ける権限や不要OAuth同意です。
今のうちに休眠エージェント権限を棚卸ししておけば、将来の監査対応だけでなく、日常のセキュリティ運用も軽くなります。まずは、AIエージェントごとの最終実行日、保持権限、OAuth同意範囲、停止条件を1枚で確認できる休眠権限点検表の作成から始めると進めやすいでしょう。