LLM 防禦的對抗性訓練
使用對抗性訓練技術,提升 LLM 對已知攻擊模式的穩健性。
概述
使用對抗性訓練技術,提升 LLM 對已知攻擊模式的穩健性。
本主題代表 AI 安全的關鍵領域,歷經大量研究與真實世界利用。理解本文涵蓋的概念、技術與防禦措施,對從事 AI 安全——無論攻擊或防禦角色——的每位從業者都至關重要。
NeMo Guardrails(NVIDIA)—— 可程式化護欄(github.com/NVIDIA/NeMo-Guardrails)為本文探討之漏洞類別提供基礎背景。
核心概念
基本原則
本主題的安全意涵源自現代語言模型的設計、訓練與部署方式的基本特性。這些並非孤立的實作缺陷,而是不同程度影響所有基於 Transformer 之語言模型的系統性特徵。
在架構層面,語言模型透過相同的注意力與前饋機制處理所有輸入符元,無論其來源或預期權限層級。這意味著系統提示詞、使用者輸入、工具輸出與檢索文件皆在同一表徵空間中競爭模型的注意力。安全邊界因此必須透過應用層控制於外部強制執行,因為模型本身並無原生的信任層級、資料分類或存取控制概念。
理解此基本特性是理解本文所述技術為何有效、以及為何儘管模型安全訓練持續改進仍然有效的關鍵。安全訓練加入行為層,使模型較不傾向遵循明顯有害的指令,但此層在相同架構之上運作,並可被處理合法輸入的相同注意力機制所影響。
技術深入探討
此漏洞類別的底層機制運作於指令遵循能力與來源認證的互動中。在訓練期間,模型學會遵循以特定格式與情境呈現的指令。能以符合模型所學指令遵循模式之格式呈現對抗性內容的攻擊者,可高度可靠地影響模型行為。
from dataclasses import dataclass
from typing import Optional
import json
@dataclass
class SecurityAnalysis:
"""Framework for analyzing security properties of LLM systems."""
target: str
model: str
defenses: list
vulnerabilities: list
def assess_risk(self, attack_type: str) -> dict:
relevant_defenses = [
d for d in self.defenses
if attack_type in d.get("covers", [])
]
likelihood = "high" if not relevant_defenses else "medium"
impact = self._assess_impact(attack_type)
return {
"attack_type": attack_type,
"likelihood": likelihood,
"impact": impact,
"defenses": len(relevant_defenses),
"risk_level": self._calculate_risk(likelihood, impact),
}
def _assess_impact(self, attack_type: str) -> str:
high_impact = ["data_exfiltration", "unauthorized_actions", "privilege_escalation"]
return "high" if attack_type in high_impact else "medium"
def _calculate_risk(self, likelihood: str, impact: str) -> str:
risk_matrix = {
("high", "high"): "critical",
("high", "medium"): "high",
("medium", "high"): "high",
("medium", "medium"): "medium",
}
return risk_matrix.get((likelihood, impact), "medium")
def generate_report(self) -> str:
attacks = ["prompt_injection", "data_exfiltration", "unauthorized_actions"]
assessments = [self.assess_risk(a) for a in attacks]
report = f"# Risk Assessment: {self.target}\n\n"
for assessment in assessments:
report += (
f"## {assessment['attack_type']}\n"
f"- Risk: {assessment['risk_level']}\n"
f"- Likelihood: {assessment['likelihood']}\n"
f"- Impact: {assessment['impact']}\n"
f"- Active defenses: {assessment['defenses']}\n\n"
)
return report攻擊面分析
理解攻擊面對攻擊與防禦工作皆至關重要:
| 攻擊向量 | 進入點 | 典型影響 | 防禦方法 |
|---|---|---|---|
| 直接注入 | 使用者訊息輸入 | 系統提示詞萃取、安全繞過 | 輸入分類 |
| 間接注入 | 外部資料來源(網頁、文件、工具) | 資料外洩、未授權動作 | 資料淨化 |
| 函式呼叫濫用 | 工具參數注入 | 未授權 API 呼叫、資料存取 | 工具沙箱化 |
| 記憶體操弄 | 對話歷史、持久記憶 | 跨會話持久、虛假上下文 | 記憶驗證 |
| 上下文操弄 | 上下文視窗管理 | 指令優先覆寫 | 上下文隔離 |
實務應用
實作方法
將這些概念套用於實務需要系統化方法論:
class PracticalFramework:
"""Practical framework for applying the concepts in this article."""
def __init__(self, target_config: dict):
self.config = target_config
self.findings = []
self.tested_vectors = set()
def test_vector(self, vector: str, payload: str) -> dict:
self.tested_vectors.add(vector)
response = self._send(payload)
finding = {
"vector": vector,
"payload_length": len(payload),
"response_length": len(response),
"success": self._evaluate(response),
"defense_triggered": self._detect_defense(response),
}
if finding["success"]:
self.findings.append(finding)
return finding
def coverage_report(self) -> dict:
all_vectors = {
"direct_injection", "indirect_injection", "function_abuse",
"memory_manipulation", "context_manipulation",
}
return {
"tested": list(self.tested_vectors),
"untested": list(all_vectors - self.tested_vectors),
"coverage": f"{len(self.tested_vectors)/len(all_vectors)*100:.0f}%",
"findings": len(self.findings),
}
def _send(self, payload: str) -> str:
pass
def _evaluate(self, response: str) -> bool:
pass
def _detect_defense(self, response: str) -> Optional[str]:
pass防禦考量
理解防禦措施同等重要:
-
輸入驗證:第一道防線。部署輸入分類器,在進入模型前評估對抗性模式。現代分類器結合關鍵字比對、正規表達式模式與基於 ML 的偵測以達全面覆蓋。
-
輸出過濾:安全網。後處理所有模型輸出,偵測並移除敏感資料外洩、系統提示詞片段及其他政策違規。輸出過濾器應獨立於輸入過濾器以提供縱深防禦。
-
行為監控:偵測層。監控模型互動模式中顯示進行中攻擊的異常——異常請求模式、重複拒絕或偏離基準行為的回應特徵。
-
架構設計:基礎。設計最小化對模型輸出之信任、對工具存取強制最小權限並於元件間維持明確安全邊界的應用架構。
真實世界相關性
這些概念直接適用於各產業的正式 AI 系統。下列因素使本主題特別相關:
- 普遍性:此漏洞類別影響所有主要模型供應商與部署配置
- 影響:成功利用可導致資料外洩、未授權動作與合規違規
- 持久性:底層架構特性確保隨模型演進,這些技術仍然相關
- 法規:新興法規(歐盟 AI 法案、NIST AI RMF)愈來愈要求組織評估並緩解這些風險
當前研究
本領域的活躍研究包括:
- 形式穩健性保證:發展證明模型於有界對抗擾動下行為的數學框架
- 大規模對抗訓練:於安全訓練期間使模型接觸對抗性輸入以提升穩健性的訓練程序
- 可解釋性引導防禦:使用機制性可解釋性於神經元層級理解攻擊為何成功,以啟發針對性防禦
- 標準化評估:HarmBench 與 JailbreakBench 等基準測試,使攻擊與防禦有效性的系統化測量成為可能
實作考量
架構模式
實作與 LLM 互動的系統時,數種架構模式影響整體應用的安全態勢:
閘道模式:專用 API 閘道位於使用者與 LLM 之間,處理認證、速率限制、輸入驗證與輸出過濾。這集中了安全控制但建立單一失效點。
from dataclasses import dataclass
from typing import Optional
import time
@dataclass
class SecurityGateway:
"""Gateway pattern for securing LLM application access."""
input_classifier: object
output_filter: object
rate_limiter: object
audit_logger: object
def process_request(self, user_id: str, message: str, session_id: str) -> dict:
request_id = self._generate_request_id()
if not self.rate_limiter.allow(user_id):
self.audit_logger.log(request_id, "rate_limited", user_id)
return {"error": "Rate limit exceeded", "retry_after": 60}
classification = self.input_classifier.classify(message)
if classification.is_adversarial:
self.audit_logger.log(
request_id, "input_blocked",
user_id, classification.category
)
return {"error": "Request could not be processed"}
response = self._call_llm(message, session_id)
filtered = self.output_filter.filter(response)
if filtered.was_modified:
self.audit_logger.log(
request_id, "output_filtered",
user_id, filtered.reason
)
self.audit_logger.log(
request_id, "completed",
user_id, len(message), len(filtered.content)
)
return {"response": filtered.content}
def _generate_request_id(self) -> str:
import uuid
return str(uuid.uuid4())
def _call_llm(self, message: str, session_id: str) -> str:
passSidecar 模式:安全元件作為獨立服務與 LLM 並行運行,各自負責特定安全面向。這提供更佳隔離與獨立擴展但增加系統複雜度。
Mesh 模式:對多代理系統,每個代理擁有自己的安全周界,具認證、授權與稽核。代理間通訊遵循零信任原則。
效能意涵
安全措施必然增加延遲與運算開銷。理解這些取捨對正式部署至關重要:
| 安全層 | 典型延遲 | 運算成本 | 對 UX 影響 |
|---|---|---|---|
| 關鍵字過濾 | <1ms | 微不足道 | 無 |
| 正規表達式過濾 | 1-5ms | 低 | 無 |
| ML 分類器(小) | 10-50ms | 中 | 最小 |
| ML 分類器(大) | 50-200ms | 高 | 顯著 |
| LLM-as-judge | 500-2000ms | 極高 | 明顯 |
| 完整管線 | 100-500ms | 高 | 中 |
建議方法是先使用快速、輕量的檢查(關鍵字與正規表達式過濾)捕捉明顯攻擊,僅對通過初始過濾的輸入執行較昂貴的 ML 分析。此串聯方法以可接受效能提供良好安全性。
監控與可觀測性
LLM 應用的有效安全監控需要追蹤捕捉對抗行為模式的指標:
from dataclasses import dataclass
from collections import defaultdict
import time
@dataclass
class SecurityMetrics:
"""Track security-relevant metrics for LLM applications."""
total_requests: int = 0
blocked_requests: int = 0
filtered_outputs: int = 0
anomalous_sessions: int = 0
_request_times: list = None
_block_times: list = None
def __post_init__(self):
self._request_times = []
self._block_times = []
def record_request(self, was_blocked: bool = False, was_filtered: bool = False):
now = time.time()
self.total_requests += 1
self._request_times.append(now)
if was_blocked:
self.blocked_requests += 1
self._block_times.append(now)
if was_filtered:
self.filtered_outputs += 1
def get_block_rate(self, window_seconds: int = 300) -> float:
now = time.time()
cutoff = now - window_seconds
recent_requests = sum(1 for t in self._request_times if t > cutoff)
recent_blocks = sum(1 for t in self._block_times if t > cutoff)
if recent_requests == 0:
return 0.0
return recent_blocks / recent_requests
def should_alert(self) -> bool:
block_rate = self.get_block_rate()
if block_rate > 0.3:
return True
return False於 CI/CD 中的安全測試
將 AI 安全測試整合進開發管線,可在到達正式環境前捕捉迴歸:
- 單元層級測試:以已知載荷測試個別安全元件(分類器、過濾器)
- 整合測試:端到端測試完整安全管線
- 迴歸測試:維護先前發現攻擊載荷的測試套件,並驗證仍被阻擋
- 對抗測試:定期執行自動化紅隊工具(Garak、Promptfoo)作為部署管線的一部分
新興趨勢
當前研究方向
LLM 安全領域快速演進。可能形塑版圖的關鍵研究方向包括:
-
LLM 行為的形式驗證:研究者探索證明模型於對抗條件下行為屬性的數學框架。雖然神經網路的完整形式驗證仍難以處理,有界驗證特定屬性顯示前景。
-
LLM 穩健性的對抗訓練:超越標準 RLHF,研究者發展於安全訓練期間使模型明確接觸對抗輸入的訓練程序,提升對已知攻擊模式的穩健性。
-
可解釋性引導防禦:機制性可解釋性研究使防禦方能於神經元與電路層級理解特定攻擊為何成功,啟發更針對性的防禦措施。
-
多代理安全:隨著 LLM 代理更普及,保護代理間通訊並於代理系統間維持信任邊界是具顯著實務意涵的活躍研究領域。
-
大規模自動化紅隊演練:NVIDIA Garak、Microsoft PyRIT 與 UK AISI Inspect 框架等工具使先前不可能規模的自動化安全測試成為可能,但自動化測試的品質與覆蓋仍是開放挑戰。
這些研究方向整合至正式系統將定義下一代 AI 安全實務。
進階考量
演進的攻擊版圖
AI 安全版圖隨著攻擊技術與防禦措施的進展快速演進。數種趨勢形塑目前狀態:
愈增的模型能力製造新攻擊面。隨著模型取得工具、程式碼執行、網頁瀏覽與電腦使用的存取權,每項新能力引入在早期僅文字系統中不存在的潛在利用向量。隨模型能力擴展,最小權限原則愈發重要。
安全訓練改進是必要但不充分的。模型供應商透過 RLHF、DPO、憲法式 AI 與其他對齊技術大量投資安全訓練。這些改進提高成功攻擊的門檻但不消除根本漏洞:模型無法可靠區分合法指令與對抗性內容,因為此區別並未於架構中表徵。
自動化紅隊工具民主化測試。NVIDIA Garak、Microsoft PyRIT 與 Promptfoo 等工具使組織能在無深厚 AI 安全專業下進行自動化安全測試。然而,自動化工具捕捉已知模式;新穎攻擊與業務邏輯漏洞仍需人類創造力與領域知識。
法規壓力驅動組織投資。歐盟 AI 法案、NIST AI RMF 與產業特定法規愈來愈要求組織評估並緩解 AI 特定風險。此法規壓力驅動 AI 安全計畫投資,但許多組織仍處於建立成熟 AI 安全實務的早期階段。
橫跨性安全原則
數項安全原則適用於本課程涵蓋的所有主題:
-
縱深防禦:沒有單一防禦措施足夠。分層多個獨立防禦,使任一層失效不致系統遭破。輸入分類、輸出過濾、行為監控與架構控制皆應存在。
-
假設已被攻破:假設任何個別元件可能被攻破來設計系統。此思維導致更佳隔離、監控與事件回應能力。當提示詞注入成功,透過架構控制將爆炸半徑最小化。
-
最小權限:僅授予模型與代理其預期功能所需的最小能力。客服聊天機器人不需要檔案系統存取或程式碼執行。過多能力放大成功利用的影響。
-
持續測試:AI 安全不是一次性評估。模型變化、防禦演進,新攻擊技術定期被發現。將持續安全測試實施為開發與部署生命週期的一部分。
-
預設安全:預設配置應安全。對風險能力要求明確選擇啟用,使用允許清單而非拒絕清單,傾向限制而非寬鬆。
與組織安全的整合
AI 安全不存在於孤立——它必須與組織更廣泛的安全計畫整合:
| 安全領域 | AI 特定整合 |
|---|---|
| 身分與存取 | API 金鑰管理、模型存取控制、AI 功能的使用者認證 |
| 資料保護 | 訓練資料分類、提示詞中的 PII、模型呼叫的資料駐留 |
| 應用安全 | AI 功能威脅建模、SAST/DAST 中的提示詞注入、安全 AI 設計模式 |
| 事件回應 | AI 特定手冊、模型行為監控、提示詞注入鑑識 |
| 合規 | AI 法規對應(歐盟 AI 法案、NIST)、AI 稽核軌跡、模型文件 |
| 供應鏈 | 模型來源、相依安全、轉接器/權重完整性驗證 |
class OrganizationalIntegration:
"""Framework for integrating AI security with organizational security programs."""
def __init__(self, org_config: dict):
self.config = org_config
self.gaps = []
def assess_maturity(self) -> dict:
domains = {
"governance": self._check_governance(),
"technical_controls": self._check_technical(),
"monitoring": self._check_monitoring(),
"incident_response": self._check_ir(),
"training": self._check_training(),
}
overall = sum(d["score"] for d in domains.values()) / len(domains)
return {"domains": domains, "overall_maturity": round(overall, 1)}
def _check_governance(self) -> dict:
has_policy = self.config.get("ai_security_policy", False)
has_framework = self.config.get("risk_framework", False)
score = (int(has_policy) + int(has_framework)) * 2.5
return {"score": score, "max": 5.0}
def _check_technical(self) -> dict:
controls = ["input_classification", "output_filtering", "rate_limiting", "sandboxing"]
active = sum(1 for c in controls if self.config.get(c, False))
return {"score": active * 1.25, "max": 5.0}
def _check_monitoring(self) -> dict:
has_monitoring = self.config.get("ai_monitoring", False)
has_alerting = self.config.get("ai_alerting", False)
score = (int(has_monitoring) + int(has_alerting)) * 2.5
return {"score": score, "max": 5.0}
def _check_ir(self) -> dict:
has_playbook = self.config.get("ai_ir_playbook", False)
return {"score": 5.0 if has_playbook else 0.0, "max": 5.0}
def _check_training(self) -> dict:
has_training = self.config.get("ai_security_training", False)
return {"score": 5.0 if has_training else 0.0, "max": 5.0}未來方向
數項研究與產業趨勢將形塑本領域的演進:
- AI 安全的形式方法:發展可於對抗條件下提供關於模型行為有界保證的數學框架
- 大規模自動化紅隊演練:持續改進可在無人類引導下發現新穎漏洞的自動化測試工具
- AI 輔助防禦:使用 AI 系統偵測並回應對其他 AI 系統的攻擊,建立動態攻防生態系
- 標準化評估:標準化基準測試(HarmBench、JailbreakBench)的日增採用,使一致的進展測量成為可能
- 法規調和:跨司法轄區之 AI 法規框架的趨同,為組織提供更清晰的要求
參考文獻與延伸閱讀
- OWASP LLM Top 10 2025 —— LLM 安全風險綜合指南 (owasp.org/www-project-top-10-for-large-language-model-applications)
- MITRE ATLAS —— AI 系統對抗威脅版圖 (atlas.mitre.org)
- NeMo Guardrails (NVIDIA) —— 可程式化護欄 (github.com/NVIDIA/NeMo-Guardrails)
- LLM Guard —— 輸入/輸出掃描 (github.com/protectai/llm-guard)
- Anthropic 2025 —— 「憲法式分類器」技術報告
針對本文描述之攻擊類別最有效的防禦策略為何?
為何儘管模型供應商持續改進安全,本文描述的技術仍然有效?