x402、AP2、委任型チェックアウトでエージェントの支出制限を徹底する

目的

2026年10月25日時点の情報である。無人での購入や再試行も含め、すべての支払いを、範囲が限定されたユーザーの承認に紐付けられるようにする。この提案手順を実装する前に、x402の対象範囲、AP2の制約スキーマ、採用するACPスナップショットを再確認する。プロトコルのフィールドは制御を支えるものであり、実際の強制は独立したコンポーネントが行わなければならない。

前提条件

モデルの外部でポリシーを強制する決済ゲートウェイまたは署名コンポーネント、永続的な承認台帳、認証付きの承認インターフェース、支払い状態の記録へのアクセスを用意する。未解決の取引について責任者を定める。支出を許可する前に、各承認のプロトコルのリビジョン、通貨または資産、金額の表現方法、許可された支払先、有効期限を記録する。

手順

1. 取引ごとの上限を設定する。 AP2のPayment Mandateはpayment.amount_rangeを定義している。ACPの委任された利用枠には、max_amount、通貨、有効期限がある。x402では、署名前に提示された支払い要件とローカルポリシーを比較する。上限は、チェックアウトの合計に含まれる各種料金も含め、最終的に承認する金額に適用する。

2. 累積支出を集計する。 AP2のpayment.budgetはpayment.agent_recurrenceと併用され、要求金額と過去のclosedのMandateの金額を合算しても上限を超えないことを求める。承認時には、その金額が累積額に加算される。この確認と予算の予約を、共有ストレージ上でアトミックに実装する。集計規則の提案として、結果を照合できるまで未解決の試行分を利用可能予算から差し引いたままにする。x402のコア仕様は、クライアント側の予算管理を対象外としている。

3. 支払先と支払い手段を制限する。 AP2には、checkout.allowed_merchantsのほか、支払いの受取人と支払い手段の制約がある。ACPは利用枠を販売者とチェックアウトセッションに結び付ける。x402では、リソースのオリジン、支払いの受取人、資産、ネットワークを対象とする外部の許可リストを管理する。販売者についての説明文を、検証済みの身元情報とみなしてはならない。

4. 人による承認を具体的な条件に結び付ける。 購入者に支払先、商品、総額、支払い手段、有効期限を示す。事前委任の場合は、代わりに許可する範囲を示す。AP2の承認フレームワークは制約の評価を必須とし、未知の制約を失敗として扱う。unresolved_constraintレスポンスを受けて、直接承認を求めることができる。ローカルポリシーとして、承認範囲を超える変更には、支払い資格情報が技術的にはまだ使える場合でも、改めて承認を求める。

5. 資格情報を漏らさずに証拠を結び付ける。 承認とMandateへの参照、ポリシー判定、予約金額、チェックアウトまたはリソースの識別子、支払い識別子、最終結果を記録する。AP2のPayment ReceiptはclosedのMandateに紐付き、支払い状態を含む。機密性の高い署名付き資格情報は、アクセスを制限した証拠保管領域に置く。通常の監査ログには、再利用可能な支払い情報そのものではなく、その参照を記録すべきである。支払いと提供は別々に照合する。

6. 運用開始前に拒否時の処理を試す。 本番以外の環境で、期限切れの承認、許可されていない販売者、通貨の変更、上限超過の金額、同時進行の購入、レスポンスの中断を試す。拒否された試行が新たな承認を作らず、未解決の試行によって支出可能額が暗黙に回復しないことを確認する。これらは受け入れ確認の提案であり、テスト結果を報告するものではない。

期待される結果

許可されたすべての試行に、追跡可能な承認、予算の予約、そして最終的に照合された結果がある。要求が拒否された理由は、モデルに判定を覆す権限を与えなくても説明できる。レビュー担当者は、要求された支出、承認された支出、完了した支出を区別できる。

限界と検証の根拠

この手順は決済プロバイダーに対して実施していない。複数のプロバイダーをまたぐ予算には、個々のプロトコルオブジェクトを超えた共通の集計が必要である。AP2の金額範囲の表は最小通貨単位の整数を指定する一方、例の1つでは小数を使っている。金額を受け入れる前に、実装上の契約でこの不整合を解消する。本記事では換算方法を推定しない。署名付きReceiptが記録するのはプロトコル上の結果であり、現物の引き渡しを証明するものではない。