Ishween Kaur：如何保护智能体的 x402 支付

我是 Ishween Kaur，从事 AI 评估和自主系统方面的工作。我对智能体支付产生兴趣，并在受控环境中通过攻击测试探索了 x402。想象一下：你可以不订阅服务，只为一部电影付费；或者智能体为一个市场数据点支付几美分。付款前，它应检查卖家、预算以及这次购买是否获得授权。

HTTP 很早就为“需要付款”保留了 402 状态码。x402 在请求流程中提供了一种让软件处理付款的方法。我介绍了四方：买方智能体、卖家、facilitator 和区块链。卖家返回付款要求，买方签名，facilitator 验证请求并可以结算付款。

对于金额很小、普通交易手续费可能超过商品价格的付款，链上支付具有吸引力。但小额支出也会累积：每次 10 美分，调用 1 万次就是 1000 美元。智能体即使没有损坏，也可能造成损失。因此我测试了 20 种干扰流程的方法，这里重点介绍其中六种。

第一个问题是价格变化。目录可能将服务标价为 5 美分，卖家在 402 付款要求中却要 50 美分。在没有防护的测试中，买方签署并结算了更高的金额。比较预期金额和实际要求的防护措施阻止了这次运行。

只检查价格并不能覆盖所有替换情况。钱包地址或网络也可能变化，原因既可能是攻击，也可能是合法轮换。买方需要一起检查相关字段，确保在预期网络上向预期卖家支付正确金额。

第二个问题是重复使用一次付款。我的例子中，卖家收到同一授权的五个副本。结算前，验证可能认为每一份都有效；最终只有一笔付款结算，但卖家可能已经交付了五次。验证和结算两个阶段的后果不同。

我建议在共享存储中记录支付标识及其进行中或已完成状态，让重复请求返回已保存的结果，而不是再次触发交付。当响应包含昂贵或保密的数据，或者会激活许可时，这一点尤其重要。买方重试也有类似风险：每次超时都创建新的付款标识，可能为同一个结果支付多次。

第三个问题是没有成功结算就交付。验证可能通过，但之后结算失败，例如买方资金不足。对昂贵、保密或需要新生成的数据，等待结算后再交付可以降低风险，但会增加延迟。对于低价值数据，企业可能作出不同选择。

免费访问也可能源于普通应用设计。如果一个接口用付费墙保护报告，另一个接口却不受保护，买方可以访问后者。应测试所有预期需要付费的接口，确认它们都会返回付款要求。

缓存提供了另一条路径。如果共享缓存将付费响应保存在公开 URL，之后的请求就可能绕过付费墙取得内容。应把缓存数据放在卖家的付款检查之后；适当情况下，敏感或昂贵的响应不应缓存。缓存配置也必须遵守预期的 no-store 策略。

第四个问题是跨资源重放。如果两个受保护页面分别维护付款记录，它们可能各自接受同一笔付款。共享状态可以把付款标识绑定到已经交付的资源，并拒绝相冲突的请求，而不是将每个页面当成独立购买。

第五个问题是恶意发现。目录可能显示某项服务可用，却没有确认谁控制域名和钱包。冒充卖家可以使用熟悉的名称和更低的价格；只按价格选择的智能体可能把钱付给错误的一方。

谨慎的企业可以只允许向已批准卖家购买。对于需要发现新卖家的工作流，我建议设置批准、阻止和观察名单，对观察名单进行人工审查并设定限制。合法卖家也会更换域名、钱包、网络和价格，因此批准名单需要持续维护。

第六个问题是卖家回复中的提示注入。回复可能暗示其他位置有更完整的版本，却没有直接命令购买。在我的 Base Sepolia 测试中，使用 Llama 3.2 的智能体获取并购买了高级摘要：原本 5 美分的请求总共花了 55 美分。

简单关键词过滤可能漏掉隐晦的提示，基于模型的判断器也可能漏掉攻击。在这个具体工作流中，我知道买方只应调用一次，因此将执行计划限制为一次调用。智能体仍决定获取额外摘要，但测试中的防护措施阻止了第二笔付款。

这些案例有一个共同点：付款看起来可能有效，结果却是错误的。买方签名前和卖家交付前都需要检查。追踪记录应显示买方意图、卖家回复、调用的服务和交易结果。

上线时，我先使用一个付款标识，端到端记录整个流程。在影子测试阶段，我建议收集大约 20 至 25 个成功和失败案例，分析错误，确定哪里需要告警、阻断或其他防护。

随后执行选定的控制措施，并逐条轨迹重复测试。结果可以帮助判断控制是否过于严格、过于宽松，或需要根据实际业务流程调整。智能体可以付款，但更重要的问题是何时应允许它付款。