MCP-identity 发布：为 AI 代理的每个请求加上“加密签名”，杜绝事后抵赖
当你的 AI 助手执行了“删除数据库”或“转账”操作，你能否证明这是你本人授权的，而非误操作或恶意代码？开源项目 mcp-identity 的出现，正是为了解决这个日益凸显的信任难题。它并非要取代现有的 OAuth 2.1，而是在会话认证之上，为每个请求增加了加密级的不可否认性（Non-Repudiation）。
OAuth 未能解决的问题：“会话有效”不等于“你签了这份文件”
目前，基于模型上下文协议（MCP）的服务器已具备 OAuth 2.1 认证。但它仅能证明在会话层面，“某个用户”是连通的。项目作者尖锐地指出：“会话有效并不等同于用户对这个确切的有效载荷、在这个确切的时刻签署了同意书。” 对于金融操作、数据删除、对外通信等高风险的“工具调用”，一旦出现事故，管理者无法在事后证明“是哪一次请求得到了谁的授权”。mcp-identity 填补的正是这个审计盲区。
其解决方案极为精炼：在每个 HTTP 请求中添加一个名为 X-MCP-Identity-Attestation 的头部。该头部包含一个 JSON 对象，内含用户的 DID、时间戳、随机数（Nonce）、请求体的哈希值，以及使用 Ed25519 算法对上述字段的签名。服务器端可在毫秒级验证签名的有效性、时间窗口（默认 30 秒）以及请求体是否被篡改。
与 OAuth 互补，而非替代：明确两层安全职责
mcp-identity 的定位非常清晰：它不是 OAuth 的竞争者，而是其必要的补充。OAuth 解决“你是谁”，而 mcp-identity 解决“你是否确认为这一笔具体交易签过名”。在一起审计中，前者提供用户身份，后者提供不可抵赖的签名证据。作者特意列出对比表格：OAuth 处理会话身份，mcp-identity 处理按请求的审计追踪。
项目提供了“宽松（permissive）”和“严格（strict）”两种运行模式。推荐用户从宽松模式开始部署，逐步过渡到严格模式，确保所有客户端都遵循签名规范后才开启强制验证。对于分布式部署，作者也指出必须使用共享的 Redis 等 Nonce 存储，否则重放攻击防护将因实例间缺乏状态同步而失效。
当前局限与未来展望
作为 v0 版本，mcp-identity 承认存在几个关键约束：目前密钥管理依赖于用户自行保管密钥文件，对非技术用户不友好；仅有 Python 参考实现；密钥无法轮换和撤销。这些功能被计划在 v0.5 版本中通过浏览器扩展或钱包集成来改善。
总结：mcp-identity 为 AI 代理时代的高风险操作提供了关键的“操作签名”层，让“谁在何时授权了什么”变得可追溯、可证明。它在安全协议栈中找到了一个精准的切入点，将是构建可信自主代理系统的重要基础设施。
