Mastercardが発表した内容
Mastercardは10月20日、Cloudflare、Ant International、AIsa、Base、BVNK、Coinbase、Hypeとのend-to-end pilotを経て、Agent Pay for Machinesのearly accessを開始しました。同社によると、初期releaseにはbuyer側とseller側のAPI、toolkit、sandbox、developer documentationが含まれます。Early access pageは、serviceが引き続きpilotでありcommercial availabilityには至っていないとも明記しています。ここまではMastercardが公表した機能とstatusであり、以下はIneezaの本番運用分析です。
この設計はx402を基盤とします。MerchantがHTTP 402を返し、承認済みtaskとspending limitの下で動くagentがdigitally signed voucherを作成し、merchantがservice提供前に検証します。Mastercardはinteractionがoffchainで行われ、voucherをまとめて後からredeemでき、参加infraを通じてfiatまたはstablecoinでsettleできると説明しています。
Mastercardのdemonstrationでは、一つの承認済みbudgetから二つのmerchantへresearchとimage generationのため9回支払いました。これはpilot demonstrationであり、commercial availability、本番throughput、不正対策性能、settlement guaranteeの実績ではありません。
Spending limitだけでは完全な認可policyにならない
Budgetは合計金額を制限しますが、許可されるmerchant、service、purpose、unit price、geography、data class、time windowを単独では定義しません。侵害されたagentは数値上の上限内に留まりながら、未認可resourceを購入したり、許可済みresourceを別taskのため繰り返し購入したりできます。
Ineezaの分析: 各voucherはprincipal、agent instance、merchant identity、resourceまたはquote digest、currency、maximum amount、nonce、issuance time、expiry、policy versionを結び付けるべきです。Merchant verificationはそれらのclaimと認証済みrequestを同時に評価する必要があります。永続的な認可判断は「このagentは支出可能」ではなく、「このprincipalがこのpolicyの下でこの購入を委任した」です。
Offchainの速度はriskをreplay、revocation、exposureへ移す
署名付きvoucherにより、merchantはonchain settlementを待たずにpayment promiseを検証できます。Machine-to-machine requestのlatencyを減らせる一方、service提供済みでもredemptionとfinal settlementが未完了の期間が生じます。
Ineezaの分析: Protocolにはregion、retry、merchant replicaをまたぐ明確なreplay scopeとone-time consumption semanticsが必要です。Platformは、revoked agent、侵害されたsigning key、使い切ったbudget、変更済みpolicyが無効になるまでの最大時間を定義し、principalとmerchantごとに未redeem exposureを制限し、revocationまたはbudget stateがpolicy上の期限を超えて古い場合はfail closedにすべきです。
Aggregationには検証可能なredemption ledgerが必要
Mastercardはproviderがvoucherをまとめて後からredeemできると説明しています。Aggregationは小額購入を経済的にできますが、一つのsettlement eventが独立に認可された多数のdeliveryを表すことになります。
Ineezaの分析: 各voucherにはissued、accepted、delivered、submitted、redeemed、settled、expired、rejected、disputedをたどるimmutableなstate pathが必要です。Batchはmemberとamountへcommitし、voucherの欠落、重複、差し替えがないことをplatformが証明できるべきです。Agent budget ledger、merchant delivery ledger、redemption batch、wallet movement、fiatまたはstablecoin settlement recordを同じidentifierでreconcileする必要があります。
Discoveryとverificationは別のtrust問題である
Pilotではagentが参加service providerを発見し、各sellerがvoucherを検証します。Discoveryはagentがrequestを送れる相手を決め、voucher verificationはsellerがpayment promiseを信頼できるかを決めます。どちらも購入serviceの品質、合法性、entitlementを証明しません。
Ineezaの分析: Provider registrationは認証済み、version管理済みで、ownershipやendpoint変更を監視すべきです。Buyerにはallowlistまたは新規merchant向けrisk-based policyが必要で、sellerには予測可能にfailするissuer key rotationとstatus処理が必要です。Delivery認可、payment認可、provider trustを別の判断として保ちつつ、共通audit trailへ結ぶべきです。
Ineezaの見解
Agent Pay for Machinesが重要なのは、自律的なservice購入でaccount、API key、prepaid credit、providerごとのbilling relationshipに代わる具体的な方式を試すためです。本番の境界はvoucher lifecycleです。委任authorityはidentityやstateを失わず、signing、verification、delivery、aggregation、redemption、settlement、revocation、disputeを通過する必要があります。Machine-speed paymentが有用なのは、各購入を誰が認可し、何が提供され、どのexposureが残り、最終的なmoney movementがどう債務を閉じたかをoperatorが正確に再構築できる場合だけです。