安全與容器化

沙箱與憑證隔離

Agent 生成的程式碼和使用者的金鑰永遠不能在同一個地方。這是安全架構的硬性要求，不只是最佳實踐的建議。

核心原則

生成的程式碼和金鑰
永遠不能在同一個地方

這是管理 Agent 安全的第一原則：憑證與執行環境的物理隔離。

舊方案出了什麼問題

傳統架構：一個容器裝所有東西

所有東西在一個容器裡

程式碼執行、API 金鑰、OAuth Token、會話憑證，全部共存在同一個執行環境中。Agent 能看到的一切，惡意程式碼也能看到。

Prompt Injection 一步偷走金鑰

攻擊者只需透過 Prompt Injection 說服 Agent 執行一行程式碼（echo $API_KEY），就能竊取環境變數中的所有金鑰。整個攻擊鏈極短，防不勝防。

Agent 越聰明，問題越嚴重

能力更強的 Agent 意味著更強大的工具呼叫能力。而在舊架構下，這也意味著更大的攻擊面。模型的進步不會自動解決這個問題，反而會讓它惡化。

模型能力越強，安全問題越嚴重。這意味著安全架構不能依賴模型自覺，必須靠結構性設計來保證：即使模型被完全控制，攻擊者也拿不到憑證。

兩種憑證隔離模式

MODE 1

綁定到資源

Token 在使用時被嵌入到資源的存取路徑中，從不作為獨立變數存在。Agent 能用它，但看不到它。

GIT 克隆場景

Token 在克隆時注入到 remote URL 中：
https://token@github.com/repo.git
沙箱內的 Agent 可以正常執行 push/pull 操作，但無法直接讀取或提取 Token：它被嵌入在 Git 配置的深層，不是一個可讀的環境變數。

Token

注入 Remote URL

Agent 可用不可見

MODE 2

Vault 代理模式

Token 存在安全的 Vault 服務中，Agent 的每次 API 呼叫都透過代理轉發。代理根據 Session ID 查詢對應憑證並注入請求，Agent 永遠接觸不到原始 Token。

MCP OAUTH 場景

Agent 發起 MCP 呼叫時，請求先到達代理服務。代理根據當前 Session ID 從 Vault 中查詢對應的 OAuth Token，將 Token 注入請求頭後轉發到目標 MCP 伺服器。Agent 全程只知道「呼叫成功了」，但從未見過 Token 的任何一個字元。

Agent 發請求

代理注入 Token

目標服務

OS 級沙箱隔離

三重隔離屏障

檔案系統隔離

Agent 只能存取工作目錄下的檔案，無法讀取宿主機的其他檔案系統路徑。憑證、配置、系統檔案全部不可見。

網路隔離

沙箱限制網路存取範圍，Agent 無法向任意外部服務傳送資料。即使取得了憑證，也無法外傳。

行程隔離

Agent 的程式碼執行在獨立行程空間中，無法存取宿主機的其他行程。既不能讀取其他行程的記憶體，也不能傳送訊號。

三層信任層級

從工具到組織的分層權限控制

TOOL

工具級信任

最細粒度的控制。某些特定工具需要每次使用都經過人工審批，比如檔案刪除、資料庫寫入、傳送郵件等高危操作。對於安全的只讀操作（如搜尋程式碼、讀取檔案），可以設為自動放行。

SESSION

會話級信任

某次對話的權限範圍。使用者在開始會話時授予 Agent 特定範圍的權限（如「可以讀寫 /src 目錄但不能改 /config」），整個會話期間權限範圍保持不變。會話結束後權限自動回收。

GLOBAL

全域級策略

組織級的安全策略限制。無論使用者在會話中授予什麼權限，Agent 都不能違反全域策略，比如「永遠不能存取生產資料庫」「不能向外部域名傳送請求」。這是安全的兜底防線。

結構性安全 > 提示詞安全。設計上讓攻擊不可能，模型自覺靠不住。憑證和執行環境物理隔離、多層信任控制、OS 級沙箱，這些是讓 Agent 在生產環境安全執行的基石。