新闻加密货币XRP Ledger 的 AI 支付工具让人类保持控制权

XRP Ledger 的 AI 支付工具让人类保持控制权

作者: Coindoo·

要点速览

  • •XRPL 的开发者指南将交易准备与授权分离,在任何支付被签名之前,预览会显示完整的收款人、金额、网络和费用。
  • •自动签名仅允许在由交易类型、网络和有效期定义的明确且临时的范围内进行,且单笔支付上限并不限制累计总支出。
  • •该指南将传入的交易备忘录和文档内容视为不可信输入,因此发票不能仅凭提出请求就授权支付,以此防范提示注入。
  • •范围受限、可撤销的 Open Wallet Standard 代理令牌会在签名前触发策略检查,而所有者的金库密码短语则提供不经过这些检查的完全访问权限,凭证选择因此至关重要。
  • •由于已签名的 XRPL 交易无法撤销,且该指南确立的是模式而非协议要求,有效的执行取决于实现测试以及实际发布的代理钱包的采用。
XRP Ledger 的 AI 支付工具让人类保持控制权

被要求支付供应商发票的 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 支持用于本地开发和低价值账户的环境变量种子、将密钥保留在代理进程之外的外部签名器,以及具有策略控制访问的 Open Wallet Standard(OWS)金库。

OWS 凭证的选择尤为关键。范围受限、可撤销的代理令牌会在签名前触发策略检查;而所有者的金库密码短语则提供完全访问权限,不经过这些检查。将密码短语交给代理,会破坏所有者原本打算施加的限制。

因此,一份要求控制在预算之内的书面指令,仅有助手的同意是不够的——签名机制本身必须拒绝未获授权的请求。正如 XRPL 的密钥文档所解释的,签名授权交易,而且没有任何特权管理员可以在签名生效后将其撤销。

对于供应商付款场景,一个有用的实现测试是故意提出错误的收款人、超出允许金额,并在授权过期后尝试付款。拒绝这些转账,比成功处理一张正确的发票更能有力地证明控制措施的有效性。

这正是用户在 AI 支付服务中应当寻找的:委托前有清晰的审查、签名时实施限制、以及对结果的可靠记录。开发者指南为构建这些防护提供了框架;其最终效果取决于应用的实现。由于该指南确立的是模式而非协议层要求,签名前审查和范围受限的委托是否会成为实际发布的代理钱包的默认设置,是值得关注的进展。

本文仅供参考,不构成财务或投资建议。开发者工具及其文档描述的行为可能发生变化。