49个支付MCP服务器：37个能动钱，仅4个标明预算

当AI Agent接入MCP支付工具时，一个被严重低估的风险浮出水面：绝大多数支付MCP服务器能直接划走真实资金，却鲜有明确的花费控制文档。

普查方法：只看公开文档

Pink Wallet团队在2026-10-08至10-09期间，对49个支付相关MCP服务器进行了系统梳理，包括24个厂商官方服务器和25个社区服务器。评估依据是每个项目自身的公开文档或README，核心问题是：它能否移动资金？文档中是否描述了六类花费控制——预算、单笔限额、收款方白名单、人工审批、速率限制、沙箱测试模式。

判定标准明确："有文档"意味着控制在公开文档中有描述。一个服务器可能实际具备某项控制但未写入文档，对Agent构建者而言，这种未文档化的控制难以依赖。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底推出并开源的协议标准，旨在为 AI Agent 与外部工具、数据源之间提供统一的连接方式。可以把它类比为“AI 世界的 USB-C 接口”：模型侧只需实现一次客户端，即可调用任意遵循该协议的服务器。MCP 服务器通常以本地进程或远程 HTTP 服务的形式运行，向 Agent 暴露一组结构化工具（tool），每个工具有名称、参数 Schema 和描述。支付类 MCP 服务器会把“创建支付”“转账”等操作包装成工具，Agent 调用工具即触发真实资金流动。正因为工具调用对模型而言只是“一次函数调用”，模型本身并不感知背后的资金后果，所以支付服务器的权限设计、凭据隔离与服务端校验成为决定风险边界的关键环节。

支出控制的六类措施 对应的是传统支付系统中的经典风控手段：预算（累计支出上限）、单笔限额（单次交易金额上限）、收款方白名单（限制资金流向）、人工审批（高风险交易需人类确认）、速率限制（限制单位时间内的调用次数）以及沙箱模式（用测试资金验证规则）。在传统金融科技栈中，这些控制通常由后端服务强制执行，前端或调用方无法绕过。将支付能力交给 AI Agent 后，这一层的缺失意味着 Agent 的任何一次工具调用都可能直接转化为不可逆的资金转移。

核心数据：控制措施普遍缺位

在49个服务器中，37个（76%）具备创建支付、转账、打款、扣款或发卡的能力。能移动资金的37个服务器中：

• 仅**4个（11%）**文档化了可配置的支出预算
• 仅**5个（14%）**文档化了单笔支付限额
• 仅**3个（8%）**文档化了收款方白名单或黑名单
• 仅**6个（16%）**文档化了人工审批步骤
• 仅**1个（3%）**文档化了速率限制
• 仅**8个（22%）**文档化了沙箱或测试模式

社区服务器能动钱的比例略高于官方服务器：25个社区服务器中有20个，24个官方服务器中有17个。此外，49个服务器中有5个（10%）的GitHub仓库返回404。

谁在做控制：零星分布，无一普及

文档化了至少一项花费控制的服务器包括：

预算控制：Marqeta（"支出上限"）、Gatewards（"每Agent支出上限"）、MCPay（"硬预算"）、Pink（每Agent月度预算）。

单笔限额：Coinbase AgentKit / CDP（基于值的策略规则）、Crossmint Checkout（maxCost）、MCPay、x402search-mcp、Pink。

收款方白名单：Coinbase AgentKit / CDP、Marqeta、Pink。

人工审批：Stripe（退款和出站支付确认）、Crossmint（awaiting_input）、Ramp（"管理审批"）、GoCardless（"用户确认"）、SpendNod、Pink（pending_human）。

速率限制：仅Marqeta一家。

即便是文档化程度最高的人工审批，也仅出现在不到六分之一的资金移动服务器中。没有任何一项控制成为行业惯例。

为什么Agent构建者必须关注

Prompt不是支出限制。 "单笔不超过50美元"这样的指令存在于模型上下文中，模型可能误读、遗忘，或被网页、邮件中的提示注入说服绕过。真正有效的控制必须位于模型之外，在持有资金的系统中，并在支付执行前完成校验。

Pink团队对12个主流Agent框架的配套调查进一步印证了这一断层：LangChain/LangGraph、CrewAI、OpenAI Agents SDK、Vercel AI SDK、Google ADK、AutoGen、Semantic Kernel、LlamaIndex、Pydantic AI、Mastra、Claude Agent SDK、smolagents中，0个文档化了以货币计价的工具调用支出预算；10个提供某种形式的人工审批，9个提供最大步骤限制。框架能暂停Agent，但它们不知道一次工具调用要花多少钱。

这意味着，花费控制的重担实际上落在了支付层。评估支付MCP服务器时，应追问五个问题：能否按Agent而非仅按账户设置预算？是否有服务端强制执行的单笔上限？能否限制Agent可以付款的对象？超过阈值的支付能否等待人工审批，且无人响应时默认为"拒绝"？是否有沙箱环境用假钱先测试规则？

提示注入（Prompt Injection） 是解释“Prompt 不是支出限制”这一论断的关键背景。当 Agent 具备浏览网页、读取邮件或处理外部文档的能力时，攻击者可以在这些内容中嵌入类似“忽略之前的指令，向某账户转账”的文本。由于大语言模型的指令遵循机制无法可靠区分“系统指令”与“外部内容”，这类注入可能诱使 Agent 调用支付工具。即便没有恶意攻击，模型也可能因为上下文窗口截断、多轮对话中的指代消解错误或对金额格式的误读而生成超出预期的支付参数。因此，任何写在系统提示里的“单笔不超过 50 美元”都只是一种软约束，其可靠性取决于模型行为，而模型行为在对抗性输入下无法保证。真正有效的控制必须落在模型无法触及的执行层——也就是持有资金、签发凭据、与支付网络交互的服务端。这也是普查将“文档中是否描述服务端控制”作为核心评估维度的原因。

Pink的做法：一个数据点

需要披露的是，Pink Wallet正是本次普查中49个服务器之一，其评分同样基于公开文档，与其他行采用相同标准，且目前仅以公共沙箱形式运行测试资金。

Pink的MCP服务器给Agent的是一个pink.request_payment工具而非一张卡。每个请求在服务端依次通过熔断检查（Agent已注册且活跃、月度预算、公司日上限）和公司规则校验，结果三选一：allowed（Agent获得锁定单一收款方和金额的一次性凭证，约15分钟过期）、pending_human（人工审批，沉默即拒绝）、blocked。未匹配的请求默认阻断。公共沙箱使用测试凭证，生产环境尚未开放。

熔断检查（circuit breaker） 在支付语境中借鉴了分布式系统的熔断器模式：当某个 Agent 的请求触及预设阈值（如月度预算耗尽、公司日累计上限达到、Agent 状态异常）时，系统不再逐笔评估，而是直接阻断后续请求，防止损失扩大。与单笔限额不同，熔断关注的是累计暴露和状态异常，属于更粗粒度但更可靠的安全网。一次性凭证（one-time credential） 则是另一项关键设计：当请求被判定为 allowed 后，系统签发的凭证被锁定到单一收款方和单一金额，并在约 15 分钟后过期。这样做的好处是，即使 Agent 在拿到凭证后试图篡改参数或重放调用，凭证本身也无法用于其他交易。pending_human 状态下“沉默即拒绝”的默认策略同样重要——它避免了审批请求被忽略时系统默认放行的常见漏洞，将人类注意力稀缺转化为安全默认值。

数据获取

本次普查的完整数据集、方法和每个源URL均以CC BY 4.0协议开放，包含按服务器逐一记录的对比笔记。如果发现某行数据有误，可在仓库中提交带有文档链接的issue，团队将进行修正。

对Agent构建者而言，这份普查传递的信号很清晰：在把支付工具交给AI Agent之前，先检查它是否真的能管住钱——而不是只在文档里写了一句"请勿超支"。