XRP账本的AI支付工具确保人类保持控制

区块链文库报道：

核心要点

记录在案的工作流需在签署前获得批准。自动签署需要明确且临时的授权。签署凭据决定了钱包策略是否适用。

助理在处理付款前的审查机制

考虑这样一个场景：一位助理被要求支付供应商的发票。阅读金额并准备转账可以节省工作量，但如果收件人地址错误，这种便利就会转化为财务损失。因此，资金转移之前必须有一个检查拟议转账的步骤。

XRP Ledger（XRPL）的文档描述了开发人员如何将这种审查机制构建到智能体（Agent）的工作流中。这些是针对开发者工具的说明；它们并未在 XRP Ledger 协议层面引入普遍的人类审批要求。

在钱包签署之前，助理会准备好付款。XRPL Payments Skill 赋予智能体构建交易所需的知识，包括 XRP 和 RLUSD 的转账。它将拟议的交易交给单独的钱包技能进行签署和提交，因此准备发票付款与授权它是两个独立的步骤。

我们此前关于 XRPL 支持 AI 以 XRP 和 RLUSD 进行支付 的报道探讨了智能体如何为服务付费。而 wallet 指南 则解决了当这些能力触及用户资金时，用户需要检查的事项。

在供应商示例中，这意味着审查助理实际准备的转账。文档化的支付演练 显示，在确认之前，预览窗口包含完整的收件人地址、金额、网络和费用。一张要求 10 XRP 的发票应产生向预期地址转账该金额的指令，且在预期的网络上执行。

完整显示地址使得比对成为可能，但这并不能确立地址的所有权。用户仍然需要一份值得信赖的供应商付款详情记录，特别是如果发票通知了地址变更的情况。

重复性付款需要更严格的权限范围

如果助理处理许多小额付款，每次手动批准可能会变得繁琐。指南允许人类用户在明确的范围内激活自动签署，智能体会复述该范围以供确认。

每项授权都必须指定交易类型、网络和过期时间。批准的目的地和金额上限可以进一步限制权限。对于一个假设的重复性任务，所有者可以允许在接下来的一小时内，向一个经过验证的供应商地址支付高达 10 XRP 的金额，且限于指定的网络。

该示例也暴露了一个在委托前值得检查的局限性：单笔付款上限并不设定总预算。十二笔每笔 10 XRP 的付款将花费 120 XRP，尽管每笔都在其个人限额内。如果企业预计总支出仅为 10 XRP，则需要对累计支出或交易数量进行额外的控制。

文档化的覆盖权限在其范围过期时结束，超出范围的请求将返回人工确认。因此，自动化可以覆盖已批准的任务，而不允许助理扩展其自身的权限。

发票不能自行授予权限

即使是范围正确的任务，也可能使智能体暴露于恶意内容中。例如，供应商的发票可能包含指示助理忽略其主人规则并将钱发送到其他地方的指令。这就是提示注入（Prompt Injection）：外部材料试图成为指令。

wallet 指南 特别将传入的交易备忘录视为不可信输入，并要求在它们影响签署之前进行新的审查。同样的区别解释了为什么正在处理的文档不应仅仅通过请求就授权付款。

对于发票工作流，金额和付款参考是待检查的信息。权威必须来自所有者的批准或现有权限，且其限制仍然适用。即使文件听起来很有说服力，变更的目的地也需要验证。

签署配置必须支持这些限制

可靠地应用这种区分还取决于智能体如何访问签名密钥。XRPL 支持用于本地开发和低价值账户的环境变量种子、将密钥保留在智能体进程之外的外部签名者，以及具有策略控制访问权限的 Open Wallet Standard (OWS) 金库。

OWS 凭据的选择尤为关键。作用域化、可撤销的智能体令牌会在签署前触发策略检查；而所有者的金库密码短语提供完全访问权限，无需这些检查。给予智能体该密码短语将破坏所有者意图应用的限制。

因此，书面指令要保持在预算内，不仅仅需要助理的配合。签署安排必须拒绝未经授权的请求。正如 XRPL 的 密钥文档 所解释的那样，签名授权交易，并且没有特权管理员可以在交易生效后逆转它们。

对于供应商付款示例，有用的实现测试是故意提议错误的收件人、超出允许的金额，并在权限过期后尝试付款。拒绝这些转账将为有效控制提供更有力的证据，这比成功处理正确的发票更具说服力。

这就是用户在 AI 支付服务中应该寻找的内容：委托前清晰的审查、签署时应用的限制，以及可靠的结果记录。开发者指南提供了构建这些安全措施的框架；其有效性取决于应用程序的实现。

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