こんにちは。CTO室長の浅野（@masakz5）です。
7月18日からウィーンでIETF 126が始まりました。WIMSE（Workload Identity in Multi-System Environments）ワーキンググループのセッションも行われる予定で、この数ヶ月でAIエージェントの「Identity」をめぐる標準化がにわかに活発になっていることを実感します。Model Context Protocol（MCP）は7月28日に次期最終仕様の公開を予定し、Agent2Agent Protocol（A2A）は4月に初の安定版となるv1.0を公開しました。FIDO AllianceやOpenID Foundation、DIF（Decentralized Identity Foundation）でも関連する動きが相次いでいます。
こうした動きを見ていてあらためて感じるのは、「AIエージェントの身元」は単一の標準や団体で完結する話ではない、ということです。以前社内向けに整理したスライドでも、この課題を①接続、②ユーザー認証・API認可、③Workload・Runtime認証、④Credential表現・相互運用、⑤取引意図・Mandate、という5つのレイヤーに分けて捉えていました。この構造は今も概ね妥当ですが、この4ヶ月の動きを踏まえると、各レイヤーの進み方には温度差が出てきています。
接続レイヤー：MCP・A2Aは「土台」を固めつつある
MCPの中心は、エージェントとツール・データソースをつなぐ接続プロトコルです。独自のIdPやエージェント身元証明方式を定義するものではありませんが、HTTPトランスポート向けにはOAuth 2.1を基盤とするAuthorization仕様を備え、OIDC Discovery等の既存標準と組み合わせて利用します。7月28日に公開予定の次期仕様では、RFC 9207に基づき、Authorization Serverから返されるissパラメータの検証を厳密化するなど、OAuth/OIDCとの安全な統合がさらに具体化されています。
A2Aも4月に初の安定版となるv1.0を公開しました。エージェントカードには、JWSを用いて署名できるSigned Agent Cardsの仕組みが用意されています。信頼できる署名鍵の配布・検証と組み合わせることで、Agent Cardの改ざんや提供者のなりすましを検知できます。150以上の組織が標準を支持しており、複数業界ですでに本番導入も始まっていると発表されています。エージェント同士が互いを認識する場面に暗号署名が組み込まれてきたのは、PKIに携わる立場からも自然な流れです。
ユーザー認証・Workload認証：既存標準の「周辺」が固まる
OIDC/OAuth/FIDOという中核部分はすでに標準化済みという前提の中で、周辺仕様が具体化しています。FIDO Allianceは4月末に「Agentic Authentication TWG」と「Payments TWG」を発足させ、ユーザーがAIエージェントに操作を委任する際のフィッシング耐性認証や、人間の操作とAIの操作の境界定義に着手しました。OpenID FoundationもOpenID Federation 1.1およびOpenID Federation for OpenID Connect 1.1を5月にFinal Specificationとして承認し、AuthZEN WGではMCP Tool Callを認可モデルにマッピングするCOAZなどがOfficial Working Group Draftとして進んでいます。
一方、Workload・Runtime認証を担うWIMSEは、アーキテクチャ文書やWorkload Credential関連文書の改訂を続けていますが、いずれもまだInternet-Draft段階であり、RFCには至っていません。一方、SPIFFEではWIMSEのWITをサブプロファイル化したWIT-SVIDの仕様整備が進み、SPIREでもその実装対応が進められています。
Credential表現・相互運用：技術は進むが、DIFは「人間中心」の統治を選んだ
このレイヤーでは、DIFに寄贈された「MCP-I」フレームワークが4月に「KYA-OS（Know Your Agent Operating System）」へ改称され、L1（既存識別子の活用）からL3（エンタープライズ監査・不変ログ）までのコンフォーマンスレベルが定義されました。DIFとToIP（Trust over IP Foundation）は6月、審査プロセスを通過した初の「推奨DIDメソッド」としてdid:webvhとdid:webplusを選定しました。実装の多様性より相互運用性を重視するこの動きは、かつてPKIのエコシステムが辿った成熟プロセスとよく似ています。
一方で興味深いのは、DIF自身のガバナンスをめぐる判断です。DIFは5月末、AIエージェントがメーリングリストや議論、GitHubリポジトリ等に独立した参加者として直接関与することを「禁止」する統治文書改訂を採択しました。公式ブログの見出しは端的に「DIF Bans Agents」。人間がAIツールを補助的に使うことはあっても、投稿・意思決定の責任は必ず人間が負う、という原則を明確化した措置です。技術的な認証・委任の基盤整備が急速に進む一方で、標準化コミュニティ自身の運営はあくまで人間が責任を持つ、という姿勢の表れです。DID Methods WG共同議長のChristian Saucier氏が7月に公開した論考では、AIエージェントをDIDの検証可能なファーストクラス・サブジェクトとして扱うべきだと論じています。両者を合わせて見ると、「技術的には検証対象として扱い得るが、コミュニティ運営上の責任主体とはしない」という整理が見えてきます。
取引意図・Mandateレイヤー：決済の実装基盤に合流
自律的な決済を扱うMandateレイヤーでは、GoogleのAgent Payments Protocol（AP2）がFIDOのPayments TWGに寄贈され、MastercardのVerifiable Intentと並んで検討されています。AP2の現行仕様はCheckout MandateとPayment Mandateを用いて、購入内容と支払い権限を署名付きデータとして表現します。ユーザーがその場にいないHuman Not Presentのフローでは、事前にユーザーが承認した条件と、エージェントが具体化した取引内容を暗号的に結び付けることで、自律的な決済を実行するモデルを採用しています。決済分野の標準化が既存のFIDO・Mastercard・Visaの枠組みに合流し、実装が現実的な段階に入りつつあります。
責任の所在をめぐる問い
技術標準とは別に、「誰がエージェントの背後で責任を持つか」という論点も複数の場所で独立に浮上しています。OpenID Foundationを中心とする議論でも、エージェントの登録、所有者、委任された権限、監査、廃止を含むIdentity Governanceの必要性が指摘されています。これは、エージェントの行動に対して誰が責任を負うのかという問題と直結します。プラットフォームの実装が進むほど、この問いは切実になります。Microsoftは2026年春にMicrosoft Entra Agent IDとしてエージェント向けID管理基盤の提供を進め、AWSのBedrock AgentCoreも機能拡張を続けています。一方、Unit 42は、Bedrock AgentCore Starter Toolkitが自動生成するIAMロールが、本番利用には過剰に広い権限を持ち得ると指摘しました。認証・認可の仕組みが整っても、権限設計が伴わなければ機能しない好例です。
まとめ
この数ヶ月を俯瞰すると、レイヤーごとの進み方には非対称性があります。ユーザー認証・API認可の周辺仕様は着実に固まり、Credential表現の分野は技術的な進展が目立つ一方、WIMSEによるWorkload認証の標準化はまだInternet-Draft段階にあります。また、AIエージェント固有の証明書登録を扱うdraft-huang-acme-scalable-agent-enrollmentは初版のまま失効しており、目立った進展がありません。一方で、ACMEを用いたRATSやデバイス・アテステーションの標準化は別途進んでいます。「単一の標準では完結せず、複数レイヤーの組み合わせで成立する」という骨格は変わっていませんが、レイヤー間を橋渡しする仕様が具体化してきたこと、そして技術の標準化が急速に進む一方で「誰が責任を持つか」という統治の議論はまだ模索段階にあることが、対比として見えてきます。PKI/CAが長年向き合ってきた「信頼をどこに置くか」という問いが、形を変えてエージェントの世界にも現れている、という印象を持っています。
