摘要

  • 11 月 2 日的一份个人草案提出五类签名记录，从事故处置授权、凭据撤销清查，一直连到 AI 代理重新运行的决定。
  • 复工记录有十六个证据栏。每栏要么指向证据摘要，要么写明该问题为何未处理；缺口不能靠省略字段藏起来。
  • 记录链通过一致性检查，只能证明文件相互吻合。审批者是否真独立、风险是否足以放行，仍要由接收方另行判断。

关机容易，重新开机得有人认账

事故发生后，停掉代理通常是明快的动作。过几天，业务又要它接回工具和凭据。谁证明问题已经处理？谁愿意承担剩下的风险？11 月 2 日草案把答案拆成五种记录：R1 记处置授权，R2 记凭据撤销清查，R3 记复工决定，R4 记跨组织共同授权，RB 记撤销能触及的边界。它们以 in-toto Statement 表示，装进签名的 DSSE 封套。

R3 允许全面恢复、分阶段恢复、继续受限，或尚无法确定。分阶段恢复要列出重新开放的代理、工具、路由或凭据。记录还写明审批者的角色及其自称的独立性依据。十六个证据栏覆盖根因、资产完整性、事故重演测试、恢复后监控、剩余风险、高层批准和资产所有者确认等问题。每栏可放证据的 SHA-256 摘要，也可填 notAddressed 并给理由。草案容许公开承认尚未处理，却不让空栏悄悄消失。

这套文件靠摘要接线。接收者要核对前序记录是否恰好出现一次、类型是否正确、是否属于同一事故、签发时间有无倒置，链条是否绕成圈。分阶段恢复的凭据还必须出现在一份 R2 清查中。全部通过，判定仅是 bundle-consistent：文件之间说得通。接收者接着用自己的准入规则决定哪些证据够用。

最敏感的是“独立审批”。草案明确说，independenceBasis 是制作者的陈述。要求外部独立判断的一方，应自行核验被点名的审批者。同一人既停机又批准复工，可以如实记录；能否接受这种权力集中，取决于接收方。IETF 状态页将其列为个人 Internet-Draft；目前查到的记录没有工作组采纳或实际部署证明。