AIエージェントの決済に『1回あたりの予算上限』を持たせる──DAAPというIETFドラフトの中身は1社の製品仕様だった

AIエージェントがフォーム送信・決済・メール送信などを人間の代わりに行うようになる中で、「誰が」「どのエージェントに」「何を」「いつまで」許可したのかを、機械的に検証・取り消しできる形で残す必要が出てくる。IETF個人ドラフト「Delegated Agent Authorization Protocol（DAAP）」（rev01、2026年3月2日提出）の本文を確認すると、DID（分散識別子）ベースの身元証明からJWTトークン、監査ログ、予算管理まで、かなり広い範囲を一体で定義する野心的な仕様であることが分かる。その一方で、この記事を書くために付録まで読み進めると、この提案が誰の製品を土台にしているかも見えてくる。

3行まとめ

• DAAPは「人間が特定のAIエージェントに特定の行動を許可した」ことを検証可能にする、OAuth 2.0を土台にしたモデル非依存・フレームワーク非依存の認可プロトコルのドラフト。DIDによるエージェント身元、署名付きJWTグラントトークン、ハッシュチェーン監査ログ、カスケード失効付きのマルチエージェント委任、支出上限を守る予算管理などを含む
• rev01（2026年3月2日提出）で「予算管理」「イベントストリーミング」「認証情報保管庫」「OPA/Cedarとの外部ポリシー連携」の4機能が新規追加。Appendix Bの「実装レポート」によれば、参照実装は提出者Sanjeev Kumar氏自身の製品Grantexの認可サーバー（Fastify + PostgreSQL + Redis）で、エージェントのDIDもdid:grantex:<agent_id>というGrantexの名前空間を使う設計だった
• 2026年8月30日提出のrev02では、DIDが任意に格下げされ、予算管理・監査・ポリシー・イベント・認証情報保管庫がコア仕様から切り出され、Grantexの実装は「適合ではなく部分的」と明記されるなど、rev01で見えていた「1社の製品仕様」的な特徴の多くが本文中で自己修正されていた

DID・JWT・監査ログを一体で持つ設計

ドラフトの要約はこの仕様の範囲をこう説明している。

This document defines the Delegated Agent Authorization Protocol (DAAP), an open, model-neutral, framework-agnostic protocol that specifies: cryptographic agent identity using Decentralized Identifiers (DIDs); a human-consent-based grant authorization flow modelled on OAuth 2.0; a signed JSON Web Token (JWT) grant token format with agent-specific claims; a revocation model with online verification; a hash-chained append-only audit trail [...]

（本文書はDelegated Agent Authorization Protocol（DAAP）を定義する。これはオープンで、モデル非依存・フレームワーク非依存のプロトコルであり、分散識別子（DID）を使った暗号学的エージェント身元、OAuth 2.0をモデルにした人間の同意ベースの権限付与フロー、エージェント固有のクレームを持つ署名済みJWTグラントトークン形式、オンライン検証付きの失効モデル、ハッシュチェーンされた追記専用の監査証跡……を規定する）

エージェントの身元はdid:grantex:ag_01HXYZ123abcDEF456ghiのようなDID形式で表現され、この識別子は開発者・エージェント名・宣言済みスコープ（例：payments:initiate:max_500のように上限金額を含むスコープ）を持つ身元文書に解決される。

予算管理——1グラントに1つの支出上限、原子的なデビット操作

支出面での具体的な設計として「予算管理（Budget Controls）」がある。

Budget Controls provide per-grant spending limits that constrain the total monetary value of actions an Agent may perform under a single Grant. This extension is critical for agents operating in financial contexts (e.g., payments:initiate) where unconstrained spending could cause irreversible harm.

（予算管理は、1つの権限付与（Grant）のもとでエージェントが実行できる行動の合計金額を制約する、グラント単位の支出上限を提供する。この拡張は、無制限の支出が不可逆な損害を引き起こしうる金融の文脈（例：payments:initiate）で動作するエージェントにとって重要だ）

ドラフトが示す予算割り当てのAPI例はこうだ。

POST /v1/budget/allocate
{ "grantId": "grnt_01HXYZ...", "amount": 10000, "currency": "USD" }

「1つのグラントは同時に1つのアクティブな予算割り当てしか持てない（MUST NOT）」という制約も明記されている。

Appendix Bで分かる——参照実装は提出企業自身の製品

このドラフトの実装状況を記した付録がこうだ。

This appendix documents the conformance status of the reference implementation and SDK coverage as of March 2026. [...] The Grantex authorization server (Fastify + PostgreSQL + Redis) implements all REQUIRED endpoints and the following OPTIONAL extensions

（この付録は、2026年3月時点での参照実装とSDKカバレッジの適合状況を記録する。Grantexの認可サーバー（Fastify + PostgreSQL + Redis）は、すべての必須エンドポイントと、以下のオプション拡張を実装している）

この付録の表によれば、ポリシーエンジン・Webhook・異常検知・SCIM 2.0・SSO（OIDC）・予算管理・イベントストリーミング・認証情報保管庫・外部ポリシー連携のすべてが「Implemented（実装済み）」となっている。つまりDAAPは、Grantex社という提出企業自身が既に構築している認可基盤の設計を、IETFドラフトという形式で書き起こしたものだと読める。DIDの名前空間自体がdid:grantex:とその企業名を冠していることも、この読み方を裏付ける。

rev02(8月30日提出)で、まさにこの「1社製品」問題が書き直されていた

この記事の元になったrev01は2026年3月2日提出だったが、IETF Datatrackerを2026年8月31日に確認し直すと、ドラフトはすでにdraft-mishra-oauth-agent-grants-02まで進んでおり、最終更新は2026年8月30日、有効期限は2027年3月3日に延びていた。rev02のAbstractには、rev01には無かった一文が加わっている。

Operational facilities such as policy engines, audit stores, budgets, event streams, and credential vaults are outside the interoperable core. Grantex is an incomplete reference implementation and is not required for conformance.

（ポリシーエンジン・監査ストア・予算管理・イベントストリーム・認証情報保管庫といった運用機能は、相互運用可能なコア仕様の対象外である。Grantexは不完全な参照実装であり、適合のために必須ではない）

さらに本文の変更点まとめ(Section 1.3)には、rev01からの変更として次の項目が明記されていた。

makes DID use optional and requires proof of possession for any advertised agent key; moves audit, budget, policy, events, and credential-vault behavior outside the interoperable core; and reports the Grantex implementation as partial rather than conformant.

（DIDの使用を任意にし、公開されるエージェント鍵には所有証明を必須にする。監査・予算管理・ポリシー・イベント・認証情報保管庫の挙動を相互運用可能なコアの対象外に移す。そしてGrantexの実装を「適合」ではなく「部分的」と報告する）

つまりこの記事がrev01から読み取った「予算管理までコア仕様に含む野心的な設計」「DIDの名前空間が提出企業名を冠している」という2つの特徴は、rev02ではいずれも修正されている。

DIDは必須ではなくなり、予算管理はコア仕様の外に切り出され、Grantexの実装自体も文書内で「部分的(partial)」「まだ適合実装ではない(not yet a conformant implementation)」と明記されるようになった。Section 13(Implementation Status)には「独自の/v1/authorize・/v1/tokenエンドポイントは標準のOAuthエンドポイントではない」「PARは未実装」「DPoPの証明が保護対象リソース側で検証されていない」という具体的な未達成項目も列挙されている。

Grantexは、ドラフト提出者本人が運営する個人発の製品だった

Grantexの公式サイト(grantex.dev)を開くと、運営主体が明記されていた。

Owned by Orchestrum Technologies LLP. Inventor and owner: Sanjeev Kumar.

（Orchestrum Technologies LLPが所有。発明者かつ所有者:Sanjeev Kumar）

rev02のドラフト著者欄も「S. Kumar」「Orchestrum Technologies LLP」となっており、ドラフトの著者とGrantexの運営者が同一人物であることが両文書の記載から確認できた。つまり「1社の製品仕様」というより、Sanjeev Kumar氏個人(またはその1人が所有する小規模企業)が、自作の認可基盤をIETF個人ドラフトとして書き起こしている、という構図になる。サイトには@grantex/cli(npm, 0.3.0)・@grantex/sdk(npm, 0.5.0リリース候補)・grantex(PyPI, 0.4.0)・grantex-go(Goモジュール, v0.2.0)・@grantex/mcp-auth(npm, 2.0.2)という実際に公開されているパッケージ一覧があり、サイト自身が「MCP Auth 2.0.2はシングルプロセスの評価用ソフトウェアで、インメモリのcode状態・レンダリングされた同意画面が無い・バックエンドのcodeハンドオフが不完全」という制限を明記していた。ドラフト側の「Grantexは不完全な参照実装」という記述と、サイト側の自己申告の両方が一致している。

これをどう見るか

IETFの個人ドラフトは、特定企業が自社製品の設計を「業界標準案」として提示すること自体は珍しくない仕組みだ。むしろ、実際に動く実装を持つ提案の方が、机上の空論より現実的だという見方もできる。一方で、DIDの名前空間が特定ベンダーに紐づいている点は、これが本当に「モデル非依存・フレームワーク非依存」なオープン標準になりうるかという点で、標準化の初期段階にある提案が抱える典型的な緊張関係を示している——この記事ではその評価まで踏み込まず、ドラフト本文と付録から読み取れる事実を提示するにとどめる。

スコープ設計の安全性と、rev01→rev02の細部の差分までは検証していない

このドラフトが今後IETFのワーキンググループに採択される見込みがあるかどうかは、この記事の一次ソースからは読み取れなかった。Grantexの運営者(Sanjeev Kumar氏、Orchestrum Technologies LLP)についても、公式サイトに書かれている情報以上の裏取り(法人登記・サービス開始時期・実際の顧客数など)はしていない。この記事を書いている自分自身は、DIDやOAuth 2.0拡張の実装経験がなく、ここで提案されているスコープ設計（payments:initiate:max_500のような金額埋め込み型スコープ）が実務上どこまで安全かの評価もできていない。rev01からrev02への変更点は、ドラフト本文のSection 1.3(変更点まとめ)に書かれている範囲を紹介したもので、両バージョンの全文を1行ずつdiffして確認したわけではない。npm・PyPI・Goモジュールとして公開されているという各パッケージも、実際にインストールして動かす検証はしていない。日本語ではZenn・Qiitaともに、DAAP単体を扱った記事は検索時点で見当たらなかった。

関連記事: AIエージェントとは

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