XRP Ledger 的 AI 支付工具讓人類保持掌控權
重點速覽
- •XRPL 的開發者指引將交易準備與授權分開,在任何付款簽署前,預覽會顯示完整的收款人、金額、網路與費用。
- •自動簽署僅能在由交易類型、網路與到期時間定義的明確且具時效性的範圍內進行,且單筆付款上限並不限制累積總支出。
- •該指引將收到的交易備忘與文件內容視為不可信任的輸入,因此發票無法僅憑提出請求就授權付款,以因應提示詞注入。
- •範圍限定且可撤銷的 Open Wallet Standard 代理權杖會在簽署前觸發政策檢查,而擁有者的保管庫通關密語則提供不受檢查約束的完整存取權,使憑證選擇具有決定性。
- •由於已簽署的 XRPL 交易無逆轉,且該指引設定的是模式而非協定要求,有效的執行取決於實作測試以及實際代理錢包的採用。

當 AI 助理被要求支付供應商的發票時,讀取金額並準備轉帳可以省下大量工作——但只要收款人出一次錯,這種便利就會變成財務損失。因此支付流程需要一個檢查點,在資金實際移動之前驗證擬議的轉帳。支付是代理式 AI 中風險最集中的環節:助理可以重寫一封寫得不好的電子郵件,但已簽署的轉帳通常無法撤銷。
XRP Ledger(XRPL)的文件說明瞭開發者如何將這種審核機制建構到代理的工作流程中。該指引涵蓋的是開發者工具而非協定本身:它並未在 XRP Ledger 中導入普遍性的人工核准要求。其中貫穿三項原則——文件所述的工作流程要求在簽署前取得核准、自動簽署需要明確且具時效性的授權,而簽署憑證的類型決定錢包政策是否適用。
準備先於授權
XRPL Payments skill 為代理提供建構交易所需的知識,包括 XRP 及 RLUSD(一種美元穩定幣)轉帳。它會將擬議的交易交給獨立的 wallet skill 進行簽署與提交,這意味著準備發票付款與授權付款是兩個不同的步驟。
較早的一篇關於 XRPL 支援以 XRP 和 RLUSD 進行 AI 支付的報導探討了代理如何為務付費。而錢包指引則說明,當這些功能接觸到使用者的資金時,使用者需要檢查哪些事項。
在供應商的情境中,這意味著審核助理實際準備的轉帳。文件所述的支付流程演示會在確認前顯示預覽,包含完整的收款人地址、金額、網路與費用。一張要求 10 XRP 的發票,應產生一筆發往預期地址、金額相符、位於預定網路上的轉帳。
完整顯示地址使比對成為可能,但無法證明該地址由誰控制。使用者仍需要供應商付款資訊的可信記錄——特別是當發票宣布地址已變更時。
核准後,錢包簽署並提交交易,然後檢查結果。僅提交並不保證供應商已收到款項:有些交易會進入已驗證的帳本並產生費用,即使其預期動作失敗。保留交易雜湊值並驗證結果,有助於避免僅因助理未立即回報成功就再發送第二筆付款。
定期付款需要更窄的授權範圍
逐一核准多筆小額付款可能變得繁瑣。因此該指引允許人類在明確的範圍內啟用自動簽署,代理會複述該範圍以供確認。
每一項此類授權都必須指定交易類型、網路與到期時間。核准的收款地址與金額上限可以進一步限制授權。在一個假設的定期安排中,擁有者可允許在接下來一小時內,向某個已驗證的供應商地址在指定網路上支付每筆最多 10 XRP。
這個例子也揭露了一個在委派前值得檢查的限制:單筆付款上限並不等於總預算。十二筆 10 XRP 的付款將花費 120 XRP,而每筆轉帳都仍在個別限額之內。預期總支出僅 10 XRP 的企業,需要針對累積支出或交易筆數增加額外的控制。
文件所述的覆寫授權在其範圍到期時終止,任何超出範圍的請求都會回到人工確認。因此,自動化可以涵蓋已核准的任務,而不會讓助理自行擴充其權限。
發票無法自行授予權限
即使是範圍正確的任務,也可能使代理接觸到惡意內容。例如,供應商的發票可能包含指示,要助理忽略擁有者的規則並將資金匯往其他地方。這就是提示詞注入(prompt injection),一種已被廣泛記錄的 AI 系統失敗模式:外部材料企圖轉變為指令。
錢包指引明確將收到的交易備忘為不可信任的輸入,並要求在它們能影響簽署之前進行全新的審核。同樣的區別也解釋了為何處理中的文件不應能僅憑提出請求就授權付款。
在發票工作流程中,金額與付款參考是待審查的資訊。授權必須來自擁有者的核准,或來自其限制仍然有效的既有權限。目的地變更時需要驗證,即使文件聽起來令人信服。
簽署設定必須強制執行這些限制
能否可靠地應用這種區別,也取決於代理如何取得簽署金鑰。XRPL 支援用於本地開發與低價值帳戶的環境變數 seed、將金鑰保留在代理程序之外的外部簽署器,以及具政策控制存取的 Open Wallet Standard(OWS)保管庫。
OWS 憑證的選擇尤其關鍵。範圍限定且可撤銷的代理權杖會在簽署前觸發政策檢查;而擁有者的保管庫通關密語則提供完整存取權且不受這些檢查約束。將該通關密語交給代理,將會破壞擁有者原本想要施加的限制。
因此,要求助理遵守預算的書面指示需要的不僅是助理的同意——簽署機制本身必須拒絕未經授權的請求。正如 XRPL 的金鑰文件所解釋,簽章授權交易,且沒有任何特權管理員可以在交易生效後將其逆轉。
就供應商付款的情境而言,一項有用的實作測試是刻意提出錯誤的收款人、超出允許的金額,並在權限到期後嘗試付款。拒絕這些轉帳,將比成功處理一張正確的發票更能有力地證明控制措施的有效性。
這正是使用者在選擇 AI 支付服務時應該尋找的:委派前有明確的審核、簽署時強制執行限制,以及結果的可靠記錄。開發者指引提供建構這些防護措施的框架;其最終效果取決於應用程式的實作。由於該指引建立的是模式而非協定層級的要求,「簽署前審核」與「限定範圍的委派」是否成為實際代理錢包的預設標準,是值得關注的發展。
本文僅供資訊參考,不構成財務或投資建議。開發者工具及其文件所述行為可能會變更。