你所验证的对象并非实际运行的对象
最近一个新工具引起了关注。它位于 curl 等命令之前，在脚本运行前向你展示内容，并高亮显示危险部分。这个工具很有用，但它忽略了核心问题。
问题不在于字节流看起来是否具有恶意。问题在于，一个 URL 今天可以提供一个脚本，明天却可以提供另一个。你的检查仅适用于某一特定时刻。
系统专家将此称为 TOCTOU。它的全称是 time-of-check to time-of-use（检查时到使用时）。你检查了一个文件，但在你打开它之前，有人将其替换了。你的检查是正确的，但它针对的是一个已经不存在的东西。
AI 智能体让这种风险变得更高。智能体在不断地进行检查。
- 一个智能体 ping 一个 URL，并将成功的响应视为安全的信号。
- 一个智能体读取一个配置文件，并将声明视为事实。
- 一个智能体看到一个签名，便假设它即将运行的字节流正是被签名的那些字节。
每次检查都将信任寄托在某个时刻或某个通道上。随后，智能体会对下游的某些内容采取行动，而这些内容从未被检查覆盖过。
例如，一个智能体可能会验证工具清单（manifest）并缓存结果。如果智能体在调用工具之前端点（endpoint）发生了变化，智能体运行的就会是错误的版本。验证通过了，但它通过的是一个智能体不再使用的清单。
试图通过加强扫描来解决这个问题是行不通的。更多的规则只能缩小窗口期，而不能关闭它。在你的扫描与执行之间的几毫秒内，生产者仍然可以提供不同的制品（artifact）。
要解决这个问题，请停止验证“时刻”，开始验证“制品”。
将你的决策绑定到一个不可变对象，而不是一次 fetch 操作。
- 不要批准一个 URL。
- 批准一个特定的内容哈希。
- 更好的是，批准一个由信任密钥签名的哈希。
这将问题从“这段文本看起来可怕吗？”转变为“这是否是密钥所担保的那个精确制品？”如果哈希不匹配，你就拒绝它。无需争论。
这种方法还使验证具有可移植性。第三方可以使用相同的哈希和签名自行验证结果。这是对象本身的属性，而不是你检查时的瞬时状态。
使用这两个问题来测试任何验证：
- 校验是绑定在所使用的确切制品上，还是绑定在一个时刻和一个承诺上？
- 一个陌生人能否重新运行该校验并得出相同的结论？
如果第一个问题的答案是“一个时刻”，那么该校验就有有效期。如果第二个问题的答案是否定的，那么你拥有的不是验证，而是证词。
目前大多数智能体验证都只是证词。“握手成功”或“扫描结果无害”是关于某个时刻的真实陈述，但它们并没有绑定到实际运行的字节上。
智能体在没有人工监督的情况下执行成千上万次操作。如果你不将信任锚定在制品上，整个链条都会继承最弱、最旧的校验结果。
你不需要新技术来解决这个问题。内容寻址和数字签名已经存在几十年了。你只需要将它们指向正确的目标：即实际执行的精确字节，而不是获取它们的请求。
在你信任一个校验之前，先弄清楚它绑定的是什么。如果它绑定的是一个时刻，那么它已经过期了。
Source: https://dev.to/anp2network/the-thing-you-verified-is-not-the-thing-that-runs-hnl
Optional learning community: https://t.me/GyaanSetuAi