防護機制與安全層架構
Advanced3 min readUpdated 2026-03-13
防護系統在架構上如何設計，包括前置處理、推論中處理與後置處理層、常見設計模式，以及各層可被繞過之處。
防護系統像多層盔甲圍繞著 LLM。理解其架構——如何組成、資料如何流經、接縫在哪——是系統性繞過的關鍵。
三層架構
幾乎所有生產級防護系統皆遵循三層模式：
┌──────────────────┐
使用者輸入 ───→ │ PRE-PROCESSING │ ──→ 封鎖/放行
│ （輸入防護） │
└────────┬─────────┘
│ （放行）
┌────────▼─────────┐
│ IN-PROCESSING │
│ （模型 + 提示 │ ──→ 生成
│ 約束） │
└────────┬─────────┘
│ （已生成）
┌────────▼─────────┐
│ POST-PROCESSING │ ──→ 封鎖/遮蔽/放行
│ （輸出防護） │
└──────────────────┘
Layer 1：前置處理
前置處理防護於使用者輸入到達模型前加以分析。它們作用於原始文字（或多模態輸入），決定放行、修改或封鎖。
| 防護類型 | 偵測方法 | 延遲 | 涵蓋 |
|---|---|---|---|
| 黑名單/regex | 模式比對 | <1ms | 低——易被規避 |
| ML 分類器 | 已訓練之注入偵測器 | 10–50ms | 中——錯過新穎攻擊 |
| 嵌入相似度 | 與已知攻擊的餘弦距離 | 5–20ms | 中——對換句話敏感 |
| 以 LLM 為基礎之護盾 | 第二個 LLM 評估輸入 | 100–500ms | 高——但昂貴且慢 |
繞過焦點： 編碼、混淆、語意換句、由多部分組成且個別看來無害的 payload。請見輸入/輸出過濾系統。
Layer 2：推論中處理
推論中防禦運作於模型推論期間，屬模型自身行為及其周圍提示工程的一部分。
- 系統提示指令 —— 寫入提示中的行為約束
- 指令階層 —— 訓練模型優先系統指令於使用者輸入之上
- 取樣約束 —— temperature 上限、logit bias、stop 序列
- Token 預算 —— 限制輸出長度以防止大規模外洩
繞過焦點： 提示注入、越獄、上下文操弄。這些攻擊鎖定模型的決策，而非外部過濾。
Layer 3：後置處理
後置處理防護於模型輸出回傳使用者前加以分析。
- 內容分類器 —— 偵測回應中有害內容的 ML 模型
- PII 偵測 —— 攔截個資外洩的 regex 與 NER 模型
- 格式驗證 —— 確保輸出吻合預期綱要（JSON、特定欄位）
- LLM 判官 —— 第二個 LLM 評估回應是否違反政策
繞過焦點： 對輸出編碼（base64、rot13）、以比喻或虛構框架、將有害內容跨多個回應分割、利用分類器的類別缺口。
設計模式
模式 1：順序管線
每個防護依序執行。任一防護封鎖即拒絕請求。
def process_request(user_input: str) -> str:
# Pre-processing
if not input_classifier.is_safe(user_input):
return "I cannot process this request."
if not prompt_shield.check(user_input):
return "I cannot process this request."
# In-processing
response = llm.generate(system_prompt + user_input)
# Post-processing
if not output_classifier.is_safe(response):
return "I cannot provide that information."
response = pii_redactor.redact(response)
return response弱點： 任一前處理層被單點繞過即讓輸入通過。後處理成為僅存防線。
模式 2：並行評估
多個防護同時評估。唯有所有防護一致同意方可進入。
async def process_request(user_input: str) -> str:
# 並行執行所有前置處理防護
results = await asyncio.gather(
input_classifier.is_safe(user_input),
prompt_shield.check(user_input),
embedding_scanner.check(user_input),
)
if not all(results):
return "I cannot process this request."
response = await llm.generate(system_prompt + user_input)
# 並行執行所有後置處理防護
post_results = await asyncio.gather(
output_classifier.is_safe(response),
pii_detector.check(response),
policy_judge.evaluate(response),
)
if not all(post_results):
return "I cannot provide that information."
return response弱點： 所有防護須被同時繞過，但它們常採相似偵測範式。能規避某個 ML 分類器的輸入，通常也能規避其他以相似資料訓練者。
模式 3：分層升級
先跑快速便宜的防護；若初步檢查不明確才跑昂貴者。
def process_request(user_input: str) -> str:
# Tier 1：快速檢查（regex、黑名單）
risk_score = fast_scanner.score(user_input)
if risk_score > HIGH_THRESHOLD:
return block_response()
# Tier 2：ML 分類器（僅於 tier 1 不確定時）
if risk_score > LOW_THRESHOLD:
if not ml_classifier.is_safe(user_input):
return block_response()
# Tier 3：LLM 判官（僅對通過 tier 2 的高風險分數）
if risk_score > MEDIUM_THRESHOLD:
if not llm_judge.approve(user_input):
return block_response()
return llm.generate(system_prompt + user_input)弱點： 分數低於 LOW_THRESHOLD 的輸入完全繞過所有分類。紅隊應打造「看來無趣」、低於 tier 1 的 payload。
同步 vs. 非同步防禦
| 面向 | 同步 | 非同步 |
|---|---|---|
| 運行時機 | 內嵌、阻擋回應 | 回應送出後 |
| 延遲影響 | 增加回應時間 | 無 |
| 可否阻擋輸出 | 可 | 否（僅標記供審查） |
| 紅隊意涵 | 必須繞過才能取得輸出 | 輸出已送達；只需避免被偵測 |
常見架構弱點
- 各端點涵蓋不一 —— 主聊天端點有防護，但 completion 或 function-calling 端點沒有
- 工具呼叫繞過輸出過濾 —— 模型的工具呼叫參數未以與其文字輸出相同方式過濾
- 串流繞過後處理 —— 串流模式下，後處理可能於區塊送達使用者前還未看到完整輸出
- 多模態缺口 —— 文字輸入被過濾，但影像、音訊或檔案輸入未被過濾
- 未追蹤 session 狀態 —— 防護獨立評估每則訊息，錯過多輪升級模式
延伸閱讀
- 輸入/輸出過濾系統 -- 過濾類型與繞過技術的深入解析
- Prompt Shields 與注入偵測 -- 專職的注入偵測系統
- LLM 作為判官的防禦系統 -- 以 LLM 評估其他 LLM
- LLM 應用的縱深防禦 -- 分層防禦策略
相關主題
- 輸入/輸出過濾系統 - 過濾類型與繞過技術的深入解析
- Prompt Shields 與注入偵測 - 專職注入偵測系統
- LLM 作為判官的防禦系統 - 以 LLM 評估其他 LLM
- LLM 應用的縱深防禦 - 分層防禦策略
- AI 防禦地景 - 防禦工具與市場的更廣視角
參考資料
- "NVIDIA NeMo Guardrails: Programmable Safety" - NVIDIA（2024）- 實作基於對話流之安全導軌的開源框架文件
- "Guardrails AI: Output Validation Framework" - Guardrails AI（2025）- LLM 應用之以綱要為基礎的輸出驗證框架
- "LLM Guard: Comprehensive Input/Output Scanning" - ProtectAI（2025）- 實作多層輸入輸出掃描的開源工具組
- "Rebuff: Self-Hardening Prompt Injection Detector" - Rebuff（2024）- 結合啟發式、LLM 與嵌入的多層提示注入偵測
Knowledge Check
在分層升級的防護系統中，最有效的繞過策略為何？