Cloudflare Wallets 姍姍來遲
Cloudflare 在其 Agents Week 期間宣布推出 Cloudflare Wallets，為 AI 代理程式提供穩定幣餘額，並提供 cloudflare.pay handle，以便在支付 API、資料與內容時出示。目前僅有領取 handle 的功能可用。資金注入與付款功能預計將在未來幾個月內推出。
這項已上線的功能已引發抱怨。在 Hacker News 上，留言者 merek 發現自己的公司名稱與多個變體已被搶注：
沒有域名驗證，這名使用者的意圖除了詐欺／冒充之外還能是什麼？
他補充，自己已經有一個冒充者在以他的品牌經營網站，並讓顧客感到混淆。留言者 nikolay 將此次推出與 Meta 處理保留使用者名稱的方式進行對比，Meta 會事先通知並提供平等的起跑點，並對此產品做出結論：
Cloudflare 的做法基本上是推我不要使用他們的產品，因為我無法取得自己的使用者名稱。
付款運行於 x402，該協議 repurposes HTTP 402 Payment Required 狀態碼，用於機器原生的微支付。Coinbase 最初提出此概念，目前由 Linux Foundation 主持，約有 40 位成員，包括 Cloudflare、Stripe、Visa、Mastercard、Google 與 Amazon Web Services。MCP 也走過同樣的路，從單一供應商轉移到 Agentic AI Foundation，理由相同。一個每個競爭者都必須實作的協議，若置於基金會內，對其創始者而言比自己掌控更有價值。
基金會主持解決了誰擁有規格的問題，但未解決誰能在其上競爭的問題，而 Cloudflare 較晚進入這個領域，該領域已有來自 AWS、Google Cloud、Circle 以及各大卡組織的解決方案。其論點在於分發能力。Wallets 是其於 7 月 1 日推出的 Monetization Gateway 的買方補充方案，後者讓網站與 API 能透過相同軌道向代理程式按請求收費。同時握有兩端意味著商家能向代理程式收費，而代理程式也能支付他們，橫跨 Cloudflare 所稱涵蓋 337 個城市、觸及約五分之一網站的網路。
數位留言者認為這篇公告與付款無關，而是關於其他事情。留言者 eddythompson80 指出，代理程式身分至今仍被困在個別系統內，因為 AWS IAM 指派的身分無法在不相關的網站上使用，而 OIDC 聯邦對一般網站來說太過複雜。障礙從來不是機制，而是無法就提供者達成共識：
同意單一 IdP 才是問題，目前大約有 40 個。
他的結論是 Cloudflare 看到了這個機會：
這有真正的需求，看起來 cloudflare 認為如果他們成為「網際網路代理程式身分提供者」，那麼就能對網際網路與 AI 使用擁有大量的權力與控制。
留言者 wxw 提出了平台版本的相同觀點，指出 Durable Objects 與 Workers 是良好的代理程式基礎元件，因此已經在使用它們的團隊不妨也採用 wallet、sandbox 與 AI gateway。其他人則沒那麼放心。留言者 Ycros 寫道 Cloudflare 不斷將自己插入一切事物之間，nater5000 回覆表示，一家在自家市場中打造有明確需求的產品的公司不需要進一步解釋。
值得仔細閱讀的部分是控制模型。每個帳戶持有人會獲得一個 Account Wallet，並可為每個代理程式建立獨立的 Virtual Wallets，從主帳戶提供資金，並受帳戶持有人設定的三項控制所限制：額度、核准商家的允許清單，以及最大交易金額。明確的目的是讓代理程式能夠測試與購買服務，而無需人類核准每一筆付款，並有硬上限來限制損害。
Cloudflare 儀表板中的 Account Wallets 與 per-agent Virtual Wallets（來源：Cloudflare 部落格）
這些基礎元件描述的是預算而非政策。額度是一個持續的總額。允許清單是一個集合成員資格測試。最大交易金額是一個每次請求的限制。每一個都是針對目前付款與固定限制進行評估，沒有一個能表達付款之間的關係。
平台團隊通常想要的規則會表達關係。一個代理程式只能支付它已經對照核准目錄檢查過的供應商。它不能在一小時內為同一件事支付兩個供應商。它必須在第一次向新商家購買前取得核准。每一個都需要針對序列而非目前請求進行推理。
並行性提出了相關問題。代理程式會平行發出動作，因此多筆付款可能在尚未扣減額度的情況下進行檢查，且每一筆都通過了它們總和已超過的上限。Cloudflare 尚未公布其額度在並行支出下的行為，這在讓代理程式無需逐筆核准即可交易前值得先確認。
這種模式並非 Cloudflare 特有。此領域的供應商推出的都是限制而非政策語言，而每一家都將這些限制的組合留給上層應用程式。
對正在評估代理程式付款的團隊來說，問題很明確。支出政策應該存在於錢包還是應用程式？當多個代理程式動作平行執行並使用同一筆預算時會發生什麼？以及供應商提供的是限制還是語言，因為這決定了有多少東西必須自行建置。
x402 是一條可運作的軌道，而誰來治理它的問題也已解決。一個代理程式在一連串付款中能夠支出多少，則尚未解決。