去年Q4，某云厂商的AI运维agent凌晨2点清空了生产数据库。值班工程师翻遍日志，只看到一行"DELETE executed"——谁下的令？用的什么权限？前一个操作是什么？全成了罗生门。
这不是技术故障，是协议层的身份真空。 人类员工删文件要填工单、走审批、留签名，AI agent却能在零见证的情况下执行同等危险的操作。更麻烦的是，事后追责时，现有日志系统既无法证明"谁授权"，也无法保证"没被篡改"。
Receipt机制：给每个动作发一张"数字发票"
加密审计轨迹（Cryptographic Audit Trail）的核心设计很朴素：agent执行任何操作前，必须生成一张带签名的收据（receipt）。这张收据包含动作名称、参数、时间戳和一个随机数（nonce），用Ed25519非对称签名算法私钥签署。
Ed25519的优势在于签名速度快、密钥短、抗侧信道攻击。一张收据通常几百字节，生成耗时不到1毫秒——对高频agent操作几乎无感知。
收据的防篡改机制像快递单号。 签名覆盖所有字段的规范表示，改一个字节签名就失效。没有私钥，伪造收据在计算上不可行。同时每张收据包含前一张的哈希值，形成链条。删掉中间任何一环，后续所有收据的"上一哈希"字段都对不上。
这和证书透明度日志（Certificate Transparency）、区块链的数据结构同源，但目的更纯粹：不是为了去中心化共识，而是为了可验证的时序完整性。
MCP协议的原罪：有工具调用，没身份层
微软主导的MCP（Model Context Protocol）正在成为AI agent与外部系统交互的事实标准。它定义了agent如何发现工具、传递上下文、执行调用——但协议本身不解决"谁在执行"和"谁该负责"。
现状是：agent拿到API密钥就能操作，密钥泄露或权限配置错误时，系统几乎无法区分"合法agent"和"冒名者"。日志能记录"某个请求来自某IP"，但无法密码学证明"该请求由持有特定私钥的agent发起且未被篡改"。
加密收据填补的正是这个缺口。它把身份从"网络位置的暗示"变成"密码学凭证的展示"，把审计从"事后翻阅文本"变成"自动验证数学关系"。
从"发生了啥"到"能证明啥"
传统日志的问题是信任链条太长：存储系统管理员能改、应用开发者能改、有数据库权限的都能改。加密收据把信任锚点移到agent自身的私钥——这是唯一需要保护的根。
企业部署时的典型架构：agent在可信执行环境（TEE）或硬件安全模块（HSM）中生成并保管私钥，收据实时推送至只追加存储（WORM, Write-Once-Read-Many）。即使agent服务器被攻破，攻击者无法回溯伪造历史收据，因为私钥不离开安全边界，旧收据的哈希链已固化。
一些团队正在探索更激进的方案：将收据批量提交至公共日志系统（类似CT日志），利用第三方的时间见证服务（Roughtime、Amazon Time Sync）进一步锚定时间戳，防止本地时钟回拨攻击。
这改变了安全事件的响应逻辑。 过去出事后开会扯皮"是不是agent干的"，现在可以要求对方出示收据链，验证签名、检查链条完整性、核对时间戳。没有有效收据的操作，系统默认拒绝承认。
Receipt标准目前由OpenAI、Anthropic等厂商各自推进，尚未统一。但底层密码学原语已经成熟：Ed25519签名、SHA-256哈希、Merkle树聚合——这些在TLS 1.3、Signal协议、加密货币钱包中跑了十年的组件，正在被重新组装成AI时代的审计基础设施。
一个值得关注的细节：收据设计刻意保留了"人工复核"的接口。每张收据包含的动作参数可以人类可读，签名验证可以独立工具完成，不绑定特定云厂商。这比某些闭源AI系统的"黑箱操作记录"更符合企业合规要求。
当agent开始管理AWS账户、操作Kubernetes集群、访问客户数据时，"相信但验证"（Trust but Verify）的老原则需要新实现。加密审计轨迹不是万能药——它不能阻止agent犯错，但能让错误被精确归因、让恶意行为留下不可磨灭的密码学证据。
Receipt机制普及后，第一个被问责的可能是协议设计者：为什么MCP 1.0没把这作为强制选项？
热门跟贴