Agent 审计日志的哈希链能证明什么

AI Agent 留下了审计日志，就能证明它没被改过、没漏记动作吗？Agenthof 作者给出的答案很克制：哈希链能暴露一部分篡改，却证明不了所有行为都被完整记录，更不能让管理员控制的文件变得「不可篡改」。

这篇文章值得读的地方，是把安全承诺拆成了能验证的机制、已经交付的能力，以及尚未补上的缺口。对准备给 AI 工具调用加审计的程序员来说，这比一句「日志安全可靠」更有参考价值。

哈希链能查出改动，但验证通过有条件

Agenthof 的审计账本是一个只追加、带哈希链的文件。每条事件携带前一条事件精确字节内容的 SHA-256，相邻记录因此连起来。修改内容、删除中间一行或交换顺序，都会让后续哈希对不上。

下面这条命令用于检查某次运行的链条是否自洽，输出包含链头和事件数量：

$ agenthof audit verify r-85f417c6…
head: 4d655340… (13 events)

要看的是第二行：它报告了一个包含 13 条事件的链头，但没有提供独立依据，证明这次运行原本就只有 13 条事件。

这种机制适合发现写入损坏、迁移失误，以及没有重新计算哈希的篡改。作者称其为 tamper-evident，即「篡改可被察觉」。tamper-proof 则是更强的「不可篡改」，本机管理员控制下的只追加文件承担不起这个承诺。

链条验证通过，首先证明的是现有记录内部一致。

删除尾部再重算，为什么必须靠机外证据

假设攻击者控制整个文件，删除最后 N 条事件，再从保留的位置重新计算哈希，就能得到一条更短、仍然合法的链。只看这个文件，验证者无法区分「日志被删短了」和「Agent 当时确实少做了几件事」。

解决办法是在机器之外保存链头，再拿它与当前账本比较。Agenthof 已交付两条路径，但覆盖范围不同。

第一条是单次运行凭据：用户自行保存打印出来的链头，之后用 agenthof audit verify --expect-head sha256:<hex> 核对。它的可靠程度取决于链头存在哪里。如果日志和链头都在攻击者控制的位置，独立性就很有限。

第二条是治理账本，记录谁应用了配置、谁停用了 Agent，以及操作时间。agenthof audit anchor 可以把当前链头固定到用户指定的透明日志，例如 Sigstore 的公共日志；audit verify control 再检查账本中记录的每个锚点是否与链条一致。audit seal 则负责把账本轮转为封存分段。

这里的「锚定」，就是把某个时刻的账本指纹交给外部保存，让后续重写有东西可对照。

按作者披露，治理账本的自动外部锚定已经交付；单次运行凭据仍需手动使用 --expect-head，自动锚定只是预留方向，尚未实现。不能因为两者都叫审计日志，就默认它们有相同的保护。

动作没被写下来，密码学也补不回证据

更容易忽略的问题是漏记。

一次受治理动作经过网关执行，但写日志时发生短暂故障，或者某条代码路径忘了记录，这条事件就从未进入账本。剩下的事件照样能组成合法哈希链。

签名也无法凭空补上它。签名可以帮助验证已有记录的完整性，却不能证明所有应该生成的记录都已生成。

作者目前提供的约束包括：序号可以发现部分尾部丢失，受治理动作必须经过负责记录的入口。但静默漏记事件的检测仍在设计中。计划中的办法是对账：由网关在入口统计处理过的调用数量，再检查账本是否有同样多的记录。

这套计数核对尚未交付，不能当作现成功能使用。

还有一层信任问题：记录者是运营方自己的网关，它并不中立。治理账本的外部锚点，可以让 Agent 和运营方都无法控制的第三方提供佐证；它并不会自动证明网关最初就忠实记录了所有动作。

这张图最有用的地方，是把「能发现什么」和「是否已经交付」放在一起。Agenthof 采用 Apache-2.0，作者也明确承认项目还处于早期。

我的判断

我认同作者把完整性、记录齐全程度和证据独立性分开讨论。它们对应不同问题，不能靠一个 verify 成功提示统一回答。

与普通文本日志相比，哈希链提供了可执行的一致性检查；与只保存在本机的链头相比，外部透明日志为事后核对增加了独立依据。但外部锚定仍有边界：它能佐证已经固定下来的链头，不能替尚未记录的动作作证。

原文没有给出锚定频率、写入失败处理、性能开销，以及与其他方案的对照数据。作者称相关能力已交付，并给出了验证命令，但文章没有完整展示故障注入和攻击复现过程。因此，可以认可它对威胁边界的分析，不能据此替整个系统的可靠性背书。

计划中的入口计数也值得继续追问：计数是否可靠持久化？重试怎么算？一次调用对应多条事件时如何核对？原文没有说清。对账方向合理，具体保证仍取决于实现。

能拿来做什么

• 给 Node 服务或 AI 工具调用接入审计时，分别检查记录是否被改动、是否漏记，以及核对凭据是否保存在独立位置，避免把「验证成功」展示成「所有行为均已审计」。
• 试用 Agenthof 时，先运行 agenthof audit verify <run>，再把单次运行链头保存到独立位置，用 --expect-head 复核；不要默认运行凭据已经自动进入透明日志。
• 评估网关审计方案时，加入修改事件、删除尾部和执行成功却漏写日志这几类验证场景，并要求区分已交付能力与设计中的能力。
• 需要追踪 Agent 配置变更和停用操作时，可以重点评估治理账本的外部锚定，同时核实锚定频率和失败处理是否满足团队要求。