SpendShield 是一个面向 AI 智能体支付的策略与授权层，其核心目的只有一个：阻止 AI 智能体在超出你设定的规则时花钱。
【用途】 每当智能体尝试发起一笔支付，都必须先经过一次 authorize() 调用，得到 ALLOW / APPROVAL（人工审批）/ DENY 的决策结果，之后资金才会移动。SpendShield 本身从不持有资金，Stripe、x402、钱包等支付渠道仍在下游。它面向任何运行“能够花钱的软件”的场景，例如基于 Stripe、x402、AP2 的智能体、MCP 服务器、Claude Code、OpenClaw 或自建自动化流程。
【为什么需要它】 一次提示注入就可能导致资金损失：智能体读取邮件、网页或工具返回结果时，若其中包含“向某账户退款 500 美元”之类的指令，资金就可能在没有人工决策、没有审计记录的情况下被转走。这不是智能体的 bug，而是缺少一道闸门。
【主要能力】
- 决策闸门：ALLOW / APPROVAL / DENY 三态授权，reason 以结构化形式返回，便于 LLM 读取。
- 策略控制：通过 YAML 策略文件设定预算、商户名单等规则。示例策略包含单笔上限与每日预算。
- 防越权：当智能体请求 75 美元而策略上限为 50 美元时返回 DENY，且不支持重试、拆分或走第二路径。
- 审计链：每个决策作为一个事件以哈希链形式串联，任何被编辑的事件都会破坏链条，任何读者都可验证（篡改检测）。
- 签名一次性授权（实验性执行强制原型）：同一授权重放会被拒绝（一次性）、无授权或格式错误被拒绝、伪造或篡改授权因签名不匹配被拒绝。Executor.verify() 使用与签发方共享的 HMAC 密钥（SPENDSHIELD_AUTHZ_SECRET，原型中有 dev-secret 回退），已消费令牌状态保存在进程内存中。
- MCP 集成：提供智能体侧与主机/人工侧的工具分离建议。智能体侧决策工具包括 spend_authorize、spend_status、spend_audit；主机/人工专用管理工具包括 spend_approve / spend_reject、spend_reset、policy_sim / policy_apply / policy_create → policy_review → policy_lifecycle_apply / policy_rollback、secret_get。
- 集成适配模式：提供 x402 / 智能体支付工具 / MCP 三种适配器模式的可运行示例（examples/integration/），无需真实资金。
【使用方式】
- 安装：pip install spendshield
- 编写一个 YAML 策略文件（policy.yaml），设定预算与商户等规则。
- 在智能体与支付之间放入一次 authorize() 调用，或直接使用返回的结果对象。
- 默认运行在 dry-run 模式：只评估、不实际花钱。
MCP 快速开始中，智能体在花钱前先询问；主机负责决定智能体可以调用哪些工具。文档指出 MCP 本身没有鉴权，需信任主机；policy_apply / policy_review 属于主机级操作。若把管理工具授予不可信智能体，当前实现不会阻止其调用。
【测试与安全】 项目包含 251 个测试、14 个以上安全套件（预算绕过、竞态条件、重放、双重花费、参数篡改、凭据泄漏等），并维护 8 条安全不变量：未授权不支付、超预算不支付、审批不匹配不支付、身份无效不支付、重放最多一次授权、并发不破坏预算、引擎故障即拒绝、智能体无法绕过 SpendShield。另有随机种子模糊测试与审计哈希链。项目设有“Break the Gate”安全挑战，鼓励在沙箱（dry_run=True / 测试密钥）中以最小复现提交绕过。文档强调：这是当前测试套件对当前实现的可复现验证，不是数学意义上的安全证明。
【适用场景】 任何让机器可以支付的系统：电商退款自动化、API 计费、x402 按次付费流程、MCP 支付服务器、Claude Code 等编码智能体、家庭自建自动化等。若机器能付款，就应有人先定好规则。
【限制与威胁模型（文档明确说明）】
- 执行强制（signed-grant executor）为实验性原型，位于 spendshield/enforce.py，与默认 authorize() 流程分离；默认公共路径保证的是决策与审计，而非密码学意义上的执行强制。将 Executor.verify() 接到支付调用之前属于集成方的部署步骤。
- 生产加固（密钥管理、持久化重放状态、外部锚定）记录在 SECURITY_HARDENING_BACKLOG.md 中，尚未完成。
- 审计链可检测部分篡改，但未加密钥、未外部锚定，无法抵御能够重写整个内存链的攻击者；加密签名 / 外部锚定在加固路线图上。
- MCP 无鉴权，需信任主机；审批 ID 为 48 位随机数；审计为内存中（追加写入在路线图上）。
- 部署模型分为 SDK → MCP → Gateway 三层，各自保证的能力不同。
【起源】 项目作者说明其动机来自一次真实事故：2026 年 8 月 9 日，其自动化流程运行了一笔测试订单，本意用 dry: true 获取价格预览，但服务器只认 ?dry=1，结果 4 笔 99 元订单被真实扣款，钱就此消失。作者由此把这次教训做成了一个库。
【价格】 资料中未提供任何收费或价格信息，暂未提供。
