只設預算，不足以約束 AI 智慧體支付

為 AI 智慧體設定消費限額，看起來是一種負責任的自動化方式。

但它遠遠不夠，而且容易製造危險的安全錯覺。

每日預算只能回答一個問題：一個週期內最多允許流出多少價值？它無法回答誰可以收款、哪個服務可以發起付款要求、允許使用什麼資產、審批後的報價是否發生變化，以及請求超時究竟代表付款失敗還是回應丟失。

一臺始終沒有超出預算的智慧體，仍然可能向錯誤的收款人支付一百次。

如果自主系統能夠花錢，它需要的不只是錢包和一個數字，而是一套把業務意圖繫結到簽名者最終授權交易的支付策略。

限額控制數量，卻不說明用途

假設一個研究智慧體每天最多可以消費 10 USDC。這個規則看起來相當保守，但如果它是唯一控制措施，就可能允許：

• 向營運人員從未批准的服務支付 10 USDC
• 因重試迴圈重複支付 100 次，每次 0.10 USDC
• 在錯誤網路上向格式相同的地址付款
• 為一項有效服務付款，但收款人在預覽與執行之間已經改變
• 為一項 POST 請求付款，但請求正文並不是使用者稽核過的內容
• 第一次請求超時後重新授權，而前一筆轉帳其實已經成功。

所有這些結果都可能沒有超過每日限額。

因此，預算是會計邊界，不是完整的授權邊界。它能夠限制總體風險敞口，卻無法說明為什麼允許某一筆付款。

其他安全系統早已體現了同樣的區別。資料庫角色不會只用可執行查詢的數量定義，雲身份也不會因為設定了月度帳單提醒就自動變得安全。資金許可權同樣需要明確作用域。

把購買表示成結構化許可權

智慧體付款許可權應該表示成結構化意圖，而不是“模型可以使用這個錢包”。這項意圖至少需要繫結：

這就是“把錢交給軟體”和“向軟體分配一項可能需要花錢的明確任務”之間的區別。

模型可以判斷自己需要購買天氣記錄、市場資料集或推理結果，但它不應該成為最終授權者，不能獨自決定任何聲稱提供該資源的地址都有權收款。

分離四個信任邊界

把四種職責分開以後，智慧體支付會更容易理解和驗證。

1. 智慧體執行時負責請求

執行時選擇資源並提出購買請求。它只持有受限且能夠撤銷的憑據，並且只能訪問自己的付款嘗試。

它不應該持有組織管理金鑰，不能修改自己的限額、批准自己的例外、登記替代錢包，也不能呼叫通用簽名方法。

即使模型本身行為正常，這種隔離仍然必要。執行時會處理不受信任的工具輸出、遠端內容和提示詞。依賴項入侵或提示詞注入不應因此繼承資金庫的完整許可權。

2. 控制平面負責決策

控制平面把擬議購買與生效策略和目前預算進行比較，並決定拒絕、自動批准，或暫停等待人工判斷。

決策應該使用經過歸一化的結構化資料，而不是自然語言描述：資源來源、收款人、網路、資產、準確金額、智慧體身份和請求身份。對於包含寫入內容的請求，還應繫結 HTTP 方法與請求正文摘要。

3. 人工審批負責處理例外

一次審批應該只授權一項已經鎖定的意圖，而不是永久放寬支付策略。

如果稽核後的收款人、網路、資產、方法、請求正文或金額髮生變化，舊審批就不應繼續有效。新請求必須被拒絕，或重新等待人工判斷。

只顯示“是否允許此智慧體支付 2 USDC？”的審批介面，隱藏了稽核人員真正需要的資訊。介面應說明將購買什麼、資源來自哪裡、誰會收款、使用哪條網路和哪種資產，以及這一操作能否安全重試。

4. 簽名者負責驗證

持有錢包金鑰的程序不能僅僅因為與智慧體執行時屬於同一家公司，就預設信任它。

更安全的做法是隻接受控制平面簽發的短期執行授權，並驗證付款載荷是否與每一項授權欄位完全一致。執行授權應繫結智慧體、錢包、環境、網路、資產、收款人、金額、隨機數和有效時間。重放、過期授權、未知簽發金鑰以及欄位不一致都必須預設拒絕。

簽名介面與金鑰儲存同樣重要。即使私鑰放在 AWS KMS 中，如果外部仍然可以呼叫通用的 sign(anything) 端點，就只是把無限制能力搬到了網路介面後面。受限簽名者只應開放與付款有關的特定操作。

執行時使用的策略必須不可變

可變策略會製造一個很難回答的審計問題：十分鐘前發生的付款，究竟由哪一版規則授權？

應該為策略文件建立版本，並讓每一個已啟用版本保持不可變。新增允許列表或修改限額時建立新版本，而不是原地覆蓋舊策略。每一項付款意圖都記錄決策時使用的策略版本。

一份精簡策略可以寫成：

const policy = {
  allowedOrigins: ['https://data.example.com'],
  allowedPayTo: ['0x1234567890abcdef1234567890abcdef12345678'],
  automaticPaymentThresholdAtomic: '250000', // 0.25 USDC
  perPaymentLimitAtomic: '1000000', // 1 USDC
}

這份文件把請求分成三種結果：

• 超過單筆硬上限的請求直接拒絕，人工審批不能悄悄繞過硬限制
• 未超過硬上限，但不在自動允許範圍內或超過自動付款閾值的請求等待審批
• 資源來源、收款人、金額、網路、資產和預算全部透過時，請求才可以自動繼續。

每日預算仍然重要。應該同時設定組織預算和智慧體預算，避免一個執行時消耗整個組織的可用額度。預算還必須在簽名前以原子方式預留，否則併發請求可能同時看到相同的剩餘額度，最終合計超過限制。

但是，只有策略能夠解釋為什麼允許這筆支出，預算只能證明當時還有容量。

報價改變後，預覽與審批仍應有效約束付款

x402 這樣的 HTTP 原生支付協議，可以讓資源伺服器返回付款要求，並讓用戶端帶上付款憑據重試原始請求。它解決了一個重要的協議問題：價格、付款載荷、驗證步驟、結算步驟和資源回應如何組成一次 HTTP 交換。

但它不會替每一個組織決定智慧體應該購買什麼。

從首次預覽到正式執行之間，資源伺服器可能返回一項更新後的付款要求。安全用戶端應該把它與已批准意圖進行比較。如果策略明確允許，更低金額或許可以接受。不同的收款人、來源、網路、資產、請求正文或更高最高金額，則代表另一項購買。

欄位繫結審批的複雜性在這裡發揮價值。智慧體不能拿“購買 example.com 的一份報告”這項審批，去授權一個上傳了不同資料或向另一個地址付款的修改後請求。

超時表示結果不確定，不表示可以重新付款

最危險的重試發生在簽名之後。

設想下面的過程：

1. 支付策略允許一項購買
2. 簽名者授權完全匹配的付款
3. 用戶端傳送付費請求
4. 用戶端在收到資源或結算回應之前超時。

付款可能失敗，也可能已經成功。

立即建立新意圖可能造成重複扣款，而且兩筆付款都符合允許列表與單筆限額。正確狀態不是 failed，而是在證據確定結果之前保持 settlement_unknown。

恢復流程需要穩定身份：

• 同一次購買嘗試始終複用一個任務級冪等鍵
• 持久儲存原始付款意圖編號
• 審批後恢復原意圖，而不是建立新意圖
• 超時後查詢並對帳原始付款
• 永遠不要把“沒有收到回應”解釋成“沒有發生轉帳”。

自主系統往往會積極重試，因為這種行為對普通軟體任務很有幫助。支付工具則必須用明確的不確定狀態替代這種樂觀假設。

審計記錄必須能夠還原決策

營運人員調查一筆智慧體付款時，應該能夠回答：

• 哪一個智慧體和任務發起了請求？
• 哪一個策略版本執行了判斷？
• 繫結了哪個來源、方法、網址和請求正文摘要？
• 批准了哪個收款人、網路、資產和金額？
• 預留了多少組織預算與智慧體預算？
• 付款是自動透過還是人工批准，由誰批准？
• 哪一項執行授權和哪個簽名者完成了簽名？
• 資源請求返回了什麼結果？
• 鏈上交易引用和結算狀態是什麼？

不能為了讓記錄看起來完整，就把錢包私鑰、完整付款簽名、原始執行授權或敏感回應正文寫入日誌。審計能力來自穩定識別符號與摘要，而不是把秘密複製到日誌中。

智慧體支付的最低控制模型

啟用自動付款前，至少應該具備：

• 一臺專用支付智慧體及能夠撤銷的執行時憑據
• 一個只用於明確目的和環境的錢包
• 包含準確來源與收款人的不可變策略版本
• 針對付款要求執行網路與資產驗證
• 單筆硬上限、智慧體每日預算和組織每日預算
• 不高於單筆硬上限的自動付款閾值
• 對未知物件或超過自動閾值的請求進行人工審批
• 把審批繫結到準確 HTTP 請求和付款欄位
• 由客戶控制且不提供通用簽名介面的簽名者
• 短期且只能使用一次的執行授權
• 重試過程中保持穩定的冪等鍵與意圖編號
• 明確的結算不確定狀態與對帳路徑。

最初應把自動付款閾值設為零，在人工審批下完成第一筆付款。驗證完整記錄後，只加入一個已知來源和收款人。提高自主程度的方法應該是縮小已知安全路徑，而不是向模型提供許可權更大的憑據。

如果準備把這套控制變成上線驗收流程，可以繼續使用生產環境的 12 項 AI Agent 支付安全檢查清單，按可驗證證據評分並完成故障演練。

為什麼我們要建置這一層

StableOps 智慧體支付圍繞上述邊界設計。智慧體執行時只獲得受限的 Agent Key。不可變策略和兩層預算共同約束每一項意圖。未知物件或超過自動閾值的購買需要等待審批。短期執行授權允許客戶自行部署的簽名者完成簽名，而錢包金鑰或 KMS 許可權始終保留在客戶環境中。

我們的目標不是讓每一筆付款都自動執行，而是清楚定義哪些付款可以自動進行、哪些需要稽核、哪些必須禁止，並在網路超時、報價改變和程序重啟時繼續守住這條邊界。

智慧體預算告訴你它最多可以花多少。

支付策略決定這項購買是否應該存在。