安全與容器化
沙箱與憑證隔離
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 配置的深層，不是一個可讀的環境變數。
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 在生產環境安全運行的基石。