要約

  • 10月27日に出た個人Internet-Draftの改訂案は、エージェントの累積支出枠について、支出済み額、未確定の許可に対する保留額、今回の請求額、判断に使った残高の版を監査記録に載せる。
  • ツールの返答が消えても保留額は消えない。同じ要求の再試行と別の支払いを区別し、古い残高を使った二重許可を複数記録の照合で探す。

返事がないから無料、とはいかない

エージェントが有料ツールを呼ぶ。画面は待ったまま、返答が届かない。ここで利用枠を戻してしまえば、最初の処理が実行済みだった場合、同じ予算を次の処理にも使わせることになる。Sankalp Gildaの新しい監査記録草案は、返答の有無と処理の結果を切り離す。結果が分かる記録ができるまで、許可した額は保留し続ける。

10月27日の告知とIETF Datatrackerによれば、これは個人Internet-Draftだ。実際の決済事故を報告した文書ではない。00版にはなかった第5.9節を加え、累積上限の下で判断がどの残高を見ていたかを記録する案を示した。

上限を守るには、一件ごとの金額が小さいことだけでは足りない。すでに使った額と、実行結果が確定していない許可額を足したうえで、次の要求を扱う必要がある。新しい consumption-state には上限を定める文書のダイジェスト、通貨単位、上限、consumed、reserved、requested、保留中の要求一覧、そして stateRevision が入る。最後の値は、判断の瞬間に読まれた残高の版だ。「残高データは数秒前」という説明だけでは、その版に未決済の許可が含まれていたか分からない。

再試行は二重請求ではない

草案は50,000ペンスの上限を例にする。すでに30,000ペンスを使い、先の12,000ペンスの許可が保留中なら、合計42,000ペンスだ。最初の呼び出しの返答が失われ、同じ要求ダイジェストで再試行した場合、12,000ペンスをもう一度足してはいけない。一方、別の12,000ペンスの要求なら合計54,000ペンスになり、拒否すべきだ。これは提案を説明する数値で、実取引の統計ではない。

保留額を確定する出口は二つある。同じ要求の後続記録が効果の発生を示せば、保留から支出済みに移す。効果が none と観測されれば解放する。返答が来なかったという事実だけでは、どちらにも移せない。何も起こらなかった処理のために一時的に枠を塞ぐ不便はある。それでも、結果が不明な処理を勝手に「未使用」と扱うよりは、委任された上限に忠実だ。

怖いのは二件目が古い stateRevision を読む場面だ。最初の12,000ペンスが保留に入る前の版なら、二件目の計算は見かけ上きれいでも、先行する約束を忘れている。草案は同じ上限文書に属する複数の記録を版順に比べ、後の許可が未決済の前の許可を保留額または支出額として追っているかを確かめる。効果が「なし」とする記録がないのに保留が解かれた場合も見つけられる。

この形式では、上限を超えた許可も記録としては有効だ。監査が悪い判断を表現できなければ、最も必要な証拠だけが「形式違反」で捨てられる。署名された記録は内部の整合性を確かめられるが、外の世界で起きたことまで自動で証明しない、と草案の安全性の節も区切っている。

残高を決める人と見届ける人

上限を設定する委任者、残高を読んで許可する判断点、実際に動くツール、効果を観測する側、記録を保管する側。同じ組織が全部を担う場合もあれば別々の場合もある。監査者が知りたいのは、次の判断が正しい版を読んだか、前の保留を数えたか、解放に必要な効果が観測されたかだ。

記録を一件だけ眺めても答えは出ない。複数件を突き合わせるための形式が今回の追加点であり、完全な記録一式を誰が渡すかは運用側の責任になる。返事が消えた後の帳簿こそ、委任の限界を守る場所だ。

原資料