AI Agent 錢包安全嗎？生產環境的 12 項支付安全檢查清單

AI Agent 錢包可以安全進入生產環境，但前提不是“餘額較少”或“設定了每日預算”，而是 Agent 無法取得任意簽名能力，每筆付款都受身份、來源、收款方、網路、資產、金額、時效和重試規則共同約束。缺少其中任何關鍵邊界，錢包就不應開放自動付款。

這份清單用於上線驗收。它不會承諾消除提示詞注入或模型錯誤，而是檢查：即使 Agent、遠端內容或某個工具給出惡意指令，支付系統能否限制損失、拒絕越權簽名、避免重複付款，並留下足夠證據供營運人員恢復。

AI Agent 錢包安全究竟指什麼

“Agent 有一個錢包”可能代表完全不同的架構：私鑰直接放在 Agent 程序裡；Agent 可以呼叫雲金鑰管理服務的通用簽名介面；或者 Agent 只能提交付款意圖，由獨立控制面和受限簽名器決定是否執行。

只有最後一種架構能夠建立清楚的安全邊界。

OWASP 對過度代理權的說明把風險歸因於功能過多、許可權過大或自主程度過高，並建議縮小工具能力、下游許可權以及高影響操作的自動執行範圍。NIST 的軟體與 AI Agent 身份和授權概念檔案也把 Agent 獨立身份、最小許可權、委託、人工授權以及可驗證審計列為關鍵問題。

因此，錢包安全不是金鑰存放位置這一個問題，而是從模型提出請求到鏈上結算的整條授權鏈能否保持最小許可權。

不可信輸入與 Agent 執行時
  │ 只能提交付款意圖；不能改策略、審批或簽名
  ▼
策略與預算控制面 ──需要例外──> 人工審批
  │ 簽發短時、單次、逐欄位繫結的執行授權
  ▼
客戶自持簽名器
  │ 校驗授權和準確付款載荷；不提供任意簽名
  ▼
x402 資源服務與鏈上結算
  │
  └──> 獨立記錄付款狀態、資源狀態和審計證據

如何給這份檢查清單評分

對每一項按證據評分：

• 0 分： 沒有控制措施，或只能口頭描述。
• 1 分： 已有部分控制，但依賴人工約定、單例項記憶體或無法重複驗證的操作。
• 2 分： 控制措施預設生效，測試能夠證明其拒絕失敗，並且審計記錄可以還原結果。

滿分為 24 分。分數只用於發現差距，不是安全認證：

第 1、2、8、9、10、12 項是一票否決項。即使總分很高，只要 Agent 能取得私鑰或通用簽名能力、執行授權可以重放、重試會建立付款，或者緊急停用未經驗證，就不應自動付款。

可以直接複製下面的表格填寫證據與得分：

1. 管理憑據、Agent 憑據與簽名憑據是否完全分離

日常執行的 Agent 只能持有屬於自身、環境和有限操作範圍的可撤銷憑據。建立錢包繫結、修改策略、提高預算、批准例外和檢視組織級資料，應使用另一套管理身份。錢包私鑰或雲金鑰管理許可權則只存在於簽名環境。

透過證據： 使用 Agent 憑據呼叫策略修改、預算修改、審批和錢包管理介面時全部被拒絕；撤銷該憑據後，已有程序也無法繼續建立付款意圖。

常見失敗： 所有 Agent 共用一個組織 API Key；把管理金鑰作為環境變數傳給模型工具；簽名伴隨服務與 Agent 使用同一組雲許可權。

2. 錢包私鑰是否離開 Agent 執行時，簽名器是否拒絕任意簽名

把金鑰放入硬體安全模組或雲金鑰管理服務，只解決金鑰材料不易匯出的問題。如果 Agent 仍能呼叫 sign(anything)，它擁有的實際資金許可權並沒有縮小。

簽名器應只接受付款專用載荷，並在簽名前驗證獨立控制面簽發的授權。測試金鑰檔案、正式環境金鑰、伴隨服務令牌和雲許可權都不能出現在提示詞、工具結果、日誌或錯誤回應中。

透過證據： 通用訊息、任意交易、錯誤錢包和錯誤網路均被簽名器拒絕；Agent 程序的檔案與雲身份許可權無法讀取或使用私鑰。

常見失敗： 生產環境仍使用明文私鑰檔案；伴隨服務監聽公網；只校驗呼叫者令牌，不校驗待簽欄位。

3. 每個 Agent 是否具有最小許可權和獨立歸屬

不同任務、環境和風險等級不應共用一個付款身份。研究 Agent、採購 Agent 和生產運維 Agent 應分別繫結需要的工具、錢包、策略和查詢範圍。沙盒憑據不得訪問正式環境，正式錢包也不應參與開發測試。

這項隔離讓團隊能夠單獨停用受影響的 Agent，並從審計記錄判斷“誰代表誰執行了什麼”。MCP 官方工具規範也要求用戶端把不可信伺服器提供的工具註釋視為不可信資訊；工具可見不應自動轉化為付款許可權。

透過證據： 任一 Agent 都無法查詢其它 Agent 的付款、呼叫未分配能力或跨環境使用憑據；許可權清單有負責人和複核日期。

4. 來源與收款方是否預設拒絕，並使用準確允許列表

只允許 https://example.com 還不夠。系統需要規範化並繫結準確來源，拒絕相似域名、非 HTTPS 降級、意外埠、重定向到其它來源以及使用者資訊混淆等情況。付款要求中的收款地址也必須獨立核對，不能因為來源在允許列表中就接受任意地址。

來源和收款方應分別形成四種結果：都已知時才可能自動付款；任一未知時進入審批或直接拒絕；兩者都未知時不應因為金額小而自動透過。

透過證據： 同形域名、開放重定向、來源不變但收款方變化，以及收款方不變但來源變化的測試都會失敗或進入審批。

5. 網路、資產和準確請求是否繫結到同一個付款意圖

地址相同不代表網路相同，同名代幣也不代表合約相同。系統必須校驗規範網路標識、資產合約或鑄幣地址、資產位數和收款地址。對於 POST、PUT、PATCH 或 DELETE，還要繫結 HTTP 方法、完整網址摘要、請求體摘要和內容型別。

如果預覽或審批後出現不同網路、資產、收款方、方法、請求體，或更高金額，它就是另一筆購買。舊審批不能繼續使用。

透過證據： 在簽名前分別替換每一個欄位，系統都拒絕執行；營運介面能顯示稽核所需欄位，但不洩露敏感請求正文。

6. 單筆上限與多級預算是否同時存在，並能抵抗併發

至少需要三層金額控制：不可由普通審批突破的單筆硬上限、每個 Agent 的週期預算，以及組織級週期預算。預算必須在簽名前原子預留或提交，不能等鏈上確認後才扣減。

否則，併發的十個請求可能同時讀到相同餘額，並分別透過判斷。金額還必須使用整數最小單位；不要用浮點數計算穩定幣限額，也不要假設所有代幣都有相同位數。

透過證據： 併發請求總額超過剩餘預算時，只有允許範圍內的請求成功；程序重啟和資料庫重試不會重複預留或釋放額度。

預算為何不能替代其它控制，可閱讀只設預算，不足以約束 AI 智慧體支付。

7. 自動付款閾值和人工審批是否表達不同風險

自動付款閾值應低於或等於單筆硬上限。已知來源、已知收款方且其它欄位全部符合策略的小額請求，可以在閾值內自動執行；未知物件或更高金額則等待人工審批；超過硬上限、預算不足或風險門禁失敗應直接拒絕，審批不能覆蓋。

審批必須針對一個不可變快照，而不是讓管理員授予“以後都可以”的模糊許可權。高金額可以要求多名不同管理員批准。操作人員需要看到購買內容、來源、收款方、網路、資產、最大金額和過期時間。

透過證據： 修改已審批快照的任一關鍵欄位都會使執行失敗；同一管理員不能重複計票；審批過期或被拒絕後不能恢復。

具體恢復方法見為什麼支付在等待審批，應該如何恢復？。

8. 執行授權是否短時、單次且逐欄位繫結

人工或策略決定不應直接變成長期簽名許可權。控制面應簽發短時執行授權，把組織、環境、Agent、Intent、錢包、網路、資產、收款方、最大金額、隨機數和有效期繫結在一起。簽名器逐欄位校驗後，只允許使用一次。

一份授權被截獲後，攻擊者不應能延長有效期、替換收款人、提高金額、用於另一個錢包，或在第二臺簽名器上再次消費。多副本簽名器需要共享、具備原子唯一約束的授權記錄，而不是各自維護記憶體集合。

透過證據： 重放相同授權、併發提交、過期授權、未知簽發金鑰和欄位不一致全部預設拒絕；金鑰發現或授權記錄儲存不可用時不降級為直接簽名。

9. 同一業務購買是否始終複用一個冪等身份

每次重試都生成新標識，會把一次購買變成多次合法付款。冪等鍵應在業務任務層生成，和原 Intent 一起持久儲存，並跨網路超時、程序重啟、佇列重投及人工審批恢復保持不變。

x402 的 payment-identifier 擴充套件允許伺服器端按付款標識去重並返回快取結果，但它是可選擴充套件，而且快取有效期由伺服器端設定。買方仍需在自己的控制面保證 Intent、預算和簽名授權不因重試而複製，不能把賣方去重當作唯一防線。

透過證據： 對同一個冪等鍵併發傳送相同請求時只產生一個 Intent 和一筆預算佔用；同一個鍵配不同請求內容時被拒絕，而不是複用錯誤結果。

10. 結算狀態未知時是否停止付款並對帳原 Intent

簽名後的超時不等於付款失敗。請求可能已經到達資源伺服器或結算服務，只是回應在返回途中丟失。此時應進入明確的 settlement_unknown 狀態，保留已經提交的預算，停止該業務購買的自動重付，並查詢原 Intent、授權和鏈上證據。

x402 的 HTTP 付款流程會把驗證、結算和資源回應連線到一次 HTTP 交換中，但具體付款方案的鏈上時點可能不同。安全恢復不能只看用戶端是否收到 2xx 回應。

透過證據： 在“簽名完成後、收到回應前”強制斷網，系統不會建立新 Intent 或釋放預算；恢復任務最終把原付款歸入已結算、已回滾、已過期或繼續未知。

完整操作見結算狀態未知時應該怎麼辦？。

11. 審計、告警與敏感資訊處理是否同時可用

一條有用的審計記錄應該能回答：哪個 Agent 和任務發起請求，使用哪版策略，誰批准，哪些欄位被繫結，由哪個簽名器和授權執行，鏈上交易及資源交付分別是什麼狀態。

記錄完整不等於複製秘密。日誌不應包含私鑰、完整 Agent Key、伴隨服務令牌、完整執行授權、付款簽名或敏感回應正文。使用穩定標識、欄位摘要和關聯編號即可重建決策鏈。

至少應對下列事件告警：連續策略拒絕、未知來源或收款方激增、審批異常、簽名重放、預算快速消耗、結算長期未知、Webhook 驗證失敗以及簽名器不可用。告警必須有負責人、處理時限和升級路徑。

透過證據： 從一條告警可以關聯到完整 Intent 和狀態遷移；刪除或修改審計記錄需要單獨許可權；日誌掃描確認沒有上述秘密。

12. 緊急停用與恢復演練是否真正阻斷新付款

團隊需要能夠分別撤銷 Agent Key、停用 Agent、解除錢包繫結、停用簽名器、撤銷管理金鑰和關閉正式環境付款。控制面故障、簽名器失聯或風險檢查不可用時應保持拒絕，而不是臨時繞過策略。

停用不一定能撤回已經提交到鏈上的付款，因此流程還要區分：阻止新意圖、阻止新授權、處理已經簽名但結果未知的付款，以及恢復仍未交付的業務資源。

透過證據： 演練從發現異常到阻斷新簽名的實際時間；停用後舊憑據、待審批 Intent 和未消費授權均不能繼續執行；結果未知的舊付款仍能進入只讀對帳流程。

哪些威脅應該由哪一層控制

單一措施無法處理所有失敗。下面的對映可用於檢查控制是否過度集中在模型提示詞或錢包餘額上。

這也是為什麼提示詞防護不是付款安全邊界。NIST 對 Agent 劫持的研究指出，攻擊者可以把惡意指令藏在 Agent 讀取的網頁、檔案或訊息中。系統應該減少這類攻擊成功的機會，但資金控制還必須假設惡意指令有時會到達工具層，並在模型之外獨立拒絕越權操作。

上線前應該怎樣做故障演練

不要只演示一筆成功付款。至少在沙盒中自動執行下面的拒絕與恢復測試：

1. 使用 Agent Key 修改自己的策略、預算和錢包繫結，確認全部被拒絕。
2. 分別替換來源、收款方、網路、資產、HTTP 方法、請求體和金額，確認舊審批或授權失效。
3. 對同一個冪等鍵發起併發請求，確認只建立一筆購買。
4. 在簽名後、資源回應前中斷連線，確認進入結算未知而不是建立付款。
5. 重啟 Agent、控制面用戶端和簽名器，再恢復同一個 Intent，確認不會重複簽名。
6. 重放已經消費的執行授權，確認所有簽名器例項都拒絕。
7. 快速耗盡 Agent 預算並同時保留組織預算，確認 Agent 級限制獨立生效。
8. 撤銷 Agent Key、停用 Agent 和解除錢包繫結，測量新付款被阻斷的時間。
9. 讓簽名器、風險檢查或審計儲存不可用，確認系統保持拒絕且產生告警。
10. 從告警、Intent、審批、授權、交易和資源狀態重建一次完整事件，確認日誌沒有洩露秘密。

透過測試後，先在正式環境完成一筆金額很小、必須人工審批、結果容易核對且沒有不可逆業務副作用的付款。只有當付款證據、資源結果、錢包餘額、預算和審計記錄全部一致時，才逐步提高自動付款閾值。

StableOps 如何對應這 12 項檢查

StableOps Agent Payments 把營運者使用的管理 API Key、執行時使用的受限 Agent Key，以及客戶環境中的簽名憑據分開。不可變策略繫結來源、收款方、網路、資產與限額，兩級預算限制 Agent 和組織總量；未知物件或超過自動閾值的付款進入審批。

執行時，StableOps 簽發短時、單次且逐欄位繫結的授權，由客戶自行部署的簽名器驗證，並使用本地測試金鑰、AWS KMS 或本地 Solana 金鑰完成付款專用簽名。私鑰不交給 StableOps 或 Agent。審批後恢復原 Intent，簽名後結果不確定則進入對帳，不用新付款替代。

這不意味著接入某個產品就自動透過檢查。團隊仍要正確隔離部署環境、保管管理憑據、限制伴隨服務、設定明確策略、接收告警，並實際完成停用與結算未知演練。可從 Agent Payments 快速開始建立沙盒流程，再按簽名器部署檢查核對金鑰邊界。

常見問題

AI Agent 錢包本身安全嗎？

錢包軟體或金鑰託管方式只能覆蓋一部分風險。決定生產安全性的是 Agent 能否取得任意簽名能力，以及每筆付款是否經過獨立、可驗證、可撤銷的授權鏈。直接把私鑰交給 Agent 不安全。

只給錢包放很少的錢，可以代替這些控制嗎？

不可以。小余額能夠限制某一時刻的最大損失，但不能防止付錯物件、重複付款、洩露金鑰或錯誤交付業務資源。它可以作為額外的資金隔離措施，不能替代許可權和恢復控制。

私鑰放在 AWS KMS 中就足夠安全嗎？

不夠。還要限制誰能呼叫 KMS、能夠簽署什麼、授權有效多久、是否只能使用一次，以及請求欄位變化時是否拒絕。對 Agent 開放通用 KMS 簽名許可權仍然屬於過大許可權。

每一筆 Agent 付款都需要人工審批嗎？

不一定。已知來源和收款方、低於自動閾值且完全符合策略的付款可以自動執行。未知目標、更高金額或高影響操作應審批，硬限制或風險檢查失敗則應直接拒絕。

這些控制能徹底解決提示詞注入嗎？

不能。它們的目標是在提示詞注入、模型錯誤或工具被入侵後，仍限制資金能力和可恢復範圍。輸入隔離、內容檢測和工具安全仍需單獨建設。

付款請求超時後可以用新冪等鍵重試嗎？

簽名前且能夠證明沒有生成授權時，可以按原業務狀態恢復。簽名後超時必須查詢原 Intent，不能用新冪等鍵發起替代付款，否則可能重複扣款。

x402 是否保證收費服務值得信任？

不保證。x402 標準化付款要求、驗證和結算流程，不替買方判斷服務品質、來源信譽、收款方歸屬或業務結果。發現服務後仍應執行允許列表、審批和結果驗證。

多久應該重新執行一次檢查清單？

至少在首次上線、提高自動閾值、增加網路或資產、更換籤名器、修改身份架構、發生安全事件以及重要依賴升級後重新執行。日常還應定期複核許可權、允許列表、告警負責人和停用時效。

從零自動付款開始

初始自動付款閾值設為零並不是失敗，而是一種校準方法。它讓團隊先驗證審批、簽名、結算和審計，再把一條經過證明的路徑改為自動執行。

先完成 12 項書面評分和十個故障測試，再從一個 Agent、一個專用錢包、一個來源、一個收款方、一種資產和一條網路開始。安全地擴大自主程度，依靠的是擴大可驗證的安全路徑，而不是擴大模型持有的許可權。

本文資料與協議連結核驗於 2026 年 9 月 15 日。