護城河不是內核鈎子

今年，操作系統層級的 AI 代理隔離機制終於落地。6月2日，微軟宣佈在 Windows 上為 AI 代理提供操作系統級隔離：進程隔離、會話隔離，以及一份聲明式策略，在操作執行前就限制代理能夠訪問的網絡和磁盤內容。NVIDIA 開源了一個沙箱，將代理鎖定在 Linux 安全模塊之後，並強制所有連接通過策略代理。各大代理編排框架也紛紛推出自己的沙箱。真正能在代理越界時阻止它、而不是靠它自覺配合的內核鈎子，正在成為標準配置。

這是好消息，值得不加保留地説：平台廠商的方向是對的。代理需要被置於它們無法討價還價的底層約束之下。過去兩年，這個觀點最難的部分是説服大家它有必要。現在這部分已經過去了。這種強制原語正在像 TLS 一樣商品化，每個代理運營者都會因此更安全。

但看看這些系統的共同點：策略存放在廠商的控制台裏，身份放在廠商的雲裏，審計日誌進廠商的工具鏈。隔離是真實的，但從頭到尾由一個不是你的人治理。你得到的是一個受控的代理，同時你也得到了一個“房東”。

對於已經身處某一家廠商技術棧的大型企業來説，“房東”模式是一種合理選擇——如果它被明確稱為一種選擇的話，那就是誠實的選擇。問題是它幾乎從不被明確説明。“你的代理被隔離了”和“你的代理被我們隔離，策略由我們掌控，對我們可見”是兩個不同的產品，而差異不會出現在功能列表上。

“保管權”（custody）這個詞正是用來描述這個差異的。我在之前關於駐留的文章中定義過，這個定義沒有變：保管權意味着密鑰在你的硬件上生成且永不離開，策略由你簽名，系統拒絕任何其他人簽名的策略，並且“拒絕”在代理之下強制執行，當權威證明缺失時自動失敗關閉。即使是最強的主權雲服務——那些把密鑰託管轉移到司法管轄區內的提供商——也只是縮短了繮繩，而不是把繮繩交給你。轄區內的保管權仍然是房東，只不過住得近一點。保管權意味着沒有房東。

這就是為什麼護城河從來不是內核鈎子。平台可以在一個發佈週期內推出鈎子，幾個平台剛剛就這麼做了。但平台在結構上無法提供的，是隻對運營者負責的強制執行，因為平台的治理面恰恰是為平台自己服務的。關鍵區別不在於內核是否在鏈路中，而在於內核聽命於誰。

當這一切成真時，它看起來是這樣的：Sanctuary 的 Wall 在 macOS 和 Linux 上執行經過簽名的運營者策略。在 Mac 上，這一聲明追溯到我們在真實硬件上捕獲、而不是口頭聲稱的證據：允許的流量通過，禁止的流量被阻斷，逐一賬户。證據到哪裏結束，聲明就到哪裏結束，我們把這些邊界和結果一起發佈，而不是放在腳註裏。如果一個供應商不願意展示其隔離證據的邊界，那本身就是對保管權問題的回答。

所以，歡迎這些鈎子。每一個推出強制原語的平台，都比任何文章更好地論證了這一層的必要性，也讓誠實的保管權更容易構建。仍然空白的是鈎子之上、房東之下的那一層：只對運營者負責的隔離，密鑰永不離開運營者硬件，支持任何平台、任何代理。這正是 Sanctuary 想要填補的層。