AI AgentのIdentityは普通のService Principalと何が違う？ Microsoft Entra Agent IDの仕組みを整理する

Posted at 2026-09-26

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

第1回では、AI AgentがMicrosoft GraphなどのAPIを呼ぶときの権限として、Delegated Permission、Application Permission、OBO（On-Behalf-Of）を整理しました。
第2回では、実際にAccess Tokenを取得して、scp / roles / oid / appid / xms_* といったClaimを比較しました。

その検証で何度も登場したのが、Agent IdentityとAgent Identity Blueprintです。

今回は、次の疑問を中心に、Microsoft Entra Agent IDの構造を整理します。

Agent Identityは、普通のService Principalと何が違うのか？

1. まずは従来のService Principalを思い出す

Microsoft Entra IDでアプリケーションを使うとき、よく登場するのがService Principalです。
ざっくり言えば、そのテナントの中でアプリケーションをIdentityとして表現するものです。

従来の非対話型アプリは、次の構成がよく使われます。

App Registration
      ↓
Service Principal
      ↓
Client Secret / Certificate
      ↓
Access Token
      ↓
Microsoft Graph

Service Principalには、API Permission、App Role、Credential、ロールの割り当てなどを関連付けられます。

2. AI AgentでもService Principalでよいのでは？

単純にAPIを呼ぶだけなら、AI AgentもService Principalで動かせます。
実際、公式ドキュメントによると、以前のバージョンのMicrosoft Copilot StudioやAzure AI Foundryは、標準のService Principalでエージェントを保護していました。

そのため、管理センターの「Agent identities」の一覧には、Agent Identityと、標準のService Principalで作られたエージェントが並ぶことがあります。
後者はAgent固有の動きを持ちません。一覧のフィルターで区別できます。

ただし、AI Agentが増えてくると、次の問題が出てきます。

Agent A
Agent B
Agent C
Agent D
Agent E

これらが同じService Principalを共有すると、どのAgentが実際に処理したのかをIdentityとして区別しにくくなります。
一方で、AgentごとにApplication Service Principalを個別作成すると、今度はIdentityやCredentialの管理対象が増えていきます。

Microsoft Entra Agent IDは、こうしたAI Agent特有のIdentity管理を扱うための仕組みです。
Microsoftも、AI Agentには通常のService Principalではなく、Agent Identityを利用することを推奨しています。

3. Agent Identityとは？

Agent Identityは、名前のとおりAI Agent自身を表す専用のIdentityです。

Security Agent      → Agent Identity A
HR Agent            → Agent Identity B
Knowledge Agent     → Agent Identity C

これにより、どのAgentがアクセスしたのかをIdentityとして区別できます。

第2回では、Application PermissionでMicrosoft Graphを呼んだとき、TokenのoidとappidがどちらもAgent Identityになることを確認しました。
Agent Identity自身が、アクセス主体としてTokenに表れます。

4. Agent Identityは、Service Principal基盤の上にある

ここは誤解しやすいところです。
Agent Identityは、Service Principalとまったく別の基盤を使うわけではありません。

公式ドキュメントでは、Agent Identityは「新しいagentサブタイプを持つ、シングルテナントのService Principalとしてモデル化されている」と説明されています。
つまり、既存のService Principal基盤の上に、Agent固有のふるまいと制約が追加された形です。

Service Principal基盤
        │
        ├─ 通常のApplication Service Principal
        │
        └─ Agent Identity
             └─ Blueprintとの親子関係 / Sponsor / Agent固有の制約と監査

通常のService Principalが自分のCredentialで直接Tokenを取得するのに対し、Agent IdentityはBlueprintによる代理（impersonation）でTokenを取得します。
この設計を一言でまとめると、次のようになります。

Blueprintが認証（Credential）を持ち、Agent Identityが権限と監査上の主体を持つ

第2回のToken実測でも、xms_act_fctに11が含まれることで、ActorがAgent Identityだと判別できました。

5. Agent Identity Blueprintとは？

Blueprintは、複数のAgent Identityを作成・認証・管理するための親となるオブジェクトです。

Agent Identity Blueprint
        │
        ├── Agent Identity A
        ├── Agent Identity B
        ├── Agent Identity C
        └── Agent Identity D

第2回の検証では、AgentIdentity-LabというBlueprintの配下にTokenTestAgentを作りました。

Blueprintの作成時には、スポンサーの指定が必須です。誰がそのAgentに責任を持つのかを、Identity側に記録する仕組みです。

Blueprintは単なるテンプレートではなく、テナント内の特別なIdentityでもあります。
公式ドキュメントによると、Blueprintがテナント内で実行できる操作は1つだけで、Agent Identityの作成と削除です。
そのためにAgentIdentity.CreateAsManagerという専用のMicrosoft Graph権限を持ちます。

なお、Blueprintにはシングルテナントとマルチテナントがあり、マルチテナントのBlueprintはカタログ経由で他のテナントに配布できます。一方、Agent Identityは常にシングルテナントです。

Blueprint Principal

Blueprintをテナントに追加すると、その存在を表すBlueprint Principalが作成されます。
BlueprintがTokenを取得すると、そのTokenのoidはBlueprint Principalを指します。監査ログにも、Blueprint Principalが実行者として記録されます。

第2回で触れたとおり、管理センターの一覧に表示される「Object ID」は、このBlueprint Principalのものです。
Secretの追加やスコープの公開に使うIDとは別なので、注意してください。

6. CredentialはAgent IdentityではなくBlueprintが持つ

従来のService Principalは、そのアプリ自身がCredentialを持ちます。
一方、Agent Identityは、Client SecretやCertificateのような長期Credentialを自分では持ちません。

Agent Identity Blueprint
        ↓
     Credential
        ↓
   Agent Identity

第2回でも、BlueprintにClient Secretを追加し、そのCredentialでAgent Identity向けのTokenを取得しました。

Agentが100個あり、従来のApplication Service PrincipalをAgentごとに個別作成して、それぞれのCredentialを個別管理する構成では、次のようになりがちです。

Agent 001 → Secret 001
Agent 002 → Secret 002
...
Agent 100 → Secret 100

Client Secretを使う構成であれば、Secretの発行、ローテーション、期限管理、漏えい時の対応が、そのまま100個分になります。
もちろん通常のService PrincipalでもCertificateやManaged Identityを利用できますが、AgentごとにCredentialを個別管理する必要がある点は変わりません。

Blueprintを使うと、次の形にできます。

                  ┌ Agent 001
Blueprint ────────┼ Agent 002
 Credential       ├ Agent 003
                  └ Agent 100

Agentの数が増えるほど、この差は大きくなります。

7. `fmi_path`とToken取得の流れ

CredentialがBlueprint側にあるなら、「どのAgentとして動くのか」をどこで指定するのでしょうか。
それが、第2回で使ったfmi_pathです。

Autonomous Agentの場合、Token取得は2段階でした。

① Blueprint
   │ Credential
   │ fmi_path = Agent Identity
   ▼
Microsoft Entra ID
   │
   ▼
交換用Token（T1）

② Agent Identity
   │ T1をCredentialとして提示
   ▼
Microsoft Entra ID
   │
   ▼
Microsoft Graph用Token

第2回でT1をデコードすると、subの末尾にfmi_pathで指定したAgent IdentityのIDが含まれていました。
BlueprintがどのAgent IdentityとしてTokenを取得しようとしているのかが、Tokenにも記録されているわけです。

BlueprintはGraph用Tokenにも残る

Agent Identityとして取得したMicrosoft Graph用Tokenにも、xms_par_app_azpとして親のBlueprintのIDが入ります。
Tokenから「User / Agent → Agent Identity → Blueprint」という関係をたどれます。

xms_par_app_azpは監査用途のClaimです。
認可の判断に使うと、Blueprint配下の複数のAgentをまとめて信頼してしまうため、公式ドキュメントでも認可用途には使わないよう案内されています。

8. Agentのユーザーアカウント

Agent IDには、Agent Identityとは別にAgentのユーザーアカウント（agent's user account）という概念もあります。

メールボックスやTeamsなど、ユーザーIdentityの存在を前提とするMicrosoft 365リソースにAgentがアクセスする場合に使います。

Agent Identityと1対1で対応する
Agent Identityの代わりではなく、両方が必要
本当に必要な場合だけ使う

第2回で見たxms_sub_fctの値13は、このAgentのユーザーアカウントを表します。
11（Agent Identity）と13（Agentのユーザーアカウント）を見分けられるようになっています。

9. Service PrincipalとAgent Identityを比較する

ここまでを整理すると、次のようになります。

観点	通常のApplication Service Principal	Agent Identity
主な用途	アプリ / 静的なWorkload	AI Agent
Identityの単位	Application / Service Principal単位	Agent単位
Credential	自分で持つ	Blueprintが持つ
Token取得	自分のCredentialで直接取得	Blueprintによる代理で取得
親子関係	Application : Service Principal は1対1	Blueprint : Agent Identity は1対多
Agent固有Claim	なし	`xms_act_fct` / `xms_sub_fct` / `xms_par_app_azp`
Azure RBACロール	割り当て可	割り当て可（Blueprintには割り当て不可）
Entraの組み込みロール	割り当て可能（ロールごとの制約に従う）	高権限ロールはブロック。カスタムロールも不可
Graphの権限	通常のApplication Permission / Delegated Permission	一部の高リスク権限はプラットフォーム側でブロック
監査	Application / Service Principal単位	Blueprint / Agent Identity / Agentのユーザーアカウントを区別して記録

Agentに付与できない権限とロール

公式ドキュメントによると、次のものはAgentに割り当てられません。

Entraロール： Global Administrator、Privileged Role Administrator、User Administratorなどの高権限ロール。カスタムロールも不可で、ロール割り当て可能なグループのメンバーにもできない
Graphの権限： Application.ReadWrite.All、RoleManagement.ReadWrite.All、User.ReadWrite.All、Directory.AccessAsUser.All

管理者であっても、これらをAgentに同意することはできません。

重要なのは、次のように捉えることです。

Agent IdentityはService Principal基盤を置き換えるものではなく、その基盤の上に追加されたAgent専用のIdentityモデル

10. inheritable permissions

Blueprintには、inheritable permissions（継承可能なアクセス許可）という仕組みがあります。

Resource Appごとに、次の2つを独立して継承対象に設定できます。

Delegated PermissionのScope
Application PermissionのRole

第2回のOBO検証では、Blueprintに同意したUser.ReadをAgent Identityへ継承させました。
そのとき、Microsoft Graphに対する設定は次のとおりです。

Scopes : allAllowed
Roles  : none

Application RoleのUser.Read.AllはAgent Identityへ直接割り当てていたので、Roleは継承しない設定にしています。

inheritable permissionsは「Blueprintの権限を何でも自動的に継承する」仕組みではありません。
Resource AppごとにScopeとRoleの継承方針を宣言するもので、実際の認可には管理者の同意が必要です。

11. Blueprintはセキュリティ境界になる

CredentialをBlueprintに集約すると管理は楽になりますが、裏返しの注意点があります。

権限の影響範囲

Blueprint Principalに広い権限を付与し、それをinheritable permissionsで広く継承させると、次のようになります。

Blueprint
  │
  ├── Agent A ── 強い権限
  ├── Agent B ── 強い権限
  └── Agent C ── 強い権限

これでは、せっかくAgent Identityを分けても、権限の影響範囲は広いままです。

Credentialの影響範囲

さらに重要なのがCredentialです。
CredentialはBlueprintが持つため、Blueprintの資格情報が侵害されると、その配下のすべてのAgent Identityが影響を受けます。

公式ドキュメントでも、Blueprintをいくつ作るかはセキュリティ境界の判断だと説明されています。
用途やリスクの大きさが違うAgentは、Blueprintを分けることを検討してください。

ポリシーの適用単位でもある

一方で、Blueprintは制御をまとめてかけられる単位でもあります。

Blueprintに適用したConditional Accessポリシーは、配下のすべてのAgent Identityに適用される
Blueprintを無効化すると、配下のすべてのAgent Identityが認証できなくなる

Agent単位の分離と、Blueprint単位の制御。この2つを組み合わせて設計します。

12. 本番環境ではFIC + Managed Identity

第2回では、検証を簡単にするためClient Secretを使いました。
ただし、本番環境で長期Secretを保持する構成は避けたいところです。

そこで使われるのがFederated Identity Credential（FIC）です。
別のIdentityが発行したTokenを信頼することで、長期Credentialを保持せずにTokenを取得できます。

Azure上でAgentを動かす場合は、次の構成になります。

Azure App Service / Functions / VM
      │ Managed Identity
      ▼
Federated Identity Credential
      │
      ▼
Agent Identity Blueprint
      │
      ▼
Agent Identity
      │
      ▼
Microsoft Graph

公式ドキュメントでも、Managed Identityが推奨されるCredentialの種類とされています。
ただし、これはBlueprint側のCredentialであって、Agent Identityそのものを置き換えるものではありません。

11章で触れたとおり、BlueprintのCredentialは配下すべてのAgentに影響します。
そのCredentialをSecretからManaged Identityに変えることは、影響範囲の大きい場所から長期Secretをなくす、という意味を持ちます。

13. まとめ

今回は、Microsoft Entra Agent IDの構造を整理しました。

Agent Identity： AI Agent自身を表すIdentity。Service Principal基盤の上に作られたagentサブタイプ
Blueprint： Agent Identityを作成・認証・管理する親。Credentialとポリシーの単位
Blueprint Principal： テナント内でのBlueprintの主体。Token取得と監査ログに表れる
Agentのユーザーアカウント： メールボックスなど、ユーザーオブジェクトを必要とするリソース向け

設計の要点は、次の一文に集約されます。

Blueprintが認証（Credential）を持ち、Agent Identityが権限と監査上の主体を持つ

この分離によって、AgentごとにSecretを配らずに、Agent単位で権限・監査・ライフサイクルを分けられます。

AI Agentが少数のうちは、通常のService Principalでも管理できるかもしれません。
しかし、Agentごとにできることも、アクセスするデータも違います。Agentが増えるほど、Application単位ではなくAgent単位でIdentityを管理する必要が出てきます。

AIが何を考えるかだけでなく、AIに何を実行できる権限を与えるか。
そしてその権限を、どの単位で分け、どの単位でまとめて止められるようにするか。それがAgent ID設計の中心です。

次回：第4回 Security編

次回は、次の問いをSecurityの観点から考えます。

AI Agentに強い権限を与えると何が起きるのか？

例えば、次のような経路を想定します。

悪意のある入力
      ↓
Prompt Injection
      ↓
AI Agent
      ↓
強いApplication Permission
      ↓
Microsoft Graph

Prompt Injection、Least Privilege、Conditional Access、API側のAuthorization、監査ログといった要素で、どこまで被害を抑えられるのかを整理します。

連載の予定

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

参考資料

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up