护城河不是内核钩子

今年，操作系统层级的 AI 代理隔离机制终于落地。6月2日，微软宣布在 Windows 上为 AI 代理提供操作系统级隔离：进程隔离、会话隔离，以及一份声明式策略，在操作执行前就限制代理能够访问的网络和磁盘内容。NVIDIA 开源了一个沙箱，将代理锁定在 Linux 安全模块之后，并强制所有连接通过策略代理。各大代理编排框架也纷纷推出自己的沙箱。真正能在代理越界时阻止它、而不是靠它自觉配合的内核钩子，正在成为标准配置。

这是好消息，值得不加保留地说：平台厂商的方向是对的。代理需要被置于它们无法讨价还价的底层约束之下。过去两年，这个观点最难的部分是说服大家它有必要。现在这部分已经过去了。这种强制原语正在像 TLS 一样商品化，每个代理运营者都会因此更安全。

但看看这些系统的共同点：策略存放在厂商的控制台里，身份放在厂商的云里，审计日志进厂商的工具链。隔离是真实的，但从头到尾由一个不是你的人治理。你得到的是一个受控的代理，同时你也得到了一个“房东”。

对于已经身处某一家厂商技术栈的大型企业来说，“房东”模式是一种合理选择——如果它被明确称为一种选择的话，那就是诚实的选择。问题是它几乎从不被明确说明。“你的代理被隔离了”和“你的代理被我们隔离，策略由我们掌控，对我们可见”是两个不同的产品，而差异不会出现在功能列表上。

“保管权”（custody）这个词正是用来描述这个差异的。我在之前关于驻留的文章中定义过，这个定义没有变：保管权意味着密钥在你的硬件上生成且永不离开，策略由你签名，系统拒绝任何其他人签名的策略，并且“拒绝”在代理之下强制执行，当权威证明缺失时自动失败关闭。即使是最强的主权云服务——那些把密钥托管转移到司法管辖区内的提供商——也只是缩短了缰绳，而不是把缰绳交给你。辖区内的保管权仍然是房东，只不过住得近一点。保管权意味着没有房东。

这就是为什么护城河从来不是内核钩子。平台可以在一个发布周期内推出钩子，几个平台刚刚就这么做了。但平台在结构上无法提供的，是只对运营者负责的强制执行，因为平台的治理面恰恰是为平台自己服务的。关键区别不在于内核是否在链路中，而在于内核听命于谁。

当这一切成真时，它看起来是这样的：Sanctuary 的 Wall 在 macOS 和 Linux 上执行经过签名的运营者策略。在 Mac 上，这一声明追溯到我们在真实硬件上捕获、而不是口头声称的证据：允许的流量通过，禁止的流量被阻断，逐一账户。证据到哪里结束，声明就到哪里结束，我们把这些边界和结果一起发布，而不是放在脚注里。如果一个供应商不愿意展示其隔离证据的边界，那本身就是对保管权问题的回答。

所以，欢迎这些钩子。每一个推出强制原语的平台，都比任何文章更好地论证了这一层的必要性，也让诚实的保管权更容易构建。仍然空白的是钩子之上、房东之下的那一层：只对运营者负责的隔离，密钥永不离开运营者硬件，支持任何平台、任何代理。这正是 Sanctuary 想要填补的层。