AIシステムのIdentityとAuthorizationは、誰が利用しているか、どのAgentが動いているか、どの権限でToolを実行するかを分けて識別し、認可する設計です。三つを一つのCredentialへまとめないことが出発点です。
利用者がログイン済みでも、Agentがその人の操作をすべて代行してよいとは限りません。Agent自身が認証できても、特定利用者のデータを読んでよいとは限りません。
認証・認可・委任を分ける
| 用語 | 確認すること |
|---|---|
| Identity | User、Service、Agent、Workloadをどう識別するか |
| Authentication | そのIdentityであることをどう確認するか |
| Authorization | そのIdentityが対象操作を許可されているか |
| Delegation | Userの権限の一部をAgentへどう渡すか |
| Credential | Identityを証明・利用するための秘密情報やToken |
| Scope / Policy | 許可する操作と対象をどう限定するか |
NIST SP 800-63-4は、Identity proofing、Authentication、Federationを分けて扱います。AI Agent固有の文書ではありませんが、利用者Identityの基礎をAgent任せにしないための起点になります。
User IdentityとAgent Identityは同じではない
Host applicationはUser identityとAgent workload identityの両方を受け取ります。Authorization policyが両者の権限を評価し、許可された要求だけをToolまたはResource serverからBusiness dataへ到達させます。
- User identityとAgent workload identityをHost applicationへ渡します。
- HostがAuthorization policyへ認可判断を求めます。
- Policyが許可した要求だけをToolまたはResource serverへ渡し、Business dataへアクセスします。
User Identityは「誰の依頼か」を表します。AgentやRuntimeのWorkload Identityは「どの実行主体がRequestしたか」を表します。
AgentCoreのWorkload Identityは、AgentをDeploymentやCredential方式から独立したIdentityとして扱い、外部CredentialへのAccess controlに使います。
UserとAgentのどちらか一方だけで認可すると、境界が広がります。たとえば、Agent Runtimeが管理者Tokenを一つ持ち、すべてのUser RequestをそのTokenで処理すると、利用者ごとの権限を下流APIで確認できません。
Agentが誰のために動くかを明示する
主な実行Patternは分けて設計します。
User-delegated access
Agentが利用者に代わってCalendarやDriveへアクセスします。利用者の同意、対象Resource、Scope、TokenのAudienceを確認します。
Machine-to-machine
Background処理やBatchが、Agent自身の権限で共通Resourceへアクセスします。利用者権限を暗黙に引き継ぎません。
Human approvalを伴う更新
Agentは下書きや候補作成まで行い、送信・返金・削除の直前で承認を要求します。承認者、対象操作、入力、期限を結び付けたApproval tokenを使います。
Tokenは対象Resourceと最小権限へ絞る
RFC 9700は、OAuth 2.0の現在のSecurity Best Current Practiceとして、Access Tokenの権限制限、Redirect flow保護、Token replay対策などを整理しています。
Agentへ渡すTokenでは、少なくとも次を確認します。
- Audienceが対象APIへ限定されている
- Scopeが必要な操作だけに絞られている
- 有効期限が短い
- Refresh tokenとCredentialが安全に保存される
- LogやModel ContextへTokenを出さない
- User、Agent、SessionとToken利用を追跡できる
- 失効とCredential rotationができる
汎用の管理者TokenをToolへ渡し、Tool名だけで権限を分ける構成は避けます。
MCPのAuthorizationは業務認可の一部
MCP Authorization仕様は、HTTP TransportでClientがResource ownerに代わってProtected MCP Serverへ接続する流れを定義します。Token Audience、Protected Resource Metadata、PKCEなどを扱います。
ただし、MCP接続が成功しても、「この利用者がこの注文を返金できるか」は業務API側で判断します。Protocol上のAuthorizationと、Resource単位の業務認可を分けます。
よくある誤解
ログイン済みならAgentへ同じ権限を渡してよい
利用者が画面で実行できる操作でも、Agentによる自動実行では影響範囲が広がります。用途・対象・期間を絞って委任します。
System Promptへ「管理者のみ」と書けば認可になる
Instructionは強制力のあるPolicyではありません。Toolと下流APIでIdentityとPermissionを確認します。
API keyを環境変数に置けば安全である
保管場所だけでなく、誰が取得できるか、どこへ送られるか、Logへ残らないか、失効できるかを確認します。
OAuthを使えば最小権限になる
OAuthは委任のFrameworkです。広すぎるScopeや誤ったAudienceを使えば、権限は広いままです。
EastBraver Labsの判断基準
EastBraver Labsでは、User Identity、Agent Workload Identity、実行先ResourceをTrace上で結び付けます。
読み取り、下書き、更新、取り消せない操作を分け、後ろへ進むほどScopeと承認を厳しくします。
Modelが選んだTool名を認可判断には使いません。
最初は拒否をDefaultにし、必要な操作だけ許可する。 Agentが便利になるほどCredentialを広くするのではなく、Tool単位で権限を狭く保つ方を選びます。