AIエージェント

AIエージェントの認証・認可、IETF作業部会が統合案を採択

2026/9/21 （更新: 2026/10/11）

🤖 AIを使用して執筆

地図：エージェントの認証はどこで決まっているか

エージェントの認証と認可は、本稿が読むIETFの二つの草案だけで決まっているのではない。決める場は少なくとも三つある。エージェントがツールや他のエージェントと話すプロトコルの仕様、IETFの作業部会が持つ既存の部品、そしてクラウド事業者が製品として出している識別子の管理である。二つの草案は、この三つの上に置いて初めて位置が分かる。

プロトコルの側では、エージェントとツールをつなぐMCP（Model Context Protocol。Anthropicが2024年11月に公開した規格⁹）の仕様が、認可をトランスポート層のOAuth 2.1の部分集合として定め、実装には必須としない⁵。この章はクライアントの登録方式と、利用者の代理か自分の名義かという要求の形を定めるが、クライアントを人やワークロードと別のエージェントとして識別する仕組みは置かない⁵。エージェント同士をつなぐA2A（Agent2Agent Protocol）の仕様1.0は、「A2Aはエージェントを標準的な企業アプリケーションとして扱う」と書き、識別子の扱いをA2Aの意味論の外に置く⁶。

IETFの側は、部品を先に持っている。OAuth作業部会には、あるトークンを別のトークンに交換するRFC 8693（2020年）があり、統合案はこれをエージェントの資格情報の交換手段として名指す¹⁰²。OAuth作業部会自身の作業部会文書に、エージェントを題に持つものは無い。ただし、シングルサインオンを担う識別基盤を介して、身元の主張を別のサービスのアクセストークンに換える作業部会文書（Identity Assertion JWT Authorization Grant、略称ID-JAG）は、外部のツールを使うAIエージェントを、想定する使い方の一つに挙げる¹¹。一方で、同じ文書一覧の関連草案の欄には、エージェント向けの委任・失効・認可などを扱う個人提出の草案が、名前にagentを含むものだけで十数本並び、2026年9月にも改訂が出ている。エージェント向けのOAuth拡張を提案した別の個人提出の草案は、2026年2月に失効している¹²。統合案を採択したWIMSE作業部会は、ワークロードの識別子・資格情報・相互TLS・HTTP署名など8本の作業部会文書を持ち、統合案はその8本目である¹³。

標準化団体の議論はIETFの中に限らない。OpenID Foundationは2025年10月、同団体の共同体グループなどと協力してまとめた白書を公表した。白書は、当面は既存の識別の標準を相互運用できる厳密なプロファイルに沿って使うよう勧める一方で、堅牢なワークロード識別子の枠組みでも、大規模に動くエージェントに固有の要求を満たしきらないかもしれないと書く¹⁴。

製品の側では、二社とも既存のワークロード識別子を土台にエージェントの識別子を作る。Microsoft Entra Agent IDは、エージェントの識別子を「特別なサービスプリンシパル」として作り、Microsoftはサービスプリンシパルをワークロード識別子の一つに数える⁷。Amazon Bedrock AgentCore Identityも、「エージェントの識別子は、専用の属性を持つワークロード識別子として実装される」と書く⁸。違うのは強調である。Entraは、エージェントの操作を従業員・顧客・ワークロードの識別子による操作と区別することを課題の一つに挙げ、数分で生まれて消えるエージェントを既存のアプリケーション識別子で管理すると運用が複雑になると書く⁷。AgentCoreのほうは、業界標準のワークロード識別子の型との互換を保つことを挙げる⁸。どちらも資格情報は既存の種類（OAuthのアクセストークンなど）である⁷⁸。

二つの草案は、エージェントを何として識別するかの捉え方が異なる。一つ目の「AI Agent Authentication and Authorization」（以下、統合案）は、エージェントをワークロードの一種と見る側の一例である²。二つ目の「Agent Identity Protocol」（以下、専用層案）は、エージェントを人の資格情報を借りた別の行為者と見る側の一例である¹。本稿がこの二つを読むのは、捉え方の違いを作り手自身が自分の言葉で書いており、読者が原典で確かめられるからである。

統合案：エージェントはワークロードである

統合案は、エージェントを「大規模言語モデルとツール・サービス・資源の集合を繰り返し行き来するワークロード」と定義する²。ワークロードの一種なら、ワークロードのために作られた標準がそのまま当たる。草案は新しい名前もプロトコルも作らず、識別子はWIMSEが定めるワークロード識別子を割り当て、資格情報は識別子に暗号学的に結びつけて短命にし、固定のAPIキーをアンチパターンとして退ける²。認可は2012年にRFC 6749として発行されたOAuth 2.0のスコープで組み¹⁵、ワークロード識別子にはCNCFが管理するSPIFFEの識別子を使ってもよいとする¹⁶²。

草案の診断は、「こうした取り組みの多くは孤立して解決策を開発しており、既存の仕組みを再発明することが多い」ことにある。答えは、「新しいプロトコルを提案するより、実績のある標準を一貫した枠組みへ統合する」ことである²。この草案は2026年3月に個人提出として出され、2026年9月9日にWIMSE作業部会へ採択された。9月15日には、題を「AI Identity Management System」に改めた作業部会文書 draft-ietf-wimse-aims-00 として再提出された²。

専用層案：エージェントは人の資格情報を借りた別の行為者である

専用層案は、「AIエージェントは、それを操作する人間と同じ資格情報で、大規模に配備されている」という観察から始める¹。欠落は二つある。ツールサーバは行為者が人かエージェントか判別できない（Identity Gap）。方針はシステムプロンプトの文章として書かれ、敵対的な入力で回避される（Enforcement Gap）¹。

答えは二つの層である。第一の層は、人の資格情報から独立した識別子をすべてのエージェントに与える。第二の層は、エージェントごとの方針を、ツール呼び出しの境目で、「モデルの信頼領域の外で、モデルの出力によって覆せない形で」執行し、それを担うのは呼び出しを横取りするプロキシである¹。

ツールサーバへの認証は既存のままで、「エージェントは引き続き自分のOAuthトークンやAPIキーをツールサーバに提示する」¹。この草案は2026年3月に個人提出として出され、採択されないまま2026年9月17日に失効した¹³。

採択が決めたことと、決めていないこと

採択が決めたのは、WIMSE作業部会が統合案を出発点に作業を始めることである。作業部会の慣行をまとめたRFC 7221（自らを非規範的な手引きと断る文書）は、採択を「承認ではない」と位置づけ、「作業部会による採択は、その文書のRFCとしての発行を保証しない」と書く⁴。

作業部会の憲章は、草案より前の2024年に、OAuth・JWT・SPIFFEが「実務でさまざまに組み合わされてきたが、その解は比較的孤立して存在してきた」と書き、それをそろえることを部会の仕事と定めていた¹⁷。統合案の診断はこの憲章の診断と重なる。ただし憲章と里程標はエージェントに触れておらず、この重なりが採択の理由だったかどうかは、憲章からは読めない。

採択が示す範囲は、作業部会が統合案を出発点に選んだという一事に限られる。統合案の筆頭著者はWIMSE作業部会の二人の議長の一人であり²、RFC 7221は議長の立場について、作業部会の合意を評価する以外に「特別な権限を持たない」と書く⁴。したがって採択は、専用層案との優劣を作業部会が判定したことを意味しない。専用層案の失効も、期限の経過で自動的に記録される事象である³。

一致しているのは、OAuthのトークンを受け入れる点である。本稿が調べた統合案・専用層案・MCP・A2A・二社の製品は、いずれもOAuthのトークンを資格情報の一つとして扱う²¹⁵⁶⁷⁸。ただし資格情報の中身は揃っていない。専用層案は登録簿に鍵を登録する独自の識別子を足し、専用層案・A2A・AgentCore IdentityはAPIキーも扱う¹⁶⁸。モデルの扱いも二つの草案で一致する。統合案は大規模言語モデルに資格情報を持たせず²、専用層案はプロキシをモデルの信頼境界の外に置く¹。

分かれているのは、識別子と執行点である。エージェント固有の識別子を人やワークロードと別に立てるかは、二つの草案で分かれる（専用層案は登録簿の独自の識別子、統合案はWIMSEのワークロード識別子）¹²。製品は二社とも、ワークロード識別子の特別な型として実装している⁷⁸。方針をどこで執行するかは、統合案が認可サーバとスコープに置き、専用層案がプロキシに置く²¹。

どちらの草案も、許す操作を列挙できる範囲でしか縛れない。人に追加の承認を求める道（統合案のCIBA、専用層案のask）も、列挙の内側でしか開かない²¹。統合案は、CIBAがクライアント側からの開始しか扱わず、実行の途中での利用者の確認にはうまく当てはまらないとも書き、その部分には追加の仕様が要りうるとしている²。エージェントプロトコルの要件をまとめたRosenbergとJenningsのIETF草案は、タスクが「列挙されたAPIの集合ではないとき」に利用者はどう権限を与えるのかを問うたままである¹⁸。統合案は自然言語のミッションを認可要件へ翻訳する過程を「本仕様の範囲外」と宣言する²。

境目の責任：どちらの草案も配備に委ねるもの

標準を組み合わせる方針の代償は、部品の境目に出る。統合案は認証の層を一つに決めず、トランスポート層でもアプリケーション層でも起こりうるとする。アプリケーション層の認証はチャネル結合（トークンを、それが流れる暗号化された通信路に結びつけること）を本来的には持たないので、トークンは通信路の外へ持ち出して別の相手に見せられる。草案はこの中継・再生の危険を実装が考慮しなければならない（MUST）と定め、緩和策（トークンの短命化・受け手の限定・一度きりの識別子（nonce）の検査・要求への結びつけ）を、配備が通常とる手段として挙げる²。

ただし四つの緩和策のすべてが配備の裁量に任されているわけではない。短命化と有効期限は、同じ草案の資格情報の節が要件（短命化はSHOULD、有効期限はMUST）として置き、受け手を限った短命のトークンを選ぶことも別の節がSHOULDで求める²。要求への結びつけは、草案がエージェントの使いうる認証手段として挙げるWPT（ワークロードの証明トークン）とHTTPメッセージ署名が、仕組みとして備える²。要件として書かれていないのは、一度きりの識別子の検査と、そうした結びつけの手段を使うかどうかである。作業部会文書となった現在の版でも、これを決めるのは配備する側であり、この線引きは作業部会での改訂で変わりうる²。

専用層案は境目を一つの執行点に集めたが、執行点を通らない経路は守れない。草案自身が、プロキシを迂回するランタイムと、プロキシ以外からの呼び出しを受けるツールサーバからは保護しないと書く¹。執行点を集めても、その点を通らない経路の責任は仕様の外に落ちる。失効の遅れのほうは、草案が自分で塞ぎ方を書く。最悪の場合に失効後最大60秒間呼び出しが続きうるとし、より厳しい要件の配備には登録簿の失効ストリームの購読を求める（SHOULD）¹。範囲は違うが、境目の責任の一部を配備する側が負う点は、二つの草案に共通する。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。