可变的数据库日志算不上证据——任何拥有写入权限的人都能修改它，而且修改之后这张表看起来和修改之前一样值得信赖。不可篡改审计轨迹则不同：这是一个经哈希链接、可独立验证的账本，其中每个事件都与前一个事件相连，因此篡改是可检测的，而不只是被劝阻。以下是这在技术上究竟意味着什么，以及它具体如何适用于 AI 代理。
面向 AI 代理的不可篡改审计轨迹，是一种仅追加、经哈希链接的事件日志，其中每条记录的加密哈希都包含前一条记录的哈希，因此在序列中任何位置进行的修改、删除或插入都会打破链条，并能被独立、以数学方式检测到。它不是一个仅靠策略保护、防止编辑的数据库——而是一种结构，篡改会不可避免地留下自身的证据。
每个生产系统本身就已经有日志了。应用日志、请求跟踪，一张带有 occurred_at 列、并带有指向触发它的代理的外键的 Postgres 表。问题不在于这些东西不存在——而在于它们无法证明任何关于自身完整性的事情。
这一切都不需要恶意——普通的常规数据库操作权限就足够了。可变日志只是一种断言：事情就是这样发生的，请相信我们。对于执行真实操作的自主代理——发送邮件、转移资金、接触客户数据——当有人最终问出“这个代理到底做了什么，我们又如何知道这条记录是准确的？”时，一个断言是不够的。
这个机制比听起来要简单。账本中的每个事件都有一个 content_hash——这是该事件内容的加密哈希——它同时基于事件本身的数据，以及指向紧邻前一条记录的 previous_event_hash。这意味着每个事件的哈希都依赖于截至该点的整条链的历史，而不仅仅是事件本身。
新事件被追加到链条末尾。这个设计中没有更新或删除操作——账本只会不断增长。
事件 N 的哈希包含了事件 N−1 的哈希。事后对事件 N−1 做任何改动，都会产生与事件 N 记录的前驱哈希不同的结果。
验证过程会遍历每一条记录，根据内容和记录的前驱重新计算预期哈希，并确认其与存储值一致。任何一处不匹配，都会导致该点之后的整条链断裂。
这与区块链和 Git 提交历史背后的结构性理念是一样的——以内容寻址、链式关联的方式——只是应用在审计日志上，而不是货币账本或代码库上。
VeriSwarm Vault是一个仅追加、经哈希链接的账本，在 Max 套餐中提供。通过套件处理的每个事件——信任决策、Guard 扫描结果、Passport 验证、代理生命周期变更——都会自动写入其中，无需单独的日志调用。每条账本记录都会记录：
event_id, actor_type / actor_id, subject_type / subject_idevent_type, source, occurred_at, ingested_atcontent_hash — 该事件的加密哈希previous_event_hash — 紧邻前一条记录的哈希完整性可以按需在 GET /v1/suite/vault/verify 检查，该接口会遍历整条链并返回它是否完整，同时给出已检查的记录数量。验证失败会被当作安全事件处理，而不是数据质量问题——原因正在于链条断裂意味着账本已经无法证明它所声称证明的内容。账本数据也可以导出（JSON 或 CSV，可按事件类型、操作者或代理筛选），并附带校验和以便离线验证。完整的字段级细节参见Vault 文档.
眼下最明确的具体应用场景就是 EU AI Act。第 12 条要求高风险 AI 系统在其整个生命周期内自动记录事件，其形式要能识别风险情况，并经受住第 26 条规定的六个月保留期。经哈希链接的账本，正是把“我们有日志”变成监管机构或审计人员真正可以信赖的证据的关键。这项要求，以及 Vault 具体如何满足它，详见面向 AI 代理的 EU AI Act 第 12 条日志记录。不可篡改审计轨迹是通用机制；第 12 条只是当下具备可执行性的一个具体理由。
不可篡改并不意味着存储层能在物理上阻止写入——大多数数据库在技术上都可以被拥有足够权限的人编辑。它的含义是篡改是可检测的。在经哈希链接的账本中，每个事件的内容哈希都包含了前一个事件的哈希，因此每条记录都以密码学方式与其前驱记录相连。在链条的任何位置修改、删除或插入一条记录，都会导致该点之后计算出的所有哈希不再匹配——篡改会在验证时立即显现，而不是保持不可见。
普通日志——应用日志、Postgres 审计表、CloudWatch 记录——记录的是某个事件发生过。但它无法证明该记录此后没有被更改过。任何拥有该表写入权限的人（工程师、被攻破的凭据、自动化清理脚本）都可以编辑或删除一行数据，而这张表看起来依旧和之前一样值得信赖。经哈希链接的账本弥补了这一缺口：完整性不再只是一种断言，而是可以通过链条验证以数学方式核查的事实。
验证从第一个事件开始遍历整个账本，根据每条记录的内容以及记录中其前驱的哈希重新计算预期哈希，并确认与存储值一致。VeriSwarm Vault 通过 GET /v1/suite/vault/verify 暴露该能力，返回 ok: true 或 false，并附带已检查的记录数量。返回 false 意味着某条记录在正常操作之外被修改、删除或插入——VeriSwarm 的建议是将其视为安全事件，而不是数据质量缺陷。
在 VeriSwarm Vault 中，凡是通过套件记录的事件——信任决策（allow/review/deny）、Guard 安全扫描结果、Passport 身份验证、代理生命周期变更（kill switch、委托授予）——一旦 Vault 启用，都会自动写入。每条记录都会捕获操作者、主体、事件类型、时间戳、载荷以及用于链接的哈希。无需任何额外的日志调用；这只是代理在平台上正常运行的一个副产品。
监管是想要它的理由之一——EU AI Act 第 12 条的记录保存要求就是一个直接的例子——但更根本的需求要广泛得多。任何拥有一定自主性的代理（可访问工具、面向客户的操作、处理财务或 PII 数据）都会带来这样一个时刻：终会有人问“这个代理到底做了什么，我们能相信这条记录吗？”。可变日志用一句断言来回答这个问题。而不可篡改、可独立验证的日志，则用证据来回答。
不可以——Vault（包括经哈希链接的账本和链条验证端点）是 Max 套餐的功能。Gate 的免费套餐涵盖信任评分和事件摄取，但不可篡改审计账本本身是一项付费能力。当前套餐详情参见 /pricing。
Vault 是 Max 套餐的功能——经哈希链接的账本、链条验证以及导出功能都不在免费套餐中。阅读完整的技术参考，或者查看它与某项特定法规的对应关系。