要約

  • 9月27日付の個人Internet-Draft「Capability Language Core」は、allowとdenyに加え、条件が残るallow_unresolvedを提案した。
  • 時刻やネットワークの条件を中核部が評価できなければ、実行側が全部確認するか拒否する。草案のテスト通過は独立した相互運用性の証明ではない。

許可された道具をAIエージェントが呼ぶ。だが、その許可には「特定のネットワークから」「決められた時間帯だけ」という但し書きがある。権限を読む共通プログラムは但し書きの形式を理解できても、実際の接続先や現地の時刻判断を持たないかもしれない。そこで単純な許可を返せば、但し書きは失われる。Jijie Weiの草案は、この空白を例外表示ではなく独立した判定にしようとしている。

2026年9月27日に提出されたdraft-wei-capability-language-core-00は、Experimentalを意図する個人草案だ。IETF Datatrackerの状態はI-D Existsで、同ページは個人の提出にIETF標準化上の正式な地位がないと明記する。RFCでも採用済みの作業部会文書でもない。提案の対象は、能力を表す識別子、許可と具体的操作の包含関係、複数の許可の共通部分、そして理由コード付きの決定手順である。

第8.4節では、形式として認識できる時刻・ネットワーク条件でも、v1の中核に評価器がなければ消してはならない。条件をunresolvedに残し、結果をallow_unresolvedにする。これはallowの別名ではない。決定を受け取るポリシー適用点や宣言元の方式が、残った条件を一つずつ評価または確認して初めて実行を許せる。確認できない場合は拒否する。二つの条件が残れば両方必要で、一方の成立をもう一方の代わりにはできない。

続くResolveは、受け手が各条件について満たした・違反した・不明のいずれかを戻し、判定を更新する仕組みだ。返答の道筋が整っても、接続網の観測者や時刻の根拠が自動的に生まれるわけではない。二値しか想定しない既存の接続部が、deny以外を一律に通すなら、草案の狙いは実行直前に崩れる。これは仕様から導かれる実装上の注意点であり、現実の製品に欠陥が見つかったという話ではない。

草案は自らの守備範囲を限定している。許可を発行した主体の信頼、署名など元の媒体の検証、実行後の経過、証拠やトークンの共通形式は別の取り決めに委ねる。OAuthのRFC 9396は細かな認可情報を運ぶauthorization_detailsを定めているが、CLCはそれを利用可能な媒体の例として挙げるにとどまる。RFC 9396がCLCの安全性や採用を保証するわけではない。

CLC-Aについて草案は123件のベクトルと1184件の性質テストを掲げ、Go・Python・TypeScriptの実装が通過したと記す。ただし実装は同じ著者によるものだ。草案自身、これは記述の回帰テストであって独立検証ではなく、独立した二実装という成熟条件は未達だと認める。証拠側のCLC-Eも主張していない。詳細な規則があることと、異なる実装者の間で安定して動くことは別の段階にある。

出典