*** 自主 AI 代理權限失控的治理危機
隨著 Claude Code、Codex 等現代自主 AI 代理（AI Agent，指能夠根據任務目標自行規劃步驟、呼叫外部工具並執行程式碼的自動化模型系統）在軟體工程領域的廣泛應用，開發團隊正經歷前所未有的生產力變革。這些代理不再只是在對話視窗內生成靜態程式碼，而是被賦予在使用者本機或伺服器環境中安裝相依套件、存取內部 API 以及操作受保護資料夾的自主能力。然而，這種靈活性背後卻潛藏著嚴重的安全隱憂與維運混亂。
為了讓 AI 代理能夠順利執行日常任務，工程師往往必須為其開啟廣泛的系統權限，例如掛載主機目錄（bind mounts，指將主機作業系統的特定資料夾直接映射至容器內部）、授予涵蓋廣泛資源存取權限的長期金鑰，或是臨時在防火牆規則中開闢例外通道。在目前的實務運作中，這些至關重要的權限授權通常分散隱匿在工程師個人的終端機歷史紀錄、各雲端平台的權限設定儀表板，或是暫時存在於應用程式記憶體中。這種缺乏單一、可追蹤且具版本控制的交付物（artifact）現狀，導致資安團隊難以進行靜態合規審計，更無法在代理發生非預期行為時即時界定責任邊界。Docker 指出，當前 AI 代理權限設定的混亂局面，正如十年前各家容器技術各自為政的混亂時期，若不建立統一標準，各大執行環境供應商勢必會自行發明互不相容的封閉方案，造成雲原生生態系嚴重破碎。
Docker 攜手 CNCF 建立 Sandbox Kit 標準
根據技術媒體 InfoQ 的報導，Docker 於 9 月 24 日在 WeAreDevelopers 技術大會上正式宣布，計畫將其開發的 Sandbox Kit 規範（Sandbox Kit Specification）提交給雲原生計算基金會（CNCF，Cloud Native Computing Foundation，負責管理 Kubernetes 等主流開源雲原生專案的中立組織）。該規範採用寬鬆的 Apache 2.0 開源授權協議，目前演進至第三版（v3），核心目標是讓 AI 代理所能存取的系統權限，能夠像代理本身的程式碼與環境一樣具備完全的可攜性。
這項提案獲得了業界廣泛關注與支援。在規範制定與概念驗證過程中，Docker 已經與包括 AWS、Box、Datadog、Dynatrace、JFrog、NanoClaw、OpenClaw、Palo Alto Networks 以及 Snyk 等多家雲端基礎架構與資安大廠展開深度合作。CNCF 技術長 Chris Aniszczyk 對此項舉措表達高度歡迎，並強調開放標準正是驅動技術生態系快速前進且不致破碎的核心關鍵。Docker 過去曾將其 Docker 映像檔格式與底層容器執行引擎 runc 捐贈給社群，進而催生了開放容器倡議（OCI，Open Container Initiative，制定容器映像檔與執行環境通用標準的產業聯盟）；如今，Docker 再次將這種將複雜環境標準化的經驗，複製到新興的 AI 代理安全治理領域。
Sandbox Kit v3 核心架構：以標準 OCI 映像檔封裝權限
在 Sandbox Kit 第三版規範中，架構設計出現了重大突破。過去探索階段中的 Kit 曾依賴特殊的產物類型，但在 v3 中，Kit 徹底拋棄了專屬的自定義媒體類型（custom media type），也不再依賴傳統伴隨主映像檔的 Sidecar 附屬組態檔案，而是完全收斂成一個標準的 OCI 映像檔。
在底層結構上，Kit 的映像檔清單（manifest）內部僅包含一項關鍵宣告描述符：vnd.docker.sandbox.kit.descriptor。這種與原生標準完全相容的設計，帶來了極大的實務效益。工程團隊可以完全沿用現有的 DevOps 工具鏈，直接使用 docker buildx build 構建 Kit 產物、使用 docker pull 進行拉取，並能直接相容於各家雲端儲存庫的靜態弱點掃描工具與數位簽署機制。更重要的是，在 Dockerfile 中，Kit 能直接以 FROM 指令作為基礎映像檔引用；當工程師固定映像檔的內容摘要值（pinning the digest）時，不僅固化了代理內部的二進位工具與檔案系統，同時也將其請求的權限邊界永久綁定，徹底杜絕了權限在不同環境部署時遭受未授權篡改的風險。
宣告式權限語法與代理憑證保護機制
Sandbox Kit 中的權限宣告採用嚴格的型別化與語意版本化設計，例如 com.docker.sandbox/network-policy@2 用於定義網路原則，com.docker.sandbox/credential@1 則用於聲明憑證需求。在規範釋出的 GitHub 命令列工具範例中，Kit 清楚聲明允許存取 api.github.com 網域名稱，但同時針對包含 /repos/** 的路徑明確宣告拒絕 HTTP DELETE 操作。在規則衝突判定上，規範強制執行拒絕優先（deny wins）原則，只要存在任何一條拒絕規則，該危險操作便會被嚴格阻擋，防止代理因模型幻覺而誤刪重要程式碼庫。
針對高風險的機敏憑證存取，Sandbox Kit 設計了高防禦性的憑證代理機制（Proxy-managed credentials）。當沙盒啟動時，符合規範的執行環境會在網路邊界架設代理伺服器；在沙盒內部的 AI 代理環境中，完全拿不到真實的存取權杖，只能看到無效的哨兵值（sentinel value，指在系統內充當佔位符且不具真實驗證功能的假字串）。當 AI 代理發出 API 請求時，外部代理伺服器會在上游攔截流量，動態將真實的鑑別權杖注入發往合法網域的標頭中。透過這種架構隔離，即便 AI 代理內部遭受提示詞注入攻擊（Prompt Injection，指惡意輸入誘騙模型打破原有系統限制的攻擊手段），攻擊者也絕對無法從沙盒內部竊取任何真實金鑰。
職責解耦：宣告與主機決策的嚴格分離
在安全模型哲學上，Sandbox Kit 堅守職責分離原則。Kit 產物內部所包含的內容僅僅是權限的宣告性請求（request），最終是否核准並具體執行，其最高裁決權完全保留給宿主機的執行環境。如果將一個包含 Sandbox Kit 描述符的映像檔部署在一般的標準容器執行環境中，該宣告標註會處於完全不具任何作用的惰性狀態（inert），僅作為純中繼資料存在。相對地，在一個具備 Sandbox Kit 解析能力的執行環境中，若宿主機發現某項被標記為必要的權限宣告因政策或硬體限制無法被滿足，系統將採取安全失敗原則，直接拒絕啟動該沙盒任務。
Docker Sandboxes 與微虛擬機器的混成組合機制
為落實規範，Docker 推出的 Docker Sandboxes 成為首個相容於 Sandbox Kit 的執行環境實作。考量到 AI 代理執行不受信任程式碼的潛在破壞力，Docker Sandboxes 放棄了傳統共用作業系統內核的容器方案，轉而採用微虛擬機器（microVM，指啟動時間僅需數百毫秒、擁有獨立輕量作業系統內核與硬體隔離特性的虛擬化技術）來執行代理任務，確保沙盒具備最強層級的系統隔離。
在單次沙盒啟動流程中，系統會載入一個主要的工作負載 Kit（Workload Kit），由其提供完整的根檔案系統，隨後可疊加任意數量的混入擴充層（Mixin overlays）。這些 Mixin 擴充層不再依照工程師在命令列輸入參數的前後順序盲目載入，而是透過每個 Kit 內部宣告的提供項目與需求項目（provides/requires）進行拓撲相依圖譜解析。若啟動時發現存在未被滿足的相依需求，或是出現兩個 Kit 同時宣告提供相同名稱功能的衝突，系統解析將直接報錯中止。在權限疊加層面，規範支援規則正規化，例如將多個 Kit 宣告的網路存取網域取聯集合併；若遇到無法相容的底層衝突則立刻視為系統錯誤。此外，每一個描述符都能被收斂化簡為一組標準化的權限授權集合，這讓執行環境能夠精準進行版本比對，一旦發現新版映像檔試圖擴大存取權限，甚至暗中移除原有的拒絕存取規則，更新閘道即可在第一時間加以攔截，有效防範權限潛變（Privilege Creep）的風險。
實務效益、測試生態與現存限制
為了協助社群驗證與落實標準，規範內建了兩套獨立的相容性測試套件，分別針對 Kit 交付物本身以及外部執行環境進行合規檢查。有興趣嘗試的工程師可以透過公開的 docker/sandbox-kit-spec 程式碼庫獲取資源，並搭配官方釋出的 sbx 命令列工具，以類似 sbx run 的指令將任務與權限套件動態組合並進行本地測試。
然而，這套架構在邁向成熟普及的過程中，仍面臨若干客觀限制與挑戰。首先，雖然現行的容器倉庫、靜態安全掃描器與供應鏈簽署工具無須修改即可儲存與流轉這些產物，但 Sandbox Kit 引入的描述符語法與每項細緻權限能力的運作語意皆屬全新架構，開發團隊需要經歷一定的技術學習曲線。其次，權限的實際強制執行力完全取決於底層執行環境的實作水準；截至目前為止，Docker Sandboxes 仍是市場上唯一完整支援該規範的相容執行環境，這意味著 Sandbox Kit 跨越不同廠商執行環境（如不同雲端平台或競爭對手產品）的可攜性，在實務生產環境中尚未獲得多方驗證。最後，該規範在提交 CNCF 後，目前尚未正式公布是否已獲技術監督委員會（TOC）接納，亦未確定將進入沙盒階段（Sandbox）或孵化階段（Incubating）。在治理權正式轉移之前，Docker 仍負責維護規範演進，並正積極向全球社群徵求反饋，以完善更多尚未被涵蓋的執行環境權限表達需求。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。