Proof推出Agent身份钱包：x401把交易授权从“能操作”变成“可验证”
Proof于10月15日宣布Agent身份钱包、x401与生产级MCP服务的新进展。结合6月协议公告、技术规范及接入文档，解析身份凭证、交易签名和权限边界，区分协议发布与产品上线。
AI Agent拿到了账户访问权限，是否就意味着用户同意它完成某笔交易？Proof在10月15日的公告中，把这一差别推到了产品前台：公司宣布其Agent身份钱包、x401协议与生产级MCP服务的新进展，目标是让接收请求的网站验证“背后是谁”以及“具体批准了什么”。相关上线与效果描述来自公司，本站没有独立测试。
先厘清时间线：不是10月才第一次出现x401
Proof在6月25日已经公开介绍x401及其开放、发行方中立的协议思路。10月15日公告的重点是面向实际交易的身份钱包、具体条款签名与生产服务，不宜把它简单包装成“全新协议首次发布”。对开发者而言，协议出现与可以接入的生产实现，是两个不同里程碑。
新能力：身份确认和动作授权分开验证
根据10月公告，钱包持有经核验的身份信息，并向用户展示请求的信息与交易条款，由用户在自己的设备上批准。请求方随后可以检查身份凭证以及对具体交易内容的签名。文章所讨论的是身份与授权证据，不是把钱包等同于付款账户。
这种设计试图补齐一个常见断层：密码、API密钥或访问令牌说明软件有能力进入系统，却不必然证明用户批准了当前这次动作。签名如果绑定金额、收款方等条款，改动这些已签内容就需要重新核验，而不应继续沿用原有批准。
技术背景：HTTP挑战、钱包回应、服务端核验
当前官方接入文档介绍的流程是：受保护接口返回HTTP 401，并通过PROOF-REQUEST携带凭证展示请求；Agent将请求交给钱包，用户批准后，再以PROOF-RESPONSE携带展示结果重试；接收方完成密码学核验后才决定是否放行。协议规范和Node实现为开发者提供了比宣传页更具体的参考。
官方示例还涉及验证方注册、可信Agent配置、HTTPS元数据和防重放nonce。也就是说，接入并非增加一个请求头就自动安全。生产环境仍需要明确可信发行方、凭证状态、请求作用域与异常处理，并固定所依赖的协议及SDK版本。
可能的影响：Agent接口开始需要“证据层”
编辑部认为，这类基础设施的价值在于把“模型说用户同意”转成可由接收方核验的证据。对于面向Agent开放接口的网站，设计问题会从“允许机器人还是封禁机器人”，扩展为“满足什么身份、范围和授权条件才允许执行”。它与工具连接、支付等环节并不是同一件事，也不能代替业务自己的风控。
厂商宣称支持多种MCP助手，但不代表任意客户端、任意地区、任意交易都已可用。身份核验也不等于自动满足所有监管要求、避免所有争议或保证行为合法；不要将一次签名扩张解释为无限期、全账户授权。
适合哪些人关注：有敏感动作的Agent产品团队
电商与预约平台、企业软件接口团队，以及构建可执行Agent的开发者值得跟进。以下是编辑部建议的上线检查，而非对某一方案的安全背书：
- 按动作拆权限：查看信息、修改记录和提交订单分别设定要求，避免通用令牌获得过宽权限。
- 展示人能理解的条款：把对象、范围、时限与费用写清楚，再让用户确认。
- 拒绝过期与重复证据：测试请求过期、参数变更、nonce重放和用户取消的路径。
- 最小化留存：只请求必要身份属性，设计撤销、审计、证据保留和人工处理机制。
本次值得关注的并不是“Agent终于可以随意替人交易”，而是相反：当Agent越来越能行动，网站更需要把可执行能力与可证明的用户授权严格分开。
来源参考与核验说明
本文为AI导航编辑部结合公告、代码仓库、产品文档与原始条款独立整理；未实测产品，厂商自报结果不等同于独立评测。资料核验日期：2026年10月16日。
