We Gave an Agent Production Code Access and Then Tried to Sleep at Night — Moritz Johner, Form3

依賴補丁看似簡單，但在現代容器化環境中暗藏複雜性。傳統自動補丁工具設計於更簡單的年代，只需更新清單文件中的版本號即可。然而，當今的軟體包依賴往往跨越多個層級：基礎 Docker 映像中的 OS 套件、編譯時下載的二進位檔案、語言特定的執行時與開發工具。例如升級 Go 版本時，往往還需同步升級 linter，因為兩者版本間有隱性耦合，升級後的 linter 規則又會使現有代碼不符合規範。傳統工具（如 Dependabot 和 Renovate）無法推理這些依賴關係，只會機械地修改版本號，留下破損的程式碼供人工修復。

講者所在團隊構建了 PatchPilot，透過 AI 代理來處理這種多維度推理。但一開始遭遇 Infosec 團隊的合理質疑：這是自動化還是潛伏的供應鏈風險？這個發問深刻——一旦給予代理生產認證，它在事實上成為供應鏈的參與者，應受同等安全審查。PatchPilot 採用兩層架構迴應此挑戰。第一層是確定性的 Go 應用，負責掃描映像、發現漏洞、連結到儲存庫。第二層是 AI 代理層，負責推理與代碼修改。關鍵是：GitHub 的寫入權限、PR 開啟、CI 觸發等高風險操作不交給代理，而是由確定性層執行。代理只被允許修改本地檔案。這個設計邊界至關重要，因為依賴變更可能涉及數萬行程式碼，提示詞注入的攻擊面極大；透過限制代理的證書範圍，可大幅降低爆炸半徑。

工作流程如下：確定性層克隆儲存庫、準備上下文（包括約 2,000 字的提示詞），然後調用 CVE 補救代理進行最小變更修復。代理修改檔案後交還控制權，確定性層檢驗（清除空文件、編譯器中間產物等），提交、推送、建立 PR，然後監控 CI。若 CI 失敗，調用 PR 補救代理診斷並修復，迴圈執行直至達最大重試次數。每次代理調用後，要求代理進行簡短回顧，這樣可在規模化部署時彙總分析，發現共性問題（基礎設施故障、權限不足、儲存庫特異性）。

然而，沙盒隔離仍是生產部署的瓶頸。代理需要驗證自身工作，這意味著需要 Docker Socket 訪問以建置容器。一旦給予該權限，代理可以生成特權容器、逃逸、讀取其他進程記憶體，防線完全崩潰。現有 Linux 沙盒技術（Landlock、Bubblewrap、seccomp）都無法有效隔離容器守護進程。講者提出的設計方案是使用 Firecracker 微虛擬機，為代理提供獨立的核心與隔離環境，Docker Socket 在 VM 內部得以安全運作。再加上在 VSOC 層面實施網路策略，對代理與確定性層應用不同規則：確定性層需要 GitHub 和倉庫訪問，代理的網路需求難以預測（因語言、框架而異），可根據主機名、埠、IP 段施加規則，甚至部署 TLS 中間人檢查以阻止惡意 HTTP 請求。

當前的企業級沙盒解決方案仍不成熟。Firecracker 需要自行組裝網路與編排邏輯；Micro Sandbox Project（YC 資助的新興開源項目）承諾提供電池齊全的方案；Kubernetes Agent Sandbox SIG 和 Open Sandbox 也在試圖標準化這類需求。講者的結論是：AI 代理的爆炸半徑是一個架構決策，精心選擇哪些操作交給代理、哪些交給確定性層，才是真正的安全模型。

##