CaMeL 與雙 LLM 模式

分離可信與不可信處理的架構式防禦模式:Simon Willison 的雙 LLM 概念與 Google DeepMind 的 CaMeL 框架,用於防禦使用工具的 AI 代理免於提示詞注入。

隨著 AI 系統從簡單聊天機器人演進為使用工具的代理,提示詞注入威脅模型發生了根本變化。會產生有害文字的聊天機器人令人憂心;但會執行有害動作的代理——發送電子郵件、修改資料庫、執行程式碼——則是危險的。雙 LLM 模式及其在 CaMeL 中的形式化,代表了對此問題的架構式方法:與其嘗試使單一模型對所有攻擊都穩健,不如將系統拆分為具有不同信任層級的元件。

問題:代理式系統中的提示詞注入

為何代理有所不同

對聊天機器人的傳統提示詞注入主要是內容安全問題——攻擊者試圖使模型說出不該說的內容。對使用工具的代理而言,提示詞注入成為動作安全問題:

單一模型問題

在標準代理式架構中,單一 LLM 處理一切:

使用者輸入 + 工具輸出 → [單一 LLM] → 文字回應 + 工具呼叫

此 LLM 同時處理可信指令(來自開發者/使用者)與不可信內容(來自工具輸出、檢索文件、網頁)。若不可信內容含有提示詞注入,LLM 可能將其視為指令並執行惡意工具呼叫。

Simon Willison 的雙 LLM 概念

起源與動機

AI 安全社群重要聲音 Simon Willison 於 2023 年起一系列部落格文章中闡述了雙 LLM 概念。他的核心論點是:對使用工具之 LLM 的提示詞注入,無法透過更好的提示詞或更多安全訓練來解決,它需要架構上的解方。

兩個元件

雙 LLM 模式將系統拆為兩個不同元件:

運作方式

1. 1

   使用者發送請求

   使用者訊息送至擁有系統提示詞、工具與權限的特權 LLM。

2. 2

   特權 LLM 決定使用工具

   根據使用者請求與系統提示詞,特權 LLM 決定呼叫工具——例如搜尋網頁或讀取文件。

3. 3

   工具傳回不可信內容

   工具輸出(網頁、文件內容、API 回應)可能受攻擊者控制並含有提示詞注入。

4. 4

   隔離 LLM 處理不可信內容

   工具輸出送至隔離 LLM——一個獨立模型實例,無工具存取且不知系統提示詞。它只能摘要、萃取或回答有關內容的問題。

5. 5

   淨化後輸出返回特權 LLM

   隔離 LLM 的摘要/萃取返回特權 LLM。即使原始內容含有提示詞注入,隔離 LLM 在無工具存取下處理,注入毫無效果。

6. 6

   特權 LLM 繼續處理

   特權 LLM 使用淨化後資訊繼續任務、進一步呼叫工具或回應使用者。

安全邊界

關鍵安全屬性是兩個 LLM 之間的信任邊界:

┌─────────────────────────────────────────────────┐
│  特權區                                           │
│  ┌───────────────┐     ┌──────────────────┐     │
│  │ 特權 LLM      │────→│  工具 / 動作       │     │
│  │ (僅可信輸入)   │     │  (發送郵件、      │     │
│  │                │     │   執行程式碼等)   │     │
│  └───────┬───────┘     └──────────────────┘     │
│          │                                       │
│          │ 請求摘要                              │
│          │ 不可信內容                            │
│          ↓                                       │
│  ┌───────────────┐                               │
│  │ 隔離          │  ← 無工具存取                 │
│  │ LLM           │  ← 無系統提示詞               │
│  │ (處理          │  ← 無動作能力                 │
│  │  不可信        │                               │
│  │  內容)         │                               │
│  └───────────────┘                               │
└─────────────────────────────────────────────────┘

即使隔離 LLM 被注入內容完全「越獄」,由於它沒有工具、沒有權限,也不知系統能力,它也無法造成傷害。

Google DeepMind 的 CaMeL 框架

從概念到框架

2025 年,Google DeepMind 發表CaMeL(CApabilities for MachinE Learning),將雙 LLM 概念形式化並擴展為代理式系統的完整安全框架。

超越雙 LLM 的關鍵創新

CaMeL 加入多項 Willison 原概念未完整指明的重要機制:

CaMeL 架構

CaMeL 引入了具多個元件的更結構化架構:

可信控制器

較小、較簡單的模型(甚至基於規則的邏輯),作為系統的安全核心:

不可信處理器

處理複雜推理與使用者互動之較大、較強的模型:

資料流與污點追蹤

CaMeL 最重要的貢獻之一是 LLM 系統的污點追蹤:

1. 1

   資料進入系統

   所有傳入資料均被標記:使用者輸入與系統提示詞為「可信」,工具輸出與檢索文件為「污染」。

2. 2

   處理保留污點

   當 LLM 處理污染資料並產生輸出時,該輸出亦標記為污染。污點在系統中傳播。

3. 3

   工具呼叫檢查污點

   當 LLM 提出工具呼叫時,控制器檢查任何引數是否源自污染資料。

4. 4

   政策決定動作

   政策指定哪些工具呼叫允許使用污染資料。例如:「搜尋工具可以污染引數呼叫,但 send_email 工具不行。」

架構比較

雙 LLM vs. CaMeL vs. 傳統

架構式方法的優勢

安全屬性

雙 LLM / CaMeL 方法提供的安全屬性是任何模型訓練都無法保證的:

1. 架構隔離:不可信處理元件實質上無法執行特權動作,不論其被攻破的程度
2. 縱深防禦:即使某一元件失效,系統安全也不會完全崩潰
3. 可稽核性:所有工具呼叫均經控制器,建立清晰稽核軌跡
4. 最小權限原則:每個元件僅擁有所需權限

為何僅訓練不足夠

限制與實務考量

這些模式「未」解決的問題

實務部署挑戰

準確性與安全性的取捨

CaMeL 的形式政策建立硬邊界:若工具呼叫違反政策則被阻擋。這與安全訓練的機率本質不同,後者的拒絕基於模型判斷。硬邊界較安全但較不彈性:

紅隊意涵

攻擊雙 LLM / CaMeL 系統

對紅隊而言,這些架構轉移了攻擊面:

具體攻擊策略

1. 信任邊界混淆:找出系統誤分類為可信、實則為攻擊者控制的輸入
2. 污點洗白:找出系統中污染資料失去污點標籤的路徑,允許在特權操作中使用
3. 控制器繞過:若控制器為較簡單模型,可能有自身漏洞——測試控制器是否可被混淆或淹沒
4. 政策缺口:測試有害但未被政策涵蓋的動作——列舉允許動作(允許清單)的政策較列舉封鎖動作(封鎖清單)更安全
5. 側通道利用:即使無直接工具存取,隔離 LLM 的輸出(內容、長度或結構)可能被特權 LLM 以攻擊者可影響的方式使用
6. 跨元件混淆:打造使特權與隔離 LLM 對情境理解不一致的輸入,可能導致不正確決定

實作模式

最簡雙 LLM 實作

對想要採用雙 LLM 模式但不採用完整 CaMeL 框架的團隊,最簡可行實作包括:

1. 兩個獨立模型實例(或 API 呼叫)——一個用於特權處理,一個用於隔離處理
2. 工具呼叫路由——只有特權實例可執行工具呼叫
3. 內容路由——所有不可信內容先由隔離實例處理再傳給特權實例
4. 基本政策——至少在請求涉及不可信來源內容時,對高衝擊動作要求使用者確認

完整 CaMeL 實作

完整 CaMeL 實作另需:

1. 污點追蹤系統——標記並在資料流中傳播信任標籤
2. 政策引擎——允許使用污染/不可信資料之工具呼叫的形式規格
3. 控制器模型——授權工具呼叫的獨立模型(或規則引擎)
4. 稽核日誌——記錄所有工具呼叫提案、核准與拒絕

目前採用與未來方向

採用狀態(截至 2026 年初)

未來方向

隨著 AI 代理能力提升並更廣泛部署,雙 LLM / CaMeL 模式將愈發重要。關鍵趨勢:

• 代理框架內建信任邊界支援
• 標準化政策語言用於指定代理權限
• 硬體層級隔離可信元件(類比 TEE/安全飛地)
• 代理安全屬性的形式驗證

延伸閱讀

• 進階防禦技術 —— 更廣泛的防禦方法調查,包括指令階層與表徵工程
• 憲法式分類器 —— 使用獨立分類器的互補防禦
• 護欄與安全層架構 —— 雙 LLM / CaMeL 在整體安全架構中的位置
• 對齊偽裝 —— 為何架構式防禦可能比依賴模型對齊更可靠

相關主題

• 護欄與安全層架構 - 這些模式擴展的安全層架構
• 電腦使用代理安全 - 這些防禦最相關的代理安全脈絡
• AI 驅動的紅隊演練 - 代理安全的自動化測試方法

參考文獻

• "Dual LLM pattern for building AI assistants that can resist prompt injection" - Willison, S. (2023) - 闡述雙 LLM 概念及其安全理由的原始部落格文章
• "CaMeL: CApabilities for MachinE Learning" - Google DeepMind (2025) - 以污點追蹤與基於能力之安全性將雙 LLM 模式形式化的研究論文
• "Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection" - Greshake, K., et al. (2023) - 間接提示詞注入的基礎研究,促成架構式防禦
• "The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions" - Wallace, E., et al., OpenAI (2024) - 基於訓練的指令優先方法,與架構隔離互補