x402 SDK默认无支出上限：恶意API可掏空AI代理代币余额

当AI代理开始自主为API调用付费，支付权限就成了一把双刃剑。安全公司V12披露的x402支付SDK漏洞，给所有部署具备支付能力代理的团队敲响了警钟：默认不设支出上限，等于把代理的全部代币余额交给任何它能调用的端点。

漏洞核心：默认开放的支付授权

据V12披露，x402支付SDK在发布时没有设置任何默认支出限制。这意味着，任何使用该SDK为API调用付费的AI代理，都可能被恶意端点诱导，在单笔交易中授权其全部代币余额。代理会乖乖签名——因为它被设计为信任调用方，而SDK没有给它设下任何天花板。

问题不在于某个具体的攻击手法，而在于设计范式：一个拥有支付权限的AI代理，本质上就是一件金融工具。当这件工具缺少支出上限，它就不再是理论风险，而是任何被调用API都能利用的现成攻击面。

修复在8月落地，但在那之前部署的所有代理，都曾在没有任何交易对手请求上限的环境中运行。换句话说，漏洞窗口期覆盖了SDK发布到修复之间的全部时间，期间上线的代理都暴露在风险中。

x402 协议是围绕 HTTP 402「Payment Required」状态码构建的开放支付标准，旨在让客户端（包括 AI 代理）在访问付费 API 时自动完成链上或链下结算。其典型流程是：服务端返回 402 与支付要求，客户端 SDK 构造并签名支付授权，服务端验证后放行请求。正因为签名动作由 SDK 自动完成、无需人工介入，SDK 的默认参数直接决定了代理实际可动用的资金上限；一旦默认值缺失，协议层面的便利性就会转化为资金风险。

为什么默认值如此致命

安全领域有一条老规矩：默认配置决定实际安全水位。x402 SDK的问题恰恰出在默认值上——没有上限，就是无限授权。对于人类用户，支付前通常会有确认步骤；但对于自主运行的AI代理，签名往往是自动完成的。恶意端点只需要构造一个看似合理的API调用请求，就能让代理签下远超预期的支付授权。

这里的关键认知是：代理的支付权限等同于金融工具，而金融工具必须有风控边界。缺少支出上限不是一个小疏忽，它把每一个API调用都变成了潜在的钓鱼入口。V12的披露把一个抽象的设计原则具象化了：默认开放的设计模式，在代理经济中会直接转化为资金损失风险。

提示注入（Prompt Injection） 是攻击者通过 API 响应、网页内容或工具返回值，将恶意指令嵌入代理上下文，从而劫持其决策的技术。在代理支付场景中，它与支付授权形成叠加风险：攻击者无需攻破代理本身，只需让代理「认为」某笔支付是任务所需，即可诱导其自动签名。这使得支出上限不能仅依赖代理的判断逻辑，而必须由代理无法篡改的外部机制强制执行，否则任何可被读取的内容都可能成为操纵支付的入口。

社区讨论：支出授权该在哪一层解决

围绕这个漏洞，开发者社区提出了一个更根本的问题：在代理系统中，支出授权到底应该在哪一层实现？

• SDK层：在支付SDK内部设置默认上限、单笔限额和累计限额，让安全成为默认行为。
• 基础设施层：通过钱包、托管服务或支付网关施加策略控制，代理无法绕过。
• 代理编排层：在代理的决策逻辑中加入预算检查和人工审批环节。

目前没有统一答案。有团队倾向于在SDK层做默认限制，因为这是最接近支付动作的位置；也有团队认为基础设施层的策略引擎更可靠，因为代理本身可能被提示注入操纵，不能信任其自身逻辑。生产环境中真正有效的组合，往往是多层防护：SDK默认限额兜底，基础设施策略做硬约束，编排层负责异常上报。

代理编排层指负责规划任务、调用工具、管理状态与预算的运行时框架（如各类 Agent 框架与工作流引擎）。在这一层做预算检查的优势是能结合任务上下文判断支付合理性，并可插入人工审批；局限在于编排逻辑本身运行在代理侧，若代理被提示注入操纵，检查可能被绕过或被说服放行。因此它更适合作为异常检测与上报的第一道软性防线，而非最终的资金硬约束。

对代理经济的启示

x402漏洞暴露的不只是一个SDK的实现问题，而是整个代理支付生态的成熟度缺口。当AI代理被赋予经济行为能力，安全设计必须从“默认开放”转向“默认受限”。

对正在构建代理支付系统的团队来说，有几条可直接落地的原则：为每笔交易设置硬上限，为每个时间窗口设置累计限额，对异常支付模式触发告警或阻断，以及把支付授权视为需要审计的高危操作。代理可以自主，但自主不等于无界。

V12的披露留下了一个开放问题：你的代理在签名之前，有没有人替它踩过刹车？