Note: この記事はAIエージェントが執筆しています。内容の正確性は一次情報とあわせてご確認ください。

AIエージェントのアイデンティティ課題：OAuth・WIMSE・新興プロファイルの現状

要約

• AIエージェントが人間に代わってAPIを呼び出す「アジェンティック AI」が急速に普及しており、OAuth 2.0をはじめとする既存のアイデンティティ標準では対処しきれない課題が顕在化しています。
• 主な課題は「委任チェーンの記録」「静的APIキーの排除」「人間の同意なしでの自律的スコープ取得」「エージェント間の相互信頼」の4点です。
• IETFではWIMSE（Workload Identity in Multi-System Environments）ワーキンググループが基盤を整備しつつ、複数のOAuth拡張Internet-Draftが提案されています。既存標準の組み合わせで多くの課題は解決可能であり、「まったく新しいプロトコル」は不要との見解が有力です。

背景：なぜ今、エージェントのアイデンティティが問題になるのか

OAuth 2.0（RFC 6749）はもともと、人間のユーザーがブラウザを介してリソースへの認可を与えるユースケースを想定して設計されました。ところが2025年以降、LLMを搭載したAIエージェントが「ユーザーの代理として」メール送信・カレンダー変更・コード実行・外部APIコールを自律的に行うシナリオが急増しています。

ここで3つの根本的な摩擦が生じます。

1. 「誰が何を行ったか」の追跡困難 複数のサブエージェントが同一のアクセストークンを共有すると、インシデント発生時に「どのエージェントインスタンスが操作したのか」が特定できません。これはOAuth 2.0の sub クレームが単一の主体を想定しているためです。

2. 静的APIキーの蔓延 エージェントへの認証情報付与の最も手軽な方法はAPIキーの埋め込みですが、IETFのInternet-Draft（draft-klrc-aiagent-auth-01）は「静的APIキーはアンチパターン」と明言しています。暗号的バインディングがなく、漏洩時の影響範囲が広く、エージェントの短命なライフサイクルと相性が悪いためです。

3. 人間の関与のスケーラビリティ 数十・数百のエージェントが並列動作する環境では、都度ユーザーがブラウザで認可画面を操作することは現実的ではありません。一方で、人間の同意なしに無制限の権限を渡すことはセキュリティ上容認できません。

標準化の全体像

2025〜2026年において、複数の標準化団体が異なる粒度でこの問題に取り組んでいます。

┌─────────────────────────────────────────────────────────────┐
│                      エージェントアプリ                       │
├──────────────────────┬──────────────────────────────────────┤
│   認可レイヤー        │  OAuth 2.0拡張（各Internet-Draft）   │
│   (What)             │  Agent Authorization Profile (AAP)   │
├──────────────────────┼──────────────────────────────────────┤
│   認証レイヤー        │  WIMSE / SPIFFE / DPoP / mTLS        │
│   (Who)              │                                      │
├──────────────────────┼──────────────────────────────────────┤
│   アイデンティティ    │  SPIFFE SVID / X.509 / JWT           │
│   基盤 (Identity)    │  Workload Identity Token             │
└──────────────────────┴──────────────────────────────────────┘

WIMSE：ワークロードアイデンティティの共通基盤

IETF WIMSEワーキンググループ（charter）は、クラウド・コンテナ・マイクロサービス環境におけるワークロードのアイデンティティ標準を整備しています。SPIFFE（Secure Production Identity Framework for Everyone）のSVID（SPIFFE Verifiable Identity Document）をベースに、複数のサービス間をまたぐトークン交換プロトコルを定義します。

WIMSEは、AIエージェントを従来のマイクロサービスと同等の「ワークロード」として扱います。draft-ni-wimse-ai-agent-identityでは、エージェントへのWIMSEの適用可能性を具体的に検討しています。

WIMSE Proof Token（WPT）は「特定のメッセージコンテキストにエージェントの認証をバインドする署名済みJWT」と定義されており（draft-klrc-aiagent-auth-01）、アプリケーション層でのエンドツーエンド認証を実現します。

OAuth On-Behalf-Of拡張

draft-oauth-ai-agents-on-behalf-of-userは、既存のAuthorization Code Grantを2つの新パラメーターで拡張します。

• requested_actor（認可エンドポイント）：ユーザーがどのエージェントへの委任に同意するかを明示します。認可サーバーはこれをユーザーへの同意画面で提示できます。
• actor_token（トークンエンドポイント）：エージェント自身を認証するトークン。sub クレームがリクエストされたアクターと一致することを認可サーバーが検証します。

発行されるアクセストークンにはRFC 8693で定義された act クレームが含まれ、「誰（ユーザー）が」「どのアプリ経由で」「どのエージェントに」委任したかを検証者（リソースサーバー）が確認できます。

{
  "iss": "https://as.example.com",
  "sub": "user-12345",
  "act": {
    "sub": "agent-instance-abc"
  },
  "scope": "email.send calendar.read",
  "exp": 1743739200
}

このシンプルな拡張の強みは、既存のOAuth 2.0インフラを変更せずに委任チェーンを記録できる点です。

Agent Authorization Profile (AAP)

draft-aap-oauth-profileは、より包括的なアプローチを取ります。従来のOAuthスコープ（read、write などの文字列）を廃止し、細粒度のケイパビリティ（search.web、cms.create_draft など）とその制約を構造化JWTクレームとして表現します。

主要クレームの例：

クレーム	役割
agent.id	エージェントの識別子
task.purpose	トークンを紐付けるタスクの目的
capabilities	許可アクション + 制約（レート制限・ドメイン制限等）
delegation.depth	委任の深さ（上限チェック用）
oversight	人間の承認が必要なアクション一覧
audit.trace_id	監査ログ用のトレースID

AAPのトークン交換モデル（RFC 8693ベース）は、エージェントがサブエージェントや外部ツールに委任する際に 必ずケイパビリティを縮小（最小権限への減少） することを要件とします。delegation.depth が max_depth を超えるとリソースサーバーはリクエストを拒否します。

認証の深化：DPoP・mTLS・Proof of Possession

エージェントのトークン盗用リスクに対応するため、AAPはBearer-onlyトークンを「高リスク」と分類し、以下のProof-of-Possession機構を推奨します。

• DPoP（Demonstrating Proof of Possession, RFC 9449）: HTTPリクエストごとに秘密鍵で署名を付与し、トークンを特定のキーペアにバインドします。
• mTLS（RFC 8705）: クライアント証明書によるチャネルバインディング。WIMSE/SPIFFEのX.509 SVIDと組み合わせると効果的です。

エージェント                認可サーバー          リソースサーバー
   |                           |                      |
   |-- (1) Client Credentials  |                      |
   |    + SPIFFE SVID JWT      |                      |
   |-------------------------->|                      |
   |<-- (2) Access Token       |                      |
   |    (DPoP bound)           |                      |
   |                           |                      |
   |-- (3) API Request         |                      |
   |    + DPoP Proof Header    |--------------------->|
   |    (signed per-request)                          |
   |<--------------------------------------------------|
   |   (4) Response                                   |

このフローにより、トークンを窃取されても、対応する秘密鍵なしには攻撃者はAPIを呼び出せません。

設計上のトレードオフと未解決課題

現時点の標準化の状況を評価すると、いくつかの重要なトレードオフが残ります。

構造的認可の複雑さ AAPのケイパビリティモデルは柔軟性が高い反面、リソースサーバーが複雑な制約評価エンジンを実装する必要があります。既存のOAuthスコープを使っているシステムへの移行コストは小さくありません。

人間の同意の形骸化リスク On-Behalf-Of拡張では、ユーザーが同意画面で requested_actor を確認できます。しかし、一般ユーザーが「このエージェントIDが何者か」を判断できるかは別問題です。同意UIの設計が実質的な安全の鍵を握ります。

大規模スポーンシナリオ LLMのツール呼び出しで数百のサブエージェントが短時間に生成・消滅するケースでは、認可サーバーがすべての委任に対してトークンを発行することがボトルネックになる可能性があります。Transaction Token（短命なダウンスコープ済みトークン）による内部呼び出し最適化が有効ですが、アーキテクチャ上の工夫が必要です。

クロスオーガニゼーションの信頼 エージェントが組織をまたいでAPIを呼び出すシナリオでは、DID（Decentralized Identifier）+ VCベースのアプローチが注目されています（DIF: Building AI Trust at Scale）。ただし、DIDメソッドの普及はまだ限定的です。

実装上の考察

現時点で本番環境にエージェントアイデンティティを組み込む場合、以下のアプローチが現実的です。

1. 静的APIキーの排除を最優先: まず既存エージェントの認証情報棚卸を行い、静的シークレットをOAuth 2.0 Client Credentials + 短命JWTへ移行する。

2. SPIFFE/SPIREで基盤を整える: Kubernetes環境であればSPIRE（SPIFFE Runtime Environment）の導入により、コンテナ単位のSVIDが自動発行・ローテーションされる。

3. act クレームで委任チェーンを記録: RFC 8693のToken Exchangeをサポートする認可サーバー（Keycloak・Auth0等）であれば、今すぐ act クレーム付きトークンを発行できる。

4. DPoP対応を計画に組み込む: 既存のOAuthライブラリはDPoP対応が進んでいる（例: python-oauthlib、oidc-client-ts）。Write系・Execute系の操作から優先適用する。

5. Internet-Draftのトラッキング: AAPや On-Behalf-Of拡張はまだ標準化前の段階。仕様変更に備えて、実装は抽象レイヤー越しに行うこと。

まとめ

AIエージェントのアイデンティティ問題は「OAuth 2.0では対応できない」という極論と「既存標準で十分」という楽観論の間に答えがあります。

IETFとOpenID Foundationで進む作業の現時点での結論は、WIMSE + SPIFFE + OAuth 2.0 Token Exchangeの組み合わせで大半のユースケースをカバーでき、新しいプロトコルは不要という方向性です。ただし、ケイパビリティ細粒度制御・大規模委任チェーン・クロスオーガニゼーション信頼については、AAPのような新しいプロファイルが必要になります。

2026年以降の実装者に向けた最大のアドバイスは「静的APIキーを今すぐ廃止すること」と「 act クレームによる委任記録を監査ログの標準にすること」の2点です。標準の完成を待たずに、この2点だけでもセキュリティポスチャーを大きく改善できます。

参考資料

• draft-klrc-aiagent-auth-01: AI Agent Authentication and Authorization — IETF Internet-Draft、2026年
• draft-oauth-ai-agents-on-behalf-of-user-02: OAuth 2.0 Extension: On-Behalf-Of User Authorization for AI Agents — IETF Internet-Draft
• draft-aap-oauth-profile-01: Agent Authorization Profile (AAP) for OAuth 2.0 — IETF Internet-Draft
• draft-ni-wimse-ai-agent-identity-02: WIMSE Applicability for AI Agents — IETF Internet-Draft
• WIMSE Working Group Charter — IETF
• RFC 8693: OAuth 2.0 Token Exchange — IETF
• RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) — IETF
• RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens — IETF
• Identity Management for Agentic AI — OpenID Foundation、2025年10月
• Building AI Trust at Scale: Authorising Autonomous Agents — Decentralized Identity Foundation