技术调研 · 2026.10.02

AI Agent 购物安全与支付

公开阅读版：正文与外部公开资料链接完整保留；本地证据表与复核记录未公开。公开资料检索截止 2026 年 10 月 2 日。

核心结论

购物 Agent 要安全地使用真实账户和资金，必须同时回答四个问题：秘密是否可被读取、访问者是谁、允许执行什么交易、出事后凭什么还原事实。原文中的各项措施覆盖不同环节，任何单项都不足以建立完整信任。

1. 凭据隔离要落实到运行时。 密码在保险库中加密，并不能保证自动填入网页后仍不可读。Agent 能否执行页面脚本、读取 DOM、访问浏览器调试接口和网络响应，才决定秘密是否进入其能力范围。
2. 身份和授权需要分别验证。 Agent 注册与请求签名支持来源识别；签名授权、确定性约束检查与预算账本才限制交易行为。合法 Agent 也可能被诱导或买错商品。
3. 受限支付凭据降低损失范围，但支付生命周期仍有例外。 单次虚拟卡、商户与金额绑定适合明确的一次购买；酒店预授权、延迟扣款、分次扣款、汇率及退款必须单独设计。
4. 可验证意图增强证据，责任仍需业务规则判断。 Verifiable Intent（VI）建立授权链，但其公开规范明确把争议解决排除在范围之外；“证据可验证”不能直接推导为某一方必然承担损失。VI 官方仓库

以下按技术功能将原文拆为 17 项机制与措施，逐项研究原理、实现路径、局限和验收方法。这个数量是报告的分析粒度，不是文章自带的分类或市场统计。

范围与证据

原文与研究边界

依据 The Information 的报道《Why Shopping Agents Are a Security and Payments Headache》，作者 Yueqi Yang，文章标注 2026 年 9 月 30 日 12:42 PDT，PDF 共 4 页。本报告的公开资料检索截止日为 2026 年 10 月 2 日，北京时间。原文中的 Instinct、Muse、Vault 等名称均按原文保留，不将相似产品擅自替换。

文章是一篇报道，不是产品安全审计。本报告没有访问真实支付账户、运行文中产品漏洞利用、购买商品或检验发卡行后台。文中 Instinct 通过 JavaScript 读回凭据的案例是原文所述测试；缺少可独立复现的公开测试环境、版本和修复记录，不能据此断言所有当前版本都有同一漏洞。

证据分成三种：规范与接口文档支持设计和接口语义；厂商技术说明支持厂商公开的架构承诺，不能替代独立审计；原始研究支持特定威胁和评测结论，不直接代表当前商业产品的攻防水平。本文写明“建议”“应当”或“示例”的段落是工程综合判断，不声称某厂商已经实现。

技术状态的核查

Stripe 官方确认 Muse 接入 Link，非 Link 商户可使用针对批准购买的单次虚拟卡，每笔购买要求用户确认总额；此事实与原文主要叙述一致。Stripe，2026-09-08

Shop 官方帮助页已说明部分 Agent 购物体验（包括 Muse）能显示 Shop Pay，但具体账户和体验可用性仍须按实际入口确认。Shop Pay 帮助 对原文 PayPal 与 Muse 的具体合作，本次没有取得同等粒度的公开接口说明；技术研究使用已查阅的 PayPal 官方结账文档，不将普通 Checkout 的能力直接当成该合作的实现细节。PayPal Checkout

VI 公开仓库当前标记 v0.1 Draft；“厂商宣布方案”“规范可阅读”“有参考实现”与“所有发卡行已部署”是不同状态。Mastercard 2026 年 3 月公告中的后续 API 集成计划，不能单独证明截至检索日已全面投产。Mastercard 公告

原文机制清单

M10 与 M11 分别研究“能使用几次”和“使用范围”；M13、M14、M15 分别研究“授权生成”“执行检查”“事后取证”。这些机制可以共用产品和协议，但失败方式不同，因此独立分析。完全自主购买是运行模式，不额外计作一种安全措施；原文的消费者信任比例和市场忧虑也不计入机制数量。

术语速查

以下是正文用语的阅读说明；尤其注意“用户批准”与支付网络中的 authorization 含义不同。

威胁与信任边界

从秘密到交易的攻击路径

原文案例对应的路径是：用户输入秘密 → 保险库保存 → 自动填入网页 → 页面存在明文值 → Agent 的脚本能力读取 → 明文进入模型输出或日志。前三步可以完全正常，最后三步依然形成泄露。密码输入框的视觉遮蔽和受控代码的读取能力是两回事；HTML 的密码字段不是针对获准脚本执行者的秘密隔离边界。WHATWG HTML

更一般的攻击还包括：商品页或评论嵌入间接提示注入；合法 Agent 的注册密钥被盗；用户批准后购物车被替换；多个任务并发突破累计预算；支付超时后重复下单；网站封禁后 Agent 自动寻找替代入口；争议时只有对话摘要，没有原始签名和订单关联。每种攻击都需要在实际执行边界阻断，不能只靠模型回答“我不会”。

必须分离的权限

“不见秘密”仍允许“滥用秘密完成动作”。因此凭据隔离必须与权限范围、支付审批和出口控制组合；保护机密性与保护交易正确性是两个不同验收目标。

凭据与浏览器

M01 凭据保险库与安全存储

原文定位：第 1、3 页。 Vault 保存银行卡及登录密码；Meta 表示用户分享或手动输入的凭据进入安全存储。这里直接描述的是存储和使用流程，没有给出加密算法、密钥层级或审计证据。

技术原理。 将秘密集中放在独立服务，Agent 持有凭据标识而不是明文。建议采用信封加密：每个用户或凭据域有数据密钥，密钥由独立 KMS 或 HSM 保护；授权主体、解密主体与 Agent 进程分离，记录每次秘密使用及轮换。加密解决静态文件泄露，访问控制解决谁能解密，两者不能互相代替。

实现建议。 建立 credential_id → owner → allowed_origins → allowed_actions 的受控映射；用户输入直接送到可信凭据服务，避开聊天记录和模型上下文。对接支持 OAuth 的服务时优先使用短期、最小权限令牌，结合 PKCE、受众限制与撤销机制，减少保存长期密码的必要性。IETF OAuth 安全最佳实践

局限与验收。 保险库被放在 Agent 可读的同一文件系统、环境变量或调试日志中，就没有形成隔离。即使存储安全，凭据使用后仍可能进入 DOM、剪贴板、请求追踪、截图和错误报告。用专门的合成秘密测试所有输出面，确认 Agent 拿不到原值；同时验证跨用户、跨连接器调用被拒绝，删除与撤销是否覆盖缓存和备份策略。

M02 凭据自动填充

原文定位：第 1 页。 Agent 提示用户向 Vault 输入卡片，以便在 Booking.com 代填表单。自动填充减少用户重复输入，却不天然降低使用中的泄露风险。

技术原理。 普通自动填充把秘密写进页面字段，再由商户提交。只要脚本能力、表单值读取或浏览器调试接口能观察该字段，Agent 就可能获取它。第三方托管支付字段可通过跨源 iframe 隔离商户页面脚本，但仍须限制具有更高权限的浏览器自动化接口。TLS 保护传输路径，也不能限制页面执行者读取已解密数据。

实现建议。 把秘密填充交给独立浏览器 broker；填充前验证精确源、最终跳转目标、字段类型和任务。不要仅根据页面显示的商户名称或字符串域名后缀做匹配。填充期间暂停 Agent；填充后持续限制秘密字段读取，阻止脚本执行、原始 DOM、调试和输入事件记录等旁路。支付场景优先使用商户支持的托管结账或受限支付令牌，减少长期卡片明文进入普通网页。Stripe 集成安全指南

局限与验收。 暂停只保护填充瞬间，恢复后的页面读回仍要检查。使用合成值覆盖同源字段、跨源 iframe、重定向、隐藏字段、表单事件、异常页面、截图和网络日志；验收关注“恢复 Agent 后是否仍能读回”，不能仅检查填充过程是否隐藏。

M03 凭据不可见与隔离使用

原文定位：第 1–3 页。 Instinct 声称不直接看到秘密，但原文描述了脚本读回；Muse 也公开“不见密码和支付方法”的承诺。必须把这类承诺翻译为可测试的能力边界。

已核查的产品设计。 Meta 技术说明描述独立凭据服务、代理令牌和出口处按需替换；浏览器由单独 broker 管理，Agent 接口使用受控页面表示，并限制页面 JavaScript 与调试能力。它是厂商对启动版本的架构说明，没有在本报告中接受独立渗透验证。Meta 安全架构

工程判断。 可信代理应先核对真实请求的目标、方法、路径和参数，再把无秘密的代理标识替换为真实令牌。若把代理标识发送到未经批准域名、允许 Agent 请求原始替换结果，或者能从连接器错误信息拿到秘密，仍会破坏隔离。对支持发送者约束的 API，可采用 DPoP，使令牌使用与持有者私钥绑定，降低被复制后在其他客户端使用的风险；它仍不阻止持钥 Agent 执行本身有权限的坏动作。IETF DPoP

局限与验收。 主模型不可见、浏览器子 Agent 不可见、运行时进程不可见、平台运营方不可见是不同目标。应逐个列出威胁主体，检查进程权限、socket 身份、网络出口、cookie、会话、调试与日志。即使 PAN 没泄露，Agent 使用已登录账户买错商品也是严重失败，不能归入“凭据隔离通过”后忽略。

用户批准与结账

M04 逐笔人工批准与最终确认

原文定位：第 2–3 页。 原文区分完全自主与人工按最终购买按钮的模式，强调未经用户签字不应额外花费。Stripe 的 Muse 接入公告明确每笔购买让用户批准总额。Stripe 接入公告

技术原理。 可信批准界面把人类确认与执行对象绑定。用户看到的商品、规格、卖家、税费、运费、币种、总额和订阅条款应来自冻结订单，而不是 Agent 自行生成的一句摘要。审批服务应位于 Agent 控制之外，并发出短期、限用的执行能力。

实现建议。 冻结购物车 → 生成包含版本和随机量的审批挑战 → 在可信界面确认 → 记录订单摘要和签名 → 执行前重新核验。WebAuthn 能证明基于特定来源的认证事件，但普通登录认证不自动证明用户看过全部交易字段；W3C Secure Payment Confirmation（SPC）专门处理支付详情的可信呈现和确认，目前所查版本为候选推荐草案，不能假定所有浏览器都支持。WebAuthn、SPC，2026-07-02

局限与验收。 用户在聊天中说“继续”可能被误解释；无障碍自动化可能点击自己的审批按钮；批准后价格或购物车变化形成检查与执行间隙。测试审批重放、过期、订单变更、Agent 自批、订阅新增、并发重复确认。任何改变已批准对象的动作都必须重新审批，而非复用旧批准。

M05 支付商与商户结账集成

原文定位：第 2 页。 Stripe、PayPal 与 Agent 集成，为商户提供新的支付入口。支付接口承担订单和资金执行，Agent 承担搜索和规划；这类集成的收益是稳定交易边界，而不仅是更少页面点击。

技术原理。 将结账表示为服务器可验证的状态机：创建订单、取得最终价格、用户批准、授权资金、扣款、订单确认、退款。PayPal 的官方结账路径使用服务器订单创建和捕获；Stripe PaymentIntent 用状态跟踪一个支付流程。二者的状态和字段不同，不能用一个通用“success”字符串替代具体协议语义。PayPal Checkout、Stripe PaymentIntent

实现建议。 Agent 只能提交业务参数；商户服务器重新计算价税、库存和运输选项。支付服务保管密钥，执行冻结订单，并核验签名 webhook。重试使用与业务订单稳定对应的幂等键：同一动作重复请求不能重复扣款；新订单也不能错误复用旧键。网络超时属于“结果未知”，先查询订单和支付状态再决定是否重试。Stripe 幂等请求

局限与验收。 支付授权成功不等于已扣款，扣款成功不等于发货；浏览器页面显示成功也不足以确认服务器状态。测试乱序与重复 webhook、支付成功但订单失败、授权失败但页面重试、库存售罄和取消后扣款。原文的合作公告不证明所有商户、币种和账户都已经获得这些功能。

幂等的时间边界。 Stripe 保存同一幂等键首次执行的响应，包括 500；键达到至少 24 小时后可以被清理，清理后复用会作为新请求处理。这不是“永久只付一次”的保证。建议本地保存长于业务恢复窗口的订单—操作记录和 PSP 对象 ID；超时、旧键失效或错误响应后先对账，不直接生成新键再次付款。Stripe 幂等语义

M06 复用钱包的一键结账

原文定位：第 2 页。 Shop Pay 用已保存银行卡与配送地址，让用户一键完成购买。它将账户识别和支付资料复用移到钱包侧，Agent 无须重新搜集敏感字段。

技术原理。 已登录的钱包将用户绑定到存储的支付资料，输出商户所需的结账信息和确认流程。Shop Pay 官方文档说明其保存支付、配送和账单信息；当前帮助页另有 Agent 购物入口说明。Shopify Shop Pay、Shop Agent 购物帮助

实现建议。 用户通过可信钱包界面选定付款方式与地址，Agent 只持有钱包会话和订单引用。每次使用旧资料仍须验证账户、配送对象、订单与授权范围；不应把“同一钱包账户”解释为对任何商品、任何地址、任何订阅的许可。优先保留钱包原有的认证和风险升级流程，不让 Agent 收取 OTP 或替用户完成强认证挑战。

局限与验收。 少一步点击是体验指标，不是风险指标。旧地址、共享设备、会话劫持、默认订阅、同一账户多付款方法都可能改变交易含义。测试地址切换、账户切换、余额或卡片变化、重新登录和认证挑战；确保变更触发重新展示交易对象，并把钱包批准证据与商户订单关联。

访问与身份

M07 反机器人与欺诈防护

原文定位：第 2–3 页。 网站长期以拦截 bot 减少欺诈，这也会阻止合法购物 Agent。报道中的“防火墙”是概括说法，实际可能包含 CDN、WAF、速率限制、自动化检测、账户风控和支付风控，不应把它理解成一种单独的网络设备。

技术原理。 反机器人系统依据请求与行为信号判断自动化程度，执行放行、挑战或拒绝。Cloudflare 的 bot score 衡量请求是否像自动化流量，分数并不直接衡量用户是否授权这次交易；官方还将 verified bot 作为单独概念。Cloudflare bot score、Verified bots

实现建议。 将“流量由机器产生”“运营主体已验证”“用户有授权”“交易风险可接受”分成四个判断。身份验证通过的 Agent 可获得受限入口，但仍保留速率限制、库存保护、账户接管检测和交易审核。浏览商品、访问账户、修改地址和付款应使用不同策略，不能为一个 Agent 开全站白名单。

局限与验收。 IP 和 User-Agent 可变化或伪造；合法签名也可能来自被盗密钥。验证码会阻断无人值守任务，应转交用户或使用商户认可的 API。验收同时统计恶意请求漏放与授权 Agent 误拦，保留无攻击的任务完成率；测试同一主体的异常频率、批量抢购和账户切换，而不只测试能否打开首页。

M08 Agent 注册与来源验证

原文定位：第 3 页。 Visa、Mastercard 的登记与验证机制帮助商户识别 Agent 和背后主体。注册是信任建立环节，逐请求身份验证是运行环节；登记过的主体仍须证明当前请求确由其密钥产生。

已核查的技术路径。 Visa Trusted Agent Protocol（TAP）用 HTTP Message Signatures 识别 Agent，并区分浏览与付款目的；协议另有消费者身份和支付容器的关联签名。最低示例包含目标主机、路径、时间、密钥标识、目的标签和 nonce，不能据此声称所有请求正文已经受到同一签名保护。Visa TAP 规范

HTTP Message Signatures 的通用标准只保护被明确覆盖的消息组件；正文完整性、密钥信任和防重放需要具体部署配置。IETF RFC 9421 Mastercard 的 Agent Pay 官方材料则描述 Agentic Tokens 用于注册、验证和识别 Agent 交易，公开材料粒度不同，不能假定两家采用完全相同的接口。Mastercard Agentic Tokens

实现建议。 对运营者进行登记审查，绑定受信任公钥；网关按选定协议重建签名输入，核验算法、密钥状态、时间、受众和用途，防止转发到其他商户。新增商户政策只赋予任务需要的能力。支付正文若未被当前签名覆盖，必须由额外的支付容器、订单签名或摘要绑定保护。

局限与验收。 签名证明持钥者，不证明模型遵从用户。Cloudflare 当前 Web Bot Auth 文档明确其不校验 nonce，也不维护已见 nonce 数据库，而依赖短有效期降低重放风险；商户不能把提供 nonce 字段当成已经获得单次执行保证。Cloudflare Web Bot Auth

验收覆盖密钥撤销、过期、正文变更、目的标签互换、签名复制、JWKS 缓存失效、请求重放和时钟偏差。注册目录不可用时的降级方式要预先确定；付款不能静默降级成“看到熟悉 User-Agent 就通过”。

金额与支付凭据

M09 消费额度限制

原文定位：第 3 页。 支付商为 Agent 设置消费上限，防止意外超支。额度至少有单笔、累计、时间窗口、用户与任务范围之分，不能只在自然语言提示里写一个金额。

已核查的接口语义。 Stripe Issuing 支持卡或持卡人的金额、商户类别、国家等控制；文档提示累计统计为尽力而为，可能延迟最多 30 秒，追加费用也可能导致上限被突破。商户 ID 控制在所查文档中标记为私人预览。这些是通用 Issuing 接口的边界，不是对 Muse 专用钱包实现的实测结论。Stripe spending controls

实现建议。 在应用侧建立强一致预算账本：支付前原子地预留额度，已授权未扣款金额也计入占用；扣款后转为已花费，取消或授权释放后按核实状态释放预留。同一用户下所有并发 Agent、卡和任务都应遵守共同预算。金额使用币种规定的最小单位整数，外币订单在报价和批准时明确换算方式与上限。

工程示例。 预算 100 元，两个 Agent 同时各申请 60 元。如果只是各自读取“已消费 0”，两笔都可能通过；正确路径要求第二次原子预留失败。这个例子是并发设计说明，不是任何产品的测量结果。退款是否恢复可支出额度、何时恢复、重复退款如何防止，应成为明确政策，不能由模型临时决定。

实时授权的工程约束。 Stripe 的同步授权 webhook 在所查接口中只有 2 秒响应时间；超时会按已配置的默认策略或 Autopilot 设置批准或拒绝。关键资金决策不宜临时等待一轮长模型推理，应读取已批准订单和已预留预算，快速做确定性判断，并明确超时拒绝策略。此接口限制不应未经核查套用到所有钱包。Stripe 实时授权

局限与验收。 单笔上限不限制大量小额交易；每张卡限额不限制跨卡累加；授权金额不总等于最终扣款。验收用并发请求、重试、退款、跨币种、窗口边界与多卡场景验证总账不变量，并对无法同步拦截的后续扣款配置监控与争议处理。

预算不变量的适用范围。 建议在准许新支付授权前检查“已计入该预算的消费 + 未释放预留 + 本次预留 ≤ 预算”。币种、预算窗口和退款恢复政策必须一致。后续追加或强制扣款可能突破这个事前控制范围；应如实记入实际支出并报警，不能把账面金额截断到预算来制造“未超支”的结果。预算预留也只是应用账本状态，不等于银行已经冻结相同金额。

M10 单次使用虚拟卡

原文定位：第 3 页。 Stripe 可为 Muse 发放单次使用虚拟卡。其安全价值是不给 Agent 一张可长期在任何地方消费的底层卡，减少可复制凭据的有效范围。

技术原理。 PSP 或发卡服务为一次购买生成可被现有卡支付商户接受的凭据，后端控制使用次数与状态。这里的“单次”必须明确究竟是一笔订单、一次成功授权，还是一次授权及其后续扣款序列；这些定义在酒店、分批发货和重试中不能互换。

实现建议。 为每笔已批准订单保留卡映射、允许的授权类型、生命周期和退款路由。卡号不进入模型上下文，真实值由可信组件填充或发送。执行服务负责一次使用状态，不能依赖 Agent 记住“用过了”。卡已关闭后仍要保存非秘密映射，以便追踪退款、撤销、拒付和对账。

局限与验收。 普通“创建一张虚拟卡”的 API 不自动等于具备单次消费语义。0 元验卡、商户重试、分次扣款和订阅可与简单用后销毁逻辑冲突；只改卡状态也不能逆转已授权的扣款。Stripe 通用 Issuing 文档说明已授权交易的 capture 不受卡状态和授权控制重新判断，并支持向停用或取消卡处理退款。Stripe 交易生命周期

验收至少包含两个同时到达的使用请求、失败后重试、部分扣款、晚到扣款与卡关闭后退款，确认“单次”的系统定义与商户实际行为一致。Muse 专用卡是否具备相同全部边界，仍需钱包合同或沙箱验证。

M11 按批准购买约束凭据

原文定位：第 3 页。 原文明确虚拟卡额度按特定批准购买设定。与“单次”相比，本项回答凭据在哪个商户、以什么金额、在多长时间内有用。

技术原理。 把支付能力绑定到 order_id、merchant_id、payee_id、amount、currency、expires_at；执行时验证实际订单和实际收款方满足限制。Meta 公开架构说明进一步描述了特定商户、特定金额和有限有效期的限制，但这仍是厂商技术自述。Meta 购买安全设计

实现建议。 商户身份使用已验证的主体标识，不仅是可变的显示名称；钱包侧和商户侧共享冻结订单引用。超过批准总价、变更币种、添加商品或订阅都重新审批。不能只用商户类别码代替精确商户；也不能将支付授权层可识别的商户 ID 当成对购物车内容的验证。商品一致性要由订单摘要、SKU 约束或用户复核补足。

局限与验收。 平台型商户、支付聚合方和市场卖家可能使用不同收款标识；域名、卖家和账单主体需要事先建立映射。酒店的押金、未入住费用及延迟扣款不是已知零售总价的一次支付，无法不加修改地沿用同一策略。测试同名不同商户、批准后改价、支付网关换收款方、超时、重定向和平台子商户变化。

M12 钱包绑定与底层信息隐藏

原文定位：第 3 页。 单次虚拟卡连接 Link 中用户已有银行卡或银行账户，Agent 不获得底层付款细节。它分离资金来源与执行凭据，并不意味着整个支付链路都没有敏感数据。

技术原理。 钱包拥有底层付款资料和用户身份，Agent 获取短期、受限的支付能力。EMV Payment Tokenisation 使用替代值减少 PAN 暴露，并可限定使用域；但网络 token、PSP 保存对象、单次虚拟卡和共享支付 token 是不同技术对象，不能仅因都叫 token 就当作等价。EMVCo Payment Tokenisation

实现建议。 定义 Agent、钱包、商户、收单方与底层资金来源分别能看到哪些字段；每次消费先生成明确请求，由钱包认证用户并授权，再输出交易凭据。安全边界应包含撤销、余额检查、会话过期、资金来源切换、通知及对账。钱可以从卡或银行账户支持的路径支付，并不证明其退款和争议规则一样。

局限与验收。 不见 PAN 不等于不见可盗用 token；长期钱包会话也可能被滥用。若 token 是 bearer 凭据，复制后仍可能在有效域内使用。支付信息的隔离还不能防止错误商品、错误地址或取消失败。验收用底层凭据扫描、钱包会话盗用、账户解除连接、来源切换与退款映射检查可用权限是否真正收缩。

该表是技术对象对照，不暗示某钱包将五者全部实现。判断时应先确认发行方、验证方和执行方，再评估 token 泄露后的可用能力。

授权与争议证据

M13 Verifiable Intent 授权记录

原文定位：第 4 页。 Mastercard 用可验证意图记录用户给 Agent 的权限。本项解决的是授权从口头指示变成可验证对象，不等于把自由文本的全部含义自动转换成正确约束。

技术原理。 VI 的公开草案采用分层 SD-JWT：凭据提供方绑定用户身份及公钥，用户签署授权，自主模式中 Agent 再签署最终行为。即时确认模式不需要同样的自主委托层。cnf.jwk 连接相邻签名主体，选择性披露让不同参与方看到与其职责相关的字段。VI 凭据格式

SD-JWT 通过带盐披露值和摘要实现字段选择性披露，key binding 用于将凭据呈现与持有者密钥关联；JWT 的 cnf 表示可用于持有证明的密钥信息。这些机制提供完整性和绑定，不是对全文加密。IETF SD-JWT、IETF cnf 语义

实现建议。 用户先确认结构化授权，服务再签名；自主任务应明确预算、商户、商品、次数、时间和取消方式。签名私钥最好在用户可信设备或经验证的托管边界内。平台代持用户私钥虽然可部署，却意味着平台有代签能力；不能把“存在用户签名字段”当成用户亲自审阅的证明。需要保存可信 UI 版本、所展示对象和认证事件。

局限与验收。 签名能保护错误表达的授权不被篡改，不能纠正表达错误。“便宜的同款”“不要不可信卖家”等语义要求仍要转换成可执行规则，并由用户复核关键解释。验收包括用户密钥替换、跨用户拼接、授权过期或撤销、披露字段缺失、未知版本和错误委托链；密钥轮换与失窃处置必须独立设计。

撤销尚需部署方补齐。 VI v0.1 没有定义凭据层撤销协议，短有效期和支付网络的冻结、拒绝控制只能覆盖部分风险。用户在平台撤销任务，并不自动使所有外部验证者手中的签名失效。建议明确撤销状态由谁维护、缓存多久、执行器何时重查，以及已经发起的支付如何取消或对账；不能把一个 revoked 布尔值视为跨机构撤销已经解决。VI 撤销边界

M14 购买与授权的一致性验证

原文定位：第 4 页。 文章说 VI 记录 Agent 是否遵循指令。技术上应拆成密码学验证、规则验证和业务语义验证三层，缺一层都不能声称完整遵从。

已核查的规范要求。 VI 要求将 checkout 与 payment 绑定到同一个 checkout_jwt 原始字符串，并校验 checkout_hash 与 transaction_id 均等于 B64U(SHA-256(ASCII(checkout_jwt)))。v0.1 中购物车对象的结构与签名细节仍由实现定义，验证商户签名属于 SHOULD 建议，不能把摘要一致当成已完成商户身份认证。其约束另覆盖商户、商品、收款方、金额、预算与周期；描述性文本不能单独当作精确商品限制。VI 凭据格式与绑定、VI 约束

实现建议。 验证链签名、算法、schema、受众、有效期与持有者密钥；解析选择性披露后再检查约束；把批准的购物车、实际下单和实际付款连到同一个对象。商品限制尽量落到可信 SKU、GTIN、数量与变体标识。图片相似、名称相同或价格低于上限都不足以证明买到了同款。

状态性边界。 nonce 需要与受众、有效期和接收方的原子去重检查配合，才能阻止同一执行凭据重放；仅生成唯一值并不够。持钥 Agent 仍可能为同一授权签出不同新凭据，因此支付网络还须维护委托的使用次数与累计支出。VI Security Model

局限与验收。 验证器不认识的开放授权约束不能静默丢弃；币种、最小单位、商户匹配和商品列表的空值语义要按所用版本解释。测试同金额换商品、同商品换收款方、已批准购物车替换、隐藏额外商品、重复生成新凭据和未知约束。所有验签及金额比较都由确定性代码执行，不能让 LLM 给出“看起来合规”后放款。

严格模式必须显式配置。 约束规范 §5.4 要求 open mandate 中的未知约束一律拒绝；一般验证器同时支持 PERMISSIVE 与 STRICT，默认 PERMISSIVE 可跳过未知类型。支付实现应显式采用 STRICT，并检查逐类型策略是否又允许跳过关键约束。这里要区分“解析时保留字段”“验证时执行约束”与“遇到未知规则拒绝”，不能仅凭字段未丢失就认定权限受限。VI 校验模式

M15 意图证据接入拒付处理

原文定位：第 4 页。 Mastercard 受访者称发卡行能在常规拒付系统中获取意图数据，帮助判断成本由谁承担。这里的价值是提供可核对证据，不能推导成统一的责任转移条款已经覆盖全部 Agent 交易。

技术原理。 把授权、购物车、付款凭据、商户订单和实际交易 ID 关联，争议发生后按权限取回并验证。VI 本身不规定拒付解决；AP2 v0.2 主规范描述授权与回执作为争议证据，并区分各方验证职责。VI 范围、AP2 v0.2 固定版本

实现建议。 形成两种输出：供验证器使用的原始签名对象、披露值和关联信息；供争议工作人员阅读的简明证据包。证据包明确谁批准了什么、实际买了什么、实际付给谁、何时履约以及争议类型。应支持签名版本、密钥历史和授权时的状态回放，不要只保留“验证通过”的布尔值。

局限与验收。 意图证据并不证明商品已送达，也不证明退订已完成。发卡行、商户与钱包是否实际接收原始签名，需要具体网络与收单接口确认；无法接收时，完整证据要转换成被接收的材料。Stripe 当前争议指南明确银行不会通过外部链接自行查资料，因此仅给审查者一个网页 URL 不够。Stripe 争议应答

验收模拟四类案件：用户未授权、Agent 超出授权、商户未履约、用户授权后改变主意。核对每类材料是否回答对应问题、是否能离线复核，以及披露是否只限于该交易。

M16 传统证据与责任处理

原文定位：第 3–4 页。 收据、配送确认和客户沟通帮助商户证明购买与履约；发卡行与商户通过拒付程序处理争议。原文把某些证据与线下购物联系起来，但这些证据在电商交易同样有作用。

技术原理。 责任处理依赖争议原因、适用网络规则、认证情况、授权证据、履约证据和合同。Stripe 官方流程中，支付服务协助提交材料，通常由发卡行评估结果；部分网络合规案件还有网络层处理。因此不能把“发卡行做判断”扩大成任何案件都由其单方最终决定。Stripe dispute lifecycle

实现建议。 用同一 case_id 聚合订单、授权、支付、物流、售后和沟通，按案件类型生成证据。身份或授权争议需要授权链与认证；商品未收到需要配送或服务履行材料；订阅取消需要取消请求、条款与后续扣款时间。签名日志与履约证据互补，聊天记录只能补充上下文。

责任边界。 3-D Secure 用于支付认证和风险信息交换；某些条件下可影响欺诈争议的责任，但不是对买错商品、未履约或任意争议的保险，也不能自动证明 Agent 获得了合适委托。EMVCo 3DS、Stripe 3DS flow

局限与验收。 技术归因和法律承担损失不是同一问题。例如，Agent 违反授权但商户如实履约，需要进一步核对平台、钱包和网络合同，不能仅凭日志强制商户退款。验收确认材料保存期限覆盖业务争议窗口，证据不含 PAN/CVC 等秘密，权限和完整性可核验，并支持取消、退款及异常扣款的对账。

M17 商户封禁与第三方访问同意

原文定位：第 4 页。 Amazon 封禁 Muse，理由包括未披露第三方访问账户、处理交易和敏感数据。此事件在本报告中按用户文章记载，不把没有取得的商户内部策略视为已核实技术事实。

技术原理。 商户在入口和业务系统决定自动化主体可以使用什么功能。封禁可能通过 WAF、账户策略、API 权限、会话绑定或 Agent 识别实现；robots.txt 只是给愿意遵守的爬虫的访问声明，不能代替登录账户和付款接口的强制访问控制。

实现建议。 用户委托和商户许可是两道边界。商户可以开放专门的商品查询和结账 API，要求披露运营主体，分配任务权限与速率限制；不参加某一识别协议的商户仍能拒绝访问。Visa TAP 也明确商户是否采用该方案是可选的。Visa 商户角色规范

局限与验收。 广泛封禁会提高误拦与业务机会损失，全面放行则扩大账户风险。报告建议保留商户选择权，同时用明确错误与可替代的人工路径改善体验。测试被拒绝后的 Agent 行为：停止交易、说明原因并交接，而不是修改身份、换入口或借用户会话绕开政策；同时测试账户解除连接后旧会话与旧授权失效。

协议与机制比较

各方案回答的问题

ACP 与 UCP 是为解释 M05、M06 的实现背景而补充的研究，不计入原文 17 项。ACP 提供 Agent 结账交互规范，UCP 描述可互操作的商业能力与流程；它们与授权证据方案的关系应按具体能力和版本验证，不能把 MCP、A2A 或“有一个工具调用”本身看作支付授权。ACP 官方文档、UCP 官方概览

版本与互操作

本次固定核查的 AP2 主规范标题为 v0.2，使用 Checkout Mandate 与 Payment Mandate；仓库中的早期 Python 示例仍可见 IntentMandate、CartMandate 名称。报告以已固定的主规范为基准，不把不同代际 schema 混装。AP2 还要求相关验证在确定性代码中完成；实现时应锁定 vct、算法与验证责任，而不是靠术语相似推测兼容。AP2 固定提交

VI、TAP、Web Bot Auth 和商业协议的密钥、时间、nonce、对象绑定与算法要求不同。应逐层解析和验签，不能“上层签名通过就跳过下层校验”。签名对象应按原始规定的字节序列验算；把 JSON 美化、重序列化或转成聊天摘要再算摘要，可能破坏绑定。多协议适配应有每种组合的互操作测试，而不是仅有单一 happy path。

参考架构与执行流程

把模型与执行权限分开

以下是根据前述机制综合得到的参考架构，不是任何厂商的内部架构或本报告已部署系统。规划 Agent 处理搜索与建议；凭据 broker、审批服务、预算账本和支付执行器形成可信执行面，职责彼此分离。

用户 ──可信确认界面──> 授权服务 ──冻结订单/签名──> 策略验证器
  │                                              │
  └──任务──> 规划 Agent ──交易提案───────────────┤
                 │                               ▼
                 ├──受限浏览器/API──> 商户    原子预算预留
                 │                               │
                 └──无明文凭据引用──> 凭据 broker │
                                        │        ▼
                                        └──> 支付执行器 ──> 钱包/PSP/网络
                                                    │
授权/订单/支付/物流 ──原始对象与关联标识──> 证据存储与争议处理

强制入口。 浏览器、API、连接器、后台任务及子 Agent 都经过同一策略边界。否则受控支付工具可以被任意网络请求绕过。身份服务只回答“谁”，审批服务回答“允许什么”，预算账本回答“还剩多少”，支付执行器负责“执行到哪一步”。规划模型没有修改这些系统的权限。

最小授权对象。 建议至少包含授权 ID、用户身份引用、Agent 或任务公钥、商户和收款方、币种、金额或累计预算、订单引用、允许商品或变体、数量、有效期、使用次数及撤销策略。对于不支持的约束，系统应明确拒绝该授权模式或交给用户逐笔审批，不能静默丢弃。

凭据使用。 对 API 在出口授权后按需插入 token；对浏览器通过受限 broker 操作；对支付尽量输出交易范围的凭据。任意脚本、直接网卡出口、调试通道和可改工具实现都是重点旁路。提示注入检测可帮助筛查，但资金硬条件仍由确定性策略决定。

交易状态与幂等

草案 → 已报价 → 待批准 → 已批准 → 已预留预算 → 已发起授权
                                                    │
                                    ┌───────────────┴───────────────┐
                                    ▼                               ▼
                                 已授权                           授权失败
                                    │                               │
                                 已扣款                         核实后释放预留
                                    │
                                  已履约
                                    │
                              退款/争议/售后

报价变化使批准失效；授权超时进入“结果未知”的核实分支；退款不会把原始交易历史删除。付款回调只更新与其对象对应的状态，不得让晚到 webhook 把已取消订单直接改成已履约。重复通知去重，跨服务故障恢复从持久状态继续，不重新创建无关联付款。

通知与状态分开处理。 Stripe 官方文档说明 webhook 可能重复、也不保证事件顺序。建议验证原始请求体签名、按事件标识去重，并在缺少前置状态时查询对应支付对象。支付状态与订单/物流状态分别记录；收到“已扣款”事件不能直接写成“已履约”。普通异步通知可先可靠入队再确认接收；M09 的同步实时授权接口则必须在其时限内返回明确决定，不能套用异步处理方式。Stripe webhook

以下是业务策略伪代码，没有实现任何标准的完整验签或产品接口，也未在本任务中作为支付代码运行：

accept_payment_operation(approved_order, mandate, operation_key):
    authenticate_caller_and_check_order_owner()
    fingerprint = business_fingerprint(approved_order, mandate, "authorize")
    if an operation already exists for (owner, operation_key):
        require saved_operation.fingerprint == fingerprint
        return existing_operation_reference   # query/reconcile; no new payment
    verify_crypto_schema_and_frozen_order(approved_order, mandate)
    require merchant_policy_and_all_constraints_allow_this_order
    atomically:
        recheck_expiry_revocation_use_count_and_budget()
        insert_unique_operation_and_outbox_or_reuse_matching_existing()
        reserve_budget_only_for_a_new_operation()
    return operation_reference

dispatch_or_reconcile(operation):
    claim_exclusive_execution_right(operation)
    if a dispatch attempt is already recorded:
        reconcile_that_attempt_without_creating_a_new_payment()
        return
    credential = trusted_wallet_get_scoped_credential(operation.order)
    recheck_authority_order_version_and_execution_right()
    persist_dispatch_attempt_before_external_call()
    result = controlled_executor_authorize(operation, credential, same_psp_key)
    persist_result_and_evidence_idempotently()
    keep_reservation_if_result_is_unknown()
    release_or_commit_budget_only_for_verified_financial_state()

预算事务和外部支付不构成一个普通数据库事务。必须用持久操作记录、幂等键和补偿/对账恢复，而不是在数据库提交后假定网络调用必然成功。一次 Agent 任务可能有多个模型回合，它们都应引用同一业务交易对象。

恢复与撤销的边界。 以上伪代码省略锁、事务消息和 PSP 适配细节；它强调先保存操作，再派发资金动作。已有付款在任务过期或撤销后仍须查询和对账，不能因前置有效期检查失败而停止核实。如果准备凭据失败且能确认尚未派发，可释放预留；若付款已送出或结果不明，应保留状态并查证。部署时要明确撤销与派发的先后判据，并阻止失去执行权的旧工作进程继续发送；已派发请求是否可取消由 PSP 能力决定。退款、撤销支付授权与取消商品订单也必须分别处理。

证据保存与隐私

建议保存四个相互关联的对象：用户批准的订单及授权；Agent 最终行动和确定性验证结果；PSP 授权、扣款与退款标识；商户订单和履约材料。原始签名对象保持不可变，展示摘要另存，审计日志可用追加写和摘要链检测篡改，并由独立密钥签署关键记录。

选择性披露只限制“展示哪些声明”，不自动解决日志访问、存储加密、删除和跨交易关联。敏感商品购买记录也可能具有隐私风险。审批与取证应只携带需要的信息，不保存 PAN/CVC、密码、邮箱全集或无关聊天；具体保留期限应按业务争议周期与适用要求设置，不能盲目永久保存。

场景、验证与实施

场景选择

原文从 Booking.com 酒店表单切入，因此旅行场景是必要研究对象。酒店支付可能在授权后较长时间才扣款；通用 Issuing 文档还描述了后续 capture、超额 capture 和 force capture 的特殊边界。这说明“卡的可用期很短”不能单独证明最终支出被锁死。Stripe 交易边界

建议旅行 Agent 在批准界面分开呈现立即付款、押金、后续付款、取消和未入住条件。若无法生成与这些义务相容的受限凭据，就保留人工付款步骤。不能为了完成预订而扩大卡额度或改成不受约束的底层卡。

提示注入的研究证据

原文案例主要说明凭据能力边界，而浏览网页带来的间接提示注入是相关的扩展威胁。AgentDojo 在工具与不可信数据之间评测攻击和防御；InjecAgent 专门测试工具集成 Agent 的间接注入与信息外泄。二者支持“外部内容可能劫持动作”这一风险判断，不能据此给当前 Muse 或 Instinct 填上攻击成功率。Debenedetti 等，AgentDojo、Zhan 等，InjecAgent

CaMeL 将控制流、数据流和能力约束放到模型外围，说明结构化执行边界可以降低对模型抵抗注入能力的依赖。其 v2 在 AgentDojo 报告 77% 的安全任务完成率，对照未防护系统为 84%；这个结果受其评测任务和安全模型限定，不是现实电商系统的通用指标。Debenedetti 等，CaMeL v2

后续防火墙研究还指出基准实现和测试覆盖会影响防御结论。故验收应使用业务任务、实际攻击面和自适应攻击，同时测正常任务可用性；不能因某论文在公开基准上攻击成功率很低就移除权限或资金限制。Indirect Prompt Injections，预印本

验收矩阵

以下是实施者应运行的评测设计，本报告未运行这些产品攻防或支付沙箱测试。通过标准是工程建议，不是已取得的厂商评测数据。任何泄露或资金越权应单独记录，不能被平均完成率掩盖。

32 个用例已逐项关联到全部 17 项机制；这是最低覆盖核对，不表示穷尽了每项机制的故障组合。执行前应为每个用例固定产品版本、攻击者权限、订单样本、期望状态转换和证据保存位置。

指标建议。 记录秘密泄露事件数、未经授权动作数、越过预算的授权与最终扣款、重复订单数、审批对象不一致数、证据缺失率及正常任务完成率。统计分母分别使用被测攻击、交易尝试或业务任务，不把不同分母混成一个安全评分。关键失败类别按最坏案例检查；攻击成功率还需说明攻击者能力、尝试预算与自适应程度。

实施顺序与成本

这种顺序先缩小危险能力，再增加自主性。成本高点通常在遗留浏览器页面、支付异常恢复、商户身份映射、商品语义和争议运营，不能只按一次模型调用成本估算。没有业务流量、PSP 合同和现有系统数据，本报告不虚构金额、上线周期或 ROI。

应优先落实 M03、M04、M05 的执行边界和 M09 的共享预算，然后扩大虚拟卡和协议覆盖。把不同供应商的注册、钱包、VI 和商业协议接在一起之前，应要求其公开支持版本、地区、商户范围、验证职责、超时策略、退款路径和事故处理联系人。

来源与剩余不确定性

关键资料

下列均为技术研究中实际查阅的原始资料或官方文档；正文中的链接放在相关结论旁。厂商说明与规范的适用范围不同，不能仅按来源数量判断结论强弱。

版本留存：VI 仓库检索时提交为 356c29635f1c44df7de02edb58699ca9f29bece6；AP2 为 e1ea56db72a6385bce3e5c1112b3a56ce60acb43。关键规范文本、检索记录与 SHA-256 保存在交付目录的 evidence 中，以便区分之后的文档变更。

必须保留的未知项

1. Instinct Vault 案例的产品版本、复现环境、根因和当前修复状态未取得公开可复核材料；不作全版本漏洞断言。
2. Muse 的隔离架构属于厂商公开说明，本报告没有验证其所有浏览器、连接器、会话及网络旁路。
3. Muse 专用 Link 钱包与通用 Stripe Issuing 的控制实现未证明完全相同；文中通用接口例外用于提示必须验证的边界。
4. PayPal 与 Muse 合作的细粒度接口、账户开放范围，以及 VI 进入各发卡行拒付系统的部署覆盖未取得完整公开证据。
5. 授权可验证不直接回答责任归属；须进一步核对具体网络、地区、交易类型与平台合同。
6. 对“便宜、合适、可信、同款”等语义意图的正确转换仍是开放工程问题；商品身份和可信批准不能被签名替代。

本次制作与复核

首轮按页提取原文并逐项核对机制覆盖；Jev 实际用于一次 21 段分类请求，返回模型为 jev-1.13.0，使用量为输入 5,646、输出 1,132 tokens。支付集成段落分类置信度较低，且虚拟卡段落横跨授权与凭据；最终机制划分、技术研究、判断和报告复核由 Codex 完成，未让 Jev 决定交易或执行权限。第二轮复核未再调用 Jev，内容检查由 Codex 完成，编号、引用与验收覆盖用确定性脚本核对。

报告自身的检查与优化记录另存为《质量检查与优化记录》，包括内容修订、引用与覆盖检查、实际渲染检查，以及未执行的产品测试。本文中的验收矩阵是可供后续实施使用的设计，不是对所讨论厂商安全性的认证。