Molt 实战：在测试环境里给 AI Agent 加上单次、限额、可核验的购买权限
让 Agent 搜索商品、生成购物清单，和让它真正提交订单，是两个安全等级完全不同的问题。前者出错通常只是答案不佳；后者一旦被提示注入、错误路由或上下文污染影响，就可能把外部动作带到不该去的商家、金额或商品上。一个常见但过于粗糙的做法，是把可长期使用的支付凭据交给自动化程序，再依赖提示词要求它“不要乱买”。这没有把风险变成系统可执行的约束。
Molt 是一个 Apache-2.0 的开源协议与参考实现，讨论的是更窄的命题：怎样把有上限的、可撤销的购买授权交给 Agent。它并不是支付处理商，也不承诺能让 Agent 安全地进行真实消费。当前公开的参考 Tab Authority 明确只在 Stripe 测试模式与 Base Sepolia 测试网下运行，并拒绝在其他环境启动。因此，更合适的定位是：用它研究“外部动作如何被限制和留证”的工程模型，而不是拿它接管生产付款。
先把授权拆开：人、Tab Authority 与 Agent
Molt 的结构不是让 Agent 直接持有用户真实的银行卡，而是在用户、Tab Authority 与 Agent 之间放入一层可收窄的授权。用户先通过 passkey 完成一次人为授权，创建一个带预算约束的 tab；Agent 后续拿到的是受该 tab 限制的能力，而不是一张可到处使用的长期卡号。
这个模型最值得借鉴的部分是“作用域”而不是“自动下单”。每次购买使用一次性的 shell：它应对应一个已知商家、一个精确购物车和一个金额边界，并且在授权后失效。仓库的威胁模型把提示注入视为默认前提：若 Agent 被诱导访问从未在 tab 中出现过的商家，流程应转为等待用户用 passkey 再次确认；即使是已知商家，单笔额度、速率和 tab 剩余额度也继续限制结果。
这和给 Agent 一把“权限很大的 API key”不同。前者把权限拆成对象、时间、金额和目标四个维度；后者通常只能依赖代码分支或模型自律。也要正视边界：Molt 的 README 明确表示它不规避反机器人机制、不托管资金、不发起支付，也不提供强客户认证或售后保障。协议约束能缩小技术上的爆炸半径，不能替代商家条款、合规审查和人工决策。
在测试模式启动参考实现
官方 Quickstart 要求 Docker，以及一个已启用 Issuing 测试模式的 Stripe 账户。先克隆项目并准备环境文件：
git clone https://github.com/meyerdav24/molt cd molt cp .env.example .env docker compose up
最小配置涉及会话密钥、Tab Authority 的签名密钥、Stripe 的测试模式 restricted key，以及可选的邮件配置。不要把这些值写进仓库，也不要把本地 .env 发给 Agent 对话。启动后访问 http://localhost:3000/login，用 passkey 注册并创建 tab。这里的人为步骤不应被“自动化掉”：它正是把初始授权从 Agent 操作中分离出去的控制点。
做实验时，先写下 tab 的三项意图：允许的总预算、单次上限和测试商家范围；再记录创建时间与测试任务 ID。这样后续看到一条收据时，能回答“它属于哪一次实验、由谁授权、为何允许”，而不是只知道请求曾经成功。若你的目标只是验证接口，不要跳过这个记录步骤；审计材料应该从实验开始产生，而非在事故后才临时拼凑。
MCP 接入：把工具能力当作受限接口
Molt 的 MCP 服务暴露五个工具：open_tab、connect_tab、resolve_merchant、purchase 与 get_receipts。工具数量少并不等于风险小，关键在于调用顺序和每一步能否被单独核验。官方示例可将本地构建出的 MCP server 配到客户端：
mcp_servers:
molt:
command: node
args: [/path/to/molt/apps/mcp-server/dist/index.js]
env:
MOLT_API_URL: https://moltprotocol.dev
MOLT_AGENT_KEY: ${MOLT_AGENT_KEY}
这里的 MOLT_AGENT_KEY 是与一个 tab 相关联的 Agent key，不应当被误认为平台级管理员密钥。更稳妥的测试顺序是：先由 Agent 调用 open_tab 获取需要人工确认的地址；人完成 passkey 流程；再从仪表盘为该 tab 创建 Agent key，配置进本地 MCP 进程；最后调用 connect_tab。把 key 放进受权限保护的本地 secret store 或 CI 的密钥系统，而不是提交进 YAML，是基本要求。
不要让一个提示词从“找商品”直接跳到 purchase。把工作流拆成四段：检索阶段只输出候选和价格依据；商家解析阶段用 resolve_merchant 识别目标；人工或策略层比对购物车与预算；最后才允许购买工具执行。每段都输出结构化摘要，下一段只消费必要字段。这样，恶意网页文本即使进入检索上下文，也较难直接变成未经核对的外部动作。
收据不是日志装饰，而是验收输入
自动化流程经常只检查 HTTP 200，忽略“系统究竟批准了什么”。Molt 在项目结构中将收据签名与 molt verify CLI 放在协议包内，并提供 get_receipts 给 Agent 读取。对测试任务来说，至少应把以下检查写入验收：收据是否属于预期 tab、商家和购物车是否匹配、金额是否未超过单笔与总额限制、是否出现了需要升级人工确认的事件。
一个可重复的验收策略是把“购买请求”和“购买成功”区分开。请求阶段验证输入：商品标识、数量、货币、目标商家与预算；完成阶段验证输出：收据、授权边界、是否消耗了一次性凭据。若其中任何一步缺失，就将任务标记为待人工处理，而不是让 Agent 再试一次。对有副作用的工具而言，盲目重试可能比一次明确失败更危险。
把验收实现为独立的只读步骤也很重要。它不应复用能够下单的 Agent key 去“顺便修正”异常，而应只读取收据与任务输入，并输出机器可比较的结论。实践中可以为每次演练生成一份不可变的预期清单：允许的 merchant 标识、购物车哈希、金额区间、tab 标识和预期的人工升级状态。验收器逐项比对后写出通过、拒绝或待确认原因；任何不一致都停在人工队列。这样即使模型把自然语言总结说得很合理，自动化链路仍需面对具体字段是否匹配的事实。
还应故意设计失败用例：改变购物车总额、改到陌生商家、重复提交同一购物车，或让 Agent 在已有上下文中读到“忽略限制”的恶意字符串。测试的目标不是证明模型永远不会犯错，而是确认限制仍然在模型犯错时生效。若限制只存在于提示词而不是授权对象或服务端验证中，这类测试很快会暴露问题。
哪些团队适合先试
Molt 更适合安全工程、Agent 平台团队或研究原型，用于学习如何对高风险工具调用实施最小授权、人工升级和可验证收据。即使你的业务不涉及支付，也可以迁移其思路：为部署操作限制环境与变更窗口，为采购 API 限制供应商和预算，为数据导出限制数据集与有效期。重点不是复刻支付流程，而是让“允许什么”成为可检查的数据结构。
它不适合被当成生产消费自动化的即插即用方案。项目仍处于 test-mode beta；真实资金、客户身份校验、商家规则和合规责任都不因接入协议而消失。对于生产系统，先以只读检索、草稿订单和人工批准作为默认路径，再逐步评估是否需要更细粒度的、由服务端执行的授权边界。
如果把 Agent 看成会出错、会被污染、也会遇到网络故障的执行者，权限设计就不应只问“它能否完成任务”，还要问“失败时它最多能做什么”。Molt 提供的价值正在于把后一问带回可测试的协议、配置、收据和人工确认环节中。