『誰の代理でこのAPIを叩いたか』をトークンに刻む──OAuth Transaction Tokensのエージェント拡張を読む

マイクロサービスが連鎖してAPIを呼び合う環境で「このリクエストは誰の代理で、どのサービスが今実行しているか」を追跡する仕組みとして、OAuthには「Transaction Tokens」という仕様がある。ここにAIエージェントが割り込むとどうなるか——LLMエージェントやワークフローオーケストレーターが代理でAPIを叩く場合、従来のsub（誰の代理か）クレームだけでは、エージェントの連鎖（AがBに委任し、BがCを呼ぶ、といった多段の代理関係）を表現しきれない。この課題に対処するIETF個人ドラフトの本文をdatatrackerで確認した。

3行まとめ

• draft-araut-oauth-transaction-tokens-for-agentsは、OAuth Transaction Tokens仕様にagentic_ctxというクレームを追加し、単一エージェントの代理行動と、複数エージェントが連鎖して動く「マルチエージェントフロー」の両方に対応させる拡張ドラフト
• agentic_ctxには「今動いているエージェント」（current_actor）と「最初にこの連鎖を始めたエージェント」（originator）、ホップ数などの連鎖メタデータを含む。エージェントがバトンタッチするたびに、Transaction Token Service（TTS）がこのクレームを更新しつつ、subとactという不変の身元情報は保持し続ける
• この記事の執筆時点（2026年8月28日）の最新はrev 02（2026年5月22日付、著者Ashay Raut氏）。実はこのドラフトは一度名前が変わっており、旧ドラフト名draft-oauth-transaction-tokens-for-agents（rev 06、2026年4月11日付）はIETF Datatracker上で「Replaced Internet-Draft」（置き換え済み・失効アーカイブ）というステータスになっていることを確認した

課題——エージェントの連鎖に「不変の身元」が必要

新しいドラフト本文は、なぜagentic_ctxが必要かをこう説明している。

Txn-Tokens are increasingly used in environments where transactions are executed by or with the assistance of autonomous or semi-autonomous agents [...] relying exclusively on subject identity and generic transaction parameters is insufficient to make robust authorization decisions. Additional information about the agent chain and its operational context is often required.

（Transaction Tokenは、自律的または半自律的なエージェントによって、あるいはその支援を受けて取引が実行される環境でますます使われるようになっている。主体の身元と一般的な取引パラメータだけに頼ることは、堅牢な認可判断を下すには不十分であり、エージェントの連鎖とその実行文脈についての追加情報がしばしば必要になる）

具体例——株の買い注文をエージェントが代行する場合

ドラフトが挙げる例では、あるユーザー（alice@example.com）の代理でエージェントが株の買い注文を出す場面のトークンがこう表現される。

{
  "sub": "user:alice@example.com",
  "act": { "sub": "agent-identity-1" },
  "tctx": { "action": "BUY", "ticker": "MSFT", "quantity": "100" },
  "agentic_ctx": {
    "current_actor": "agent-identity-1",
    "originator": "agent-identity-1",
    "chain_metadata": { "hop_count": 1 }
  }
}

subは人間の身元、act.subは代理するエージェントの身元（RFC 8693で定義済みのactクレームをそのまま使う）、そして新設のagentic_ctxが「今誰が動いているか」と「連鎖が何ホップ目か」を運ぶ。複数エージェントが連鎖する場合は、エージェントが切り替わるたびにTransaction Token Serviceがトークンを再発行し、current_actorだけを更新しつつoriginator（最初の依頼者）とsub/actは不変のまま保持する、という設計だ。

社内エージェントと社外エージェントで信頼度に差をつける

ドラフトが明記している設計判断の一つが、エージェントの出自によってagentic_ctxに書ける情報の深さを変えるという点だ。

The depth of context available within agentic_ctx differs between external and internal agents. [...] the trust domain does not own or control external agents and therefore cannot verify their operational posture to the same degree.

（agentic_ctx内で利用可能な文脈の深さは、外部エージェントと内部エージェントで異なる。〔中略〕信頼ドメインは外部エージェントを所有・制御していないため、その動作の実態を同じ深さまで検証することはできない）

社内エージェント（エージェントレジストリやハードウェア構成証明で検証済み）にはより詳細な情報を持たせられるが、社外から来たエージェントについては、トークン交換時に得られる情報（act.subやclient_id）に基づく最低限の情報しか信頼しない、という非対称な扱いを明文化している。

ドラフト名が変わっていた——旧版は失効・アーカイブ済み

この記事を書くにあたって一次ソースを確認する過程で、当初想定していたドラフト名draft-oauth-transaction-tokens-for-agents（rev 06、2026年4月11日更新）がIETF Datatracker上で次のように表示されていることが分かった。

Document Type: Replaced Internet-Draft (individual). Expired & archived. [...] Replaced by draft-araut-oauth-transaction-tokens-for-agents

（文書種別：置き換え済みInternet-Draft（個人提案）。失効・アーカイブ済み。draft-araut-oauth-transaction-tokens-for-agentsによって置き換え）

つまりこのドラフトは著者名を含む形（draft-araut-...）に改名され、そちらが現行のアクティブなドラフト（rev 02、失効予定2026年11月23日）として続いている。この記事の内容は、旧名で調べ始めた後にこの改名を確認し、現行のdraft-araut-版の本文に基づいて書き直したものだ。

土台となるOAuth Transaction Tokens本体を読む——最新はrev 11

agentic_ctxが依拠する土台のOAuth Transaction Tokens仕様（draft-ietf-oauth-transaction-tokens、著者Atul Tulshibagwaleほか）は、datatrackerで確認したところ最新版はrev 11（失効予定2027年1月31日）で、こちらはIETF OAuthワーキンググループのドラフトとして進行しており、draft-araut-の個人ドラフトより一段階公式なプロセスに乗っている。本体仕様（Section 9.2）が定義するTxn-Tokenのボディクレームを一覧にすると次の通り。

本体仕様が示す非規範的な例（Figure 4）を見ると興味深いのは、agentic_ctxドラフトが挙げていた例にあったactクレーム（RFC 8693の代理人クレーム）が、本体仕様自身の例には登場しないことだ。本体仕様は「誰の代理か」をsubだけで表現する設計を基本としており、actによるエージェント連鎖の表現はagentic_ctxドラフト側が独自に追加した拡張だと分かる。

OAuthやマイクロサービス間認可の実装経験はない

この記事を書いている自分自身はOAuthやマイクロサービス間の認可基盤を実務で構築した経験がなく、agentic_ctxが実際にどの企業のトークンサービスで実装されているかについては確認できていない。本体仕様（rev 11）についても、Section 9.2に記載されたクレーム定義以上には、Section 13のSecurity ConsiderationsやSection 16のIANA Considerationsまでは読み込んでいない。日本語ではZenn・Qiitaともに、この拡張ドラフト単体を扱った記事は検索時点で見当たらなかった。

関連記事: MCP（Model Context Protocol）とは

感想・指摘はコメント欄へ。