代理框架安全
對主要 AI 代理框架的安全分析,包含 LangChain、CrewAI、AutoGen、Semantic Kernel 與 OpenAI Assistants,涵蓋預設組態、常見漏洞,以及各框架特有的攻擊面。
代理框架安全
代理框架把建構 AI 代理的複雜度抽象掉——工具註冊、記憶管理、對話流程與多步推理。這層抽象是一把雙面刃:框架讓你很容易建構出強大的代理,但同樣也很容易建構出不安全的代理。預設組態優先考量開發者體驗而非安全;社群貢獻的元件鮮少經過稽核;而框架本身的漏洞會傳遞到每一個構築其上的應用程式。
框架地景
截至 2026 年初的主要代理框架:
| 框架 | 維護者 | 主要使用情境 | 代理模式 |
|---|---|---|---|
| LangChain / LangGraph | LangChain Inc. | 通用代理開發 | Chain、graph、ReAct agents |
| CrewAI | CrewAI Inc. | 多代理協作 | 角色式 crew 並支援任務委派 |
| AutoGen | Microsoft | 多代理對話 | 可對話代理搭配群組聊天 |
| Semantic Kernel | Microsoft | 企業 AI 整合 | 以外掛為基礎並搭配規劃器 |
| OpenAI Assistants | OpenAI | 代管型代理部署 | 託管助理搭配代管狀態 |
各框架共通的安全問題
儘管在架構上有所差異,所有主要框架都共享若干一再出現的安全問題:
1. 危險的預設組態
各框架都附帶以快速上手為優先、而非以安全為優先的預設值:
| 框架 | 危險的預設 | 影響 |
|---|---|---|
| LangChain | PythonREPLTool 可用但無沙箱 | 在主機上任意執行程式碼 |
| CrewAI | 代理可委派任務給任何其他代理 | 代理之間不受控的橫向移動 |
| AutoGen | code_execution_config 啟用本機程式碼執行 | 沙箱若未妥善設定即可能逃脫 |
| Semantic Kernel | 自動呼叫模式不需確認就呼叫函式 | 敏感操作沒有人工把關 |
| OpenAI Assistants | Code Interpreter 預設具有網路存取權 | 透過程式碼執行外洩資料 |
2. 對工具輸出的隱性信任
沒有任何主要框架預設把工具輸出視為不可信任。當工具回傳資料時,那些資料以與系統指令相同的優先序進入代理的脈絡。這是所有框架中「混淆的代理人(confused deputy)」漏洞的根本原因。
3. 未經稽核的社群元件
LangChain 有超過 800 個社群整合。CrewAI 也有持續成長的工具市集。這些元件鮮少經過安全稽核:
- 社群工具可能執行任意程式碼、發出網路請求或存取檔案系統
- 工具描述(模型會把它讀作指令)可能包含無意間或惡意的注入內容
- 社群工具的相依套件可能引入供應鏈漏洞
4. 沒有存取控制的記憶
所有支援記憶的框架(LangChain、CrewAI、AutoGen、Semantic Kernel)都會儲存對話歷史與習得的偏好,卻沒有細緻的存取控制。並沒有任何標準機制可用於:
- 區分系統層級與使用者層級的記憶
- 防止工具輸出被儲存為記憶
- 加密敏感的記憶內容
- 在多租戶部署中強制使用者之間的記憶隔離
各框架特有的漏洞
LangChain / LangGraph
LangChain 廣泛的抽象層造就了龐大的攻擊面。關鍵的擔憂包括:
- Chain 組合攻擊 —— 在元件之間直接傳遞輸出而不淨化的 chain
- 回呼利用 —— 自訂的回呼會在每一次代理動作上執行,包含工具呼叫
- Hub 提示風險 —— LangChain Hub 上的提示是社群貢獻,可能含有注入內容
- Agent executor 無限迴圈 —— 預設的
max_iterations偏高,可能導致資源耗盡
詳細分析見 LangChain 安全深入剖析。
CrewAI 與 AutoGen
多代理框架引入了代理間的攻擊面:
- 角色操弄 —— 定義了角色的代理仍可能被說服去做角色之外的事
- 代理間注入 —— Agent A 的輸出就是 Agent B 的輸入,形成注入鏈
- 委派濫用 —— 階層式的委派可被利用為權限升級
詳細分析見 CrewAI 與 AutoGen 安全。
OpenAI Assistants
這個代管平台有其獨有的考量:
- 檔案搜尋利用 —— 上傳的檔案可能含有注入酬載
- Code Interpreter 濫用 —— 雖在沙箱中,仍能進行資料處理與外洩
- 執行緒注入 —— 對執行緒新增訊息可能污染脈絡
詳細分析見 OpenAI Assistants API 安全。
Semantic Kernel
聚焦於企業,但並非毫無風險:
- 外掛信任模型 —— 所有已註冊的外掛被同等地信任
- 規劃器操弄 —— AI 規劃器可被引導,以非預期的順序呼叫外掛
- 連接器利用 —— 資料庫與 API 連接器會原封不動地傳遞模型生成的查詢
評估方法論
辨識框架與版本
判定使用的是哪個(或哪些)框架,以及其確切版本。檢查該版本是否有已知的 CVE 與安全公告。
稽核預設組態
對照框架的預設值審查代理的組態。辨識任何未被覆寫的危險預設(程式碼執行、未限制的工具存取、開放式委派)。
列舉已註冊的工具與元件
列出所有註冊給代理的工具、外掛、chain 或整合。辨識哪些來自社群、哪些來自原廠。對工具描述進行注入內容稽核。
測試工具輸出處理
透過工具結果注入對抗性內容,觀察代理是否會遵循被注入的指令。這檢驗框架(缺乏)輸出淨化的程度。
測試記憶隔離
如果應用是多租戶,測試一個使用者的記憶是否能被另一個使用者存取。測試工具輸出是否會未經淨化即被儲存到記憶中。
測試各框架特有的攻擊面
套用框架特定的測試:LangChain 的 chain 組合、CrewAI/AutoGen 的代理間注入、OpenAI Assistants 的檔案搜尋投毒。
依安全需求選擇框架
各框架安全功能的詳細比較,見 安全比較表。
相關主題
- LangChain 安全深入剖析 —— LangChain 漏洞詳細分析
- CrewAI 與 AutoGen 安全 —— 多代理框架安全
- OpenAI Assistants API 安全 —— 代管平台安全
- 安全比較表 —— 各框架並列比較
- 函式呼叫利用 —— 適用於所有框架的工具呼叫攻擊
多個代理框架之間共享、最危險的預設組態模式是什麼?
參考資料
- LangChain Security Documentation (2025)
- Microsoft AutoGen Security Considerations (2024)
- OpenAI Assistants API Documentation (2025)
- OWASP Top 10 for LLM Applications v2.0
- CrewAI Documentation (2025)