この記事は、連載「AI AgentとIdentity」の第1回：概念編です。

生成AIの活用が進み、最近では「質問に答えるだけ」ではなく、AI Agentがメールを読んだり、予定を確認したり、社内システムを操作したりするケースが増えてきました。

例えば、こんなAgentです。

「今日の予定を教えて」
「自分宛てのメールを探して」
「この資料にアクセスできるか確認して」
「毎晩ユーザー情報をチェックして、異常があれば報告して」

ここで、セキュリティを考えるうえで重要な疑問があります。

AI Agentは、いったい「誰の権限」でシステムを操作するのでしょうか？

今回は、Microsoft Entra IDとMicrosoft Graphを例に、AI Agentの権限を整理します。

1. まずは「社員に仕事を頼む」と考えてみる

OAuthやAccess Tokenの話から入ると難しいので、会社の仕事に置き換えてみます。

あなたがアシスタントに「私の予定表を確認して」とお願いしたとします。
この場合、アシスタントにはあなたの代理として、あなたが見られる予定表だけを確認してもらうのが自然です。

一方で、「毎晩、全社員の情報を確認してレポートを作って」という仕事はどうでしょう。
これは特定のユーザーの代理ではなく、システム自身に必要な権限を持たせて自動で実行する仕事です。

AI Agentでも、考え方はほぼ同じです。

2. AI Agentの権限は大きく2パターン

AI AgentからMicrosoft GraphなどのAPIを使う場合、押さえるべきは次の2つです。

① ユーザーの代理として動く

User
  ↓
AI Agent
  ↓
Microsoft Graph

「このユーザーの代わりに操作します」

② Agent自身の権限で動く

AI Agent
  ↓
Microsoft Graph

「Agent自身の権限で操作します」

Microsoftの用語では、それぞれ次のように呼ばれます。

動き方	Microsoftの呼び方	Token上の表れ方
ユーザーの代理	Delegated Permission	`scp`（スコープ）
Agent自身	Application Permission	`roles`（アプリロール）

まずはこの2つを区別できれば十分です。

3. Delegated Permission：ユーザーの代理で動く

Delegatedは「委任」という意味です。
ユーザーから権限を委任されて、Agentがユーザーの代わりに操作するという考え方です。

例えば、ユーザーがAI Agentに「今日の予定を確認して」と依頼した場合です。

User
  │ 「予定を確認して」
  ▼
AI Agent
  │ Userの代理
  ▼
Microsoft Graph
  │
  ▼
Userの予定表

このとき、Agentが自由に全社員の予定表を見られるわけではありません。
実際に操作できるのは、アプリに許可された権限の範囲内で、かつユーザー自身がアクセスできる範囲です。

向いているケース

ユーザー本人のデータを、ユーザーからの指示で操作するチャット型のAgentです。

自分のメールを探す：「昨日、田中さんから来たメールを探して」
自分の予定を確認する：「明日の午後に空いている時間ある？」
自分のファイルを探す：「先週作った提案資料を探して」

4. Application Permission：Agent自身の権限で動く

もう1つがApplication Permissionです。
こちらはユーザーの権限を借りず、Agent自身が持つ権限で操作する方式です。

例えば、夜中に自動で動くセキュリティAgentを考えてみます。

Security Agent
      │ 毎晩自動実行
      ▼
Microsoft Graph
      │
      ▼
情報を収集

夜中なので、Agentに指示しているユーザーはいません。
そのため、Userの権限ではなくAgent自身の権限を使います。

Microsoft Entra Agent IDでは、Agentごとに専用のIdentity（以下、Agent Identity）を持たせることができます。
このように独立して動くAgentは、Autonomous Agentとして整理されており、Agent Identityを主体としてApplication Permissionを利用します。

向いているケース

ユーザーがその場にいなくても動くAgentです。

定期チェック：毎晩ユーザー情報を確認する
セキュリティ監視：定期的に情報を集めて異常を確認する
バックグラウンド処理：ユーザーの操作と関係なく処理を実行する

5. OBOとは？

ここでよく出てくるのが OBO（On-Behalf-Of） です。
名前のとおり「〜の代理として」という意味です。

ただし、Delegated Permissionを使うときにいつもOBOが必要なわけではありません。
ユーザーがサインインしたアプリが、そのままGraph用のTokenを取得できる構成なら、OBOは使いません。

OBOが必要になるのは、ユーザーからAgent宛てのAccess Tokenを受け取り、そのユーザーの代理として下流APIを呼び出す構成です。

User（フロントのアプリ）
 ↓ ① ユーザーのToken（宛先：AI Agent）
AI Agent
 ↓ ② Graph用のToken（宛先：Microsoft Graph）
Microsoft Graph

①のTokenはAI Agent宛てなので、そのままGraphに再利用することはできません。
そこでAI Agentは、①のTokenをEntra IDに渡し、同じユーザーの代理としてGraph用の新しいTokenを取得します。

この仕組みがOBOです。

OBOの流れ

ユーザーがAI Agentに「自分の予定を確認して」と依頼した場合、次のように動きます。

① UserがAI Agentを呼び出す

User
  │ ユーザーのToken（宛先：AI Agent）
  ▼
AI Agent

② AI AgentがGraph用のTokenを取得する（OBO）

AI Agent
  │ ユーザーのToken ＋ Agentの認証情報
  ▼
Microsoft Entra ID
  │ Graph用のToken（Userの代理）
  ▼
AI Agent

③ 取得したTokenでMicrosoft Graphを呼び出す

AI Agent
  ↓
Microsoft Graph
  ↓
Userの予定表

つまりOBOは、User → Agent → APIという複数段の構成で、ユーザーのIdentityを次のAPIへつなげるための仕組みです。

6. OBOは「3つ目の権限」ではない

ここは間違えやすいポイントです。
「Delegated」「Application」「OBO」という3種類の権限があるように見えるかもしれませんが、そうではありません。

Microsoft Graphのアクセス許可は、ユーザー代理で動くDelegated Permissionとアプリ自身で動くApplication Permissionの2種類
OBOは、ユーザーのIdentityとDelegated Accessの文脈を維持したまま、下流API向けのAccess Tokenを取得するための認証フロー

イメージとしては、次のような組み合わせです。

Delegated Permission
        ＋
       OBO（Agent宛てのTokenから下流APIを呼ぶ場合）

7. どちらを選べばいい？

まずは次の質問から考えると整理しやすくなります。

その処理を依頼しているユーザーは、その場にいるか？

     ユーザーがその場にいて、本人の代わりに操作する？
                     │
             ┌───────┴───────┐
            Yes              No（自動処理・定期処理）
             │               │
             ▼               ▼
         Delegated       Agent Identity
   （下流APIを呼ぶなら        ＋
         ＋ OBO）      Application Permission

ユーザーがいる場合

「自分のメールを検索して」「今日の予定を教えて」のようなケースです。
Delegated Permissionが候補になります。
Agent宛てのTokenを受け取ってから、ユーザーの代理で下流APIを呼ぶ構成なら、OBOを組み合わせます。

ユーザーがいない場合

「毎晩自動でチェックする」「定期的にレポートを作る」のようなケースです。
Agent Identity ＋ Application Permissionが候補になります。

実際のシステムでは、もっと複雑なケースもあります。
ただし、最初の整理としてはこれで十分です。

8. Application Permissionには特に注意する

ここからがセキュリティ上とても重要です。
Application Permissionは便利ですが、ユーザー自身のアクセス権には制約されません。
付与したPermissionによっては組織全体のデータへアクセスできるため、影響範囲が大きくなる可能性があります。

User
 ↓
AI Agent（Delegated）
 ↓
アプリの権限 × User本人がアクセスできる範囲

Delegatedでは、アプリに許可されたDelegated Permissionと、サインインユーザー自身のアクセス権の両方に制約されます。
例えばDelegatedのFiles.Read.Allでも、読めるのはそのユーザーが実際にアクセスできるファイルまでです。

AI Agent
 ↓
Application Permission
 ↓
Permissionが対象とする範囲（例：Files.Read.All ならすべてのサイトコレクション）

一方、ApplicationのFiles.Read.Allでは、サインインユーザーなしで、すべてのサイトコレクション内のファイルを読み取ることができます。
付与したPermissionの範囲がそのまま影響範囲になるため、Application Permissionの付与には管理者の同意が必要です。

そこで重要になるのが 最小権限（Least Privilege） です。
Microsoft Graphでも、必要最小限の権限だけを要求することが推奨されています。

読み取りだけでよいなら、ReadWriteではなくReadの権限にする
Sites.Selectedのように、対象を特定のリソースに絞れる権限を検討する
Exchange OnlineのRBAC for Applicationsなどで、アクセスできるメールボックスを絞る

なお、Delegatedでも管理者ユーザーが使えば影響範囲は大きくなります。
「Delegatedだから安全」とは限らない点にも注意が必要です。

また、Microsoft Entra Agent IDでは、一部の高リスクなMicrosoft Graph権限はAgentへの付与自体が制限されています。
Agentに強い権限を持たせるのではなく、必要な処理に合わせて権限を限定することが前提となっています。

9. AI Agentだからこそ「権限」が重要

通常のアプリケーションでも権限管理は重要ですが、AI Agentではさらに注意が必要です。
AI Agentは、次のところまで自分で行う可能性があるからです。

入力を受ける
   ↓
内容を判断する
   ↓
処理を決定する
   ↓
外部システムを操作する

もしAgentに強い権限が与えられていた場合、次のような経路も考える必要があります。

誤った指示
Prompt Injection
Agentの誤判断
不正な入力
        ↓
     AI Agent
        ↓
 強いApplication Permission
        ↓
 Microsoft Graph
        ↓
 組織データ

Agentが判断を誤ったり、悪意のある入力に誘導されたりしても、与えられた権限を超えた操作はできません。
だからこそ、Agentに与える権限そのものが、重要な防御線の1つになります。

実際には、Conditional Access、API側の認可、DLP、監査ログ、リソース単位のアクセス制御なども組み合わせて守ります。

10. まとめ

今回は、AI AgentからMicrosoft Graphなどを使うときの権限を整理しました。
最初に押さえておきたいのは次の2つです。

パターン	考え方	代表例
Delegated Permission	ユーザーの代理	「私のメールを探して」
Application Permission	Agent自身	「毎晩自動でチェックして」

なお、OBOは3つ目の権限の種類ではありません。
Agent宛てのTokenを受け取ったAgentが、同じユーザーの代理として、下流API向けの新しいAccess Tokenを取得する仕組みです。

User
 ↓ ユーザーのToken
AI Agent
 ↓ OBOで取得したToken
Microsoft Graph

AI Agentを設計するときは、まず「このAgentは誰の権限で動くのか？」を考えると、Identity設計を整理しやすくなります。
特にAgent自身に権限を与える場合は、必要最小限の権限だけを与えることが重要です。

AIが何を考えるかだけでなく、AIに何を実行できる権限を与えるか。
これが、AI Agentのセキュリティを考えるうえでの出発点です。

次回：第2回 Token実測編

今回は仕組みの理解を優先しました。

次回はDelegated + OBOとApplication Permissionの違いを検証します。
取得したAccess Tokenで、次のClaimを比較する予定です。

scp
roles
oid
azp（v1.0のTokenではappid）
xms_*などAgentに関連するClaim

「誰の権限でAPIを呼んでいるのか？」が、Token上でどう表れるかを確認します。

連載の予定

概念編：Delegated / Application / OBO（本記事）
Token実測編：scp / roles / oid / azp / xms_*
Agent ID編：Agent Identity / Blueprint / FIC / Service Principalとの違い
Security編：Prompt Injection × Graph権限 × Least Privilege

参考資料