8 篇文章

Agent 隔離邊界

從容器、gVisor、microVM 到共用硬體上的隱蔽通道：拆開「在隔離環境中執行」這句話，看 AI agent 的程式碼被哪幾層擋住、哪些資源仍然共用、出口怎麼被找到，並以 OpenAI 2026 年的紅隊文章為案例。

系列導讀

Agent 的程式碼跑在哪裡：容器、核心、主機、網路與監控五層隔離

一段 agent 程式碼從執行到連線會穿過五層：容器、核心邊界、共用主機、網路邊界、監控。每層只承諾一件事，共用主機這層幾乎沒有承諾。

容器共用 host 核心，gVisor 在中間插一個使用者空間核心，microVM 多一個 guest 核心加 hypervisor；三種都還共用同一台 host 的 CPU 快取與儲存。

兩個互不連線的程式可以靠共用資源的快慢傳位元：一方改變資源狀態，另一方計時。這類通道要先約好協定，速度慢、容易被雜訊蓋掉；本機實驗在 20 bps 以下幾乎全對，100 bps 以上錯誤明顯增加。

OpenAI 自述紅隊 agent 在共用主機上用快取、儲存、CPU 時間與 TLS 憑證快取做出通訊管道，多數通道很慢；多數測試被指定了通道或給了協定，頻寬與錯誤率沒有公開。

沙盒沒有直連網路，不代表沒有出口：套件代理、DNS 解析器、metrics 服務這類被放行的服務，只要能替人發請求就是出口。OpenAI 的三個案例都是這個形狀。

沒有任何一項防守同時擋住旁路通道與出口。擋通道的核心是不共用，擋出口的核心是收窄被放行的服務，監控只負責發現，自動停止是事後回應，兩者都不是預防。

依我的判斷，OpenAI 談的是訓練前沿模型的研究環境；個人 agent 最該先做的是限制憑證與出口，旁路通道要到有第二個需要被隔離的租戶時才變成主要風險。

這則轉述的事實大多對得上原文，出入集中在三處：把「被指定」寫成「自行摸索」、補上原文沒有的細節、加上原文沒有的悲觀語氣。