要約

  • IETFは、OAuthワーキンググループが2026年9月28日にオンライン暫定会合を開き、議題を「Anthropic & OpenAI Agentic Use Cases」とすると発表した。これは会合予定の証拠であり、両社が特定案を支持する証拠でも、ワーキンググループが解決策を採用した証拠でもない。
  • RARは既知の金額や受取人を細かく表現でき、DPoPはトークンを鍵へ結び付けられる。それでも、モデルが生成した値をそのまま許可オブジェクトへ写せば、候補行為が自らの権限を定義する。独立した根拠で最終引数を承認し、最初に外部効果を生む境界で照合・消費してから実行する必要がある。

エージェントに「支払いAPIを使う権限」があることと、「このIBANへ123.50ユーロを送る権限」があることは同じではない。後者の値がユーザーの注文書から来たのか、汚染されたメールから来たのか、モデルが補完したのかによって、同じAPI呼び出しの意味は変わる。

IETFの公告によれば、会合は9月28日17:00–18:00 UTCに行われる。公開された議題は一行だけである。会社名を会合の題名に見つけても、発表内容、参加者、支持案、実装計画までは推定できない。まして個人提出のInternet-DraftがIETF案になったわけではない。

OAuthのチャーターは、長期資格情報や場合によっては本人の身元を渡さず、第三者へ限定アクセスを委任するプロトコルとしてOAuthを位置付ける。すでに細粒度化の標準もある。RFC 9396はauthorization_detailsを定義し、支払い例には金額と受取人が入る。事前に確定した値をユーザーが認め、resource serverが実POSTと照合すれば、RARは十分に具体的である。

したがって「OAuthは粗い」という批判では核心を外す。問題は表現力ではなく、動的な値を正当なものにする主体である。9月1日のOAuth/WIMSE投稿は、モデルが出したtool nameとargumentsを一回の権限へ結び付けられるかと問うた。正しくスコープされたトークンでも、prompt injection後の引数を通してしまうからだ。

RARを巡る返信には重要な自己限定がある。受取人と金額が既知なら、既存のRARで処理できる。残るのは、モデル実行後に初めて現れた値が、どの信頼可能な根拠によって承認されるかという問題である。同じモデル出力を詳細なJSONへコピーしても、記述は細かくなるが判断主体は増えない。

独立性は毎回の人手確認を意味しない。人がT0で承認した予算・取引先・地域の上限、版管理された企業ポリシー、別システムが検証した注文、または例外時だけ行う追加承認でもよい。候補行為とは別の系統が、その具体値を許容範囲へ写像できなければならない。

Chenらのユースケース草案は、月曜日にピクニック計画を頼み、火曜日にparks.bookとcalendar.writeの同意画面を見る例を示す。最初の目的、選ばれた公園、料金が消えれば、ユーザーは依頼の続きかフィッシングかを判別しにくい。草案はOAuthに自然言語理解やタスク編成を担わせず、先行する制約と後の実行を結ぶ必要を指摘する。

LiuらのAgent Operation Authorization草案は、元の自然言語を入れずに操作案を構造化JWTへ変え、確認された特定操作を別のJWTで表す。提案の詳細より大切なのは、会話文と実行契約の間に責任ある変換を置く発想である。

Yossifのmandate問題文書は、人が制約を許す時点をT0、本人不在で具体行為を行う時点をT1と呼ぶ。数千回の呼び出しごとに人を戻せば自律性は消える。一方、T0の制約を運ばなければ、有効な資格情報だけを持ったT1が無制約になる。文書はT1の行為がT0内にあるか第三者が検証できることを求めるが、プロトコル動作は規定しない。

具体値の同一性を守るにはcanonicalizationが要る。JSONキー順、数値表現、暗黙の既定値、URL、ブラウザーのlive formが変われば、同じdigestを再現できないか、逆に重要な差を見落とす。ツール識別子、宛先、金額、対象ID、結果の重さを決定する全属性を、版付き規則で正規化しなければならない。

ただしdigestは権限ではない。攻撃者の口座をhashすれば、攻撃者の口座への忠実なfingerprintが得られるだけだ。digestが証明するのは前に検討した値と今の値の一致であり、その値を誰が許したかではない。

Dasのtool-binding草案は一つの実装像を出す。モデル出力をnon-effectiveなCandidate Actとして保持し、引数を正規化してdigest化し、検証と権限発行を行い、dispatch sinkで権限を確認・消費してからinvokeする。個人提出のInformational draftで知的財産に関する注記もあり、IETFが選んだ方式ではない。それでもtool_useとinvoke()を分離する配置原則は検証に使える。

sinkは「最初に現実を変えられる場所」である。HTTPならresource serverかもしれない。本地関数ならfunction map、computer useなら送信クリックを作るcontroller、MCPなら複数serverへ接続するclient側wrapperである場合がある。下流だけを守っても、同じ資格情報を使う旧経路が残れば、そちらが実際の権限モデルになる。

メールの続報は、finalized parameter digestがauthorized policy assertionと一致しない限りsinkを呼ばない、という規則案を紹介する。これは参加者の発言で標準要件ではない。しかしlive値、現在有効な権限、対象sink、replay状態を呼び出し前に確認し、単回権限を先に消費するというテスト可能な形を示す。

RFC 9449のDPoPは盗まれたtokenのreplayを減らすが、正しい鍵を持つclientの判断まで保証しない。RFC 8693のToken Exchangeはdelegationとimpersonationを扱うが、末端の引数の正しさを審査しない。actorの来歴とactの正当性を一つの緑色表示へ畳んではならない。

実行後にも別の断絶がある。権限を消費した直後にhostが落ちれば、下流へ届かなかったか、届いて結果だけ失われたか分からない。無条件retryは二重送金になり、無条件停止は正しい処理を失う。共通idempotency identityと照合処理を使い、「authorized」「submitted」「accepted」「committed」「observed」を分ける必要がある。HTTP 200やtool resultは目的達成そのものではない。

最小限のreceipt chainには、principal/policyと版、元のmandate、task context、candidate tool、consequence class、canonicalization版、final digest、独立した承認根拠、issuer、audience、expiry、sender key、sink、live digest、replay判定、consume結果、下流応答、永続状態、補償、ユーザーが見た結果を含める。task cancellationはこの鎖から派生権限と進行中のeffectを辿れなければ実装されていない。

Heng LuのMinimum Initial Specificationは、共通仕様をmandate・act・binding・sink・receiptの識別に必要な最小部分へ絞る根拠になる。各組織の承認閾値まで世界標準へ埋め込めば、新しい中央権力になる。

Reality Layersから見れば、tokenはprotocol上の事実、policy assertionはauthorization上の事実、dispatch receiptはimplementation上の事実、外部状態はoperation上の事実、利用者の目的はoutcomeである。Running-Code Primacyが求めるのは実試験だ。承認後に宛先を変える、一回権限を競合させる、旧wrapperを通す、consume直後にprocessを落とす。その時にeffectとreceiptが一致しなければ、設計図の権限は稼働系の権限ではない。

出典