# AIシステムのIdentityとAuthorizationとは — User・Agent・Toolの権限境界

> AI Agentで混同しやすい認証・認可・委任を分け、User Identity、Workload Identity、Token、Scope、Tool実行の責任境界を整理します。

Canonical URL: https://labs.eastbraver.com/guides/ai-identity-authorization
Published: 2026-07-01
Updated: 2026-07-24
Category: field-guide
Tags: ai-agent, governance, safety

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](https://pages.nist.gov/800-63-4/)は、Identity proofing、Authentication、Federationを分けて扱います。AI Agent固有の文書ではありませんが、利用者Identityの基礎をAgent任せにしないための起点になります。

## User IdentityとAgent Identityは同じではない

### Userと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へアクセスします。

*2種類のIdentityをPolicyで評価してResourceへのアクセスを決める構成*

User Identityは「誰の依頼か」を表します。AgentやRuntimeのWorkload Identityは「どの実行主体がRequestしたか」を表します。

[AgentCoreのWorkload Identity](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/understanding-agent-identities.html)は、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は下書きや候補作成まで行い、送信・返金・削除の直前で[承認](/guides/human-in-the-loop)を要求します。承認者、対象操作、入力、期限を結び付けたApproval tokenを使います。

## Tokenは対象Resourceと最小権限へ絞る

[RFC 9700](https://www.rfc-editor.org/info/rfc9700/)は、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](/guides/tool)へ渡し、Tool名だけで権限を分ける構成は避けます。

## MCPのAuthorizationは業務認可の一部

[MCP Authorization仕様](https://modelcontextprotocol.io/specification/2025-11-25/basic/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単位で権限を狭く保つ方を選びます。

## 関連記事

- [AI Agent 時代に、エンジニアは何を設計する人になるのか](/blog/ai-development-20260706)
- [AI運用は安全境界の確認へ](/digest/ai-digest-20260703)
- [エージェント運用の境界が具体化](/digest/ai-digest-20260709)
- [モデル選定とエージェント運用が接続](/digest/ai-digest-20260714)
- [AIエージェント運用は堅牢性と統制へ](/digest/ai-digest-20260716)

## 検証範囲

- 一次情報: 公式ドキュメント / 仕様書 / 設計面からの分析
- ローカル検証: コードは動かしていません
- 実運用: 関連するWeb業務システムの設計・運用経験をもとにしています

## 変更履歴

- 2026-07-24: Mermaid図にテキスト等価物を追加
- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-01: 初版公開