影像隱寫注入
利用隱寫技術將指令或資料嵌入影像,以規避視覺檢查並操弄多模態模型。
概述
利用隱寫技術將指令或資料嵌入影像,以規避視覺檢查並操弄多模態模型。
此主題是 AI 安全中的關鍵領域,已是大量研究與真實世界利用的主題。理解此處涵蓋的概念、技術與防禦措施,對任何從事 AI 安全工作的人——無論擔任攻擊或防禦角色——都是必要的。
Zou et al. 2023 — "Universal and Transferable Adversarial Attacks" (adapted for multimodal) 為本文所探討的漏洞類型提供了基礎脈絡。
核心概念
基本原理
此主題的安全影響源自於現代語言模型的設計、訓練與部署方式所具有的基本性質。這些並非孤立的實作瑕疵,而是影響所有以 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:
"""Assess risk for a specific attack type."""
# Check if any defense addresses this attack type
relevant_defenses = [
d for d in self.defenses
if attack_type in d.get("covers", [])
]
# Risk factors
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:
"""Assess the potential impact of an attack type."""
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:
"""Calculate overall risk from likelihood and impact."""
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:
"""Generate a risk assessment report."""
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:
"""Test a specific attack vector against the target."""
self.tested_vectors.add(vector)
# Send the payload
response = self._send(payload)
# Evaluate the result
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:
"""Report on testing coverage."""
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:
"""Send payload to target (implementation varies by target)."""
pass
def _evaluate(self, response: str) -> bool:
"""Evaluate whether the attack was successful."""
pass
def _detect_defense(self, response: str) -> Optional[str]:
"""Detect which defense mechanism was triggered."""
pass防禦考量
理解防禦措施同樣重要:
-
輸入驗證:第一道防線。部署輸入分類器,在輸入提示詞抵達模型之前評估其是否含有對抗性模式。現代分類器會結合關鍵字比對、正規表達式與基於 ML 的偵測,以達成全面覆蓋。
-
輸出過濾:安全網。對所有模型輸出進行後處理,以偵測並移除敏感資料外洩、系統提示詞片段及其他政策違反情形。輸出過濾器應與輸入過濾器相互獨立,以提供縱深防禦。
-
行為監控:偵測層。監控模型互動模式,找出顯示攻擊正在進行的異常——異常請求模式、重複拒絕,或與基準行為不同的回應特徵。
-
架構設計:基石。設計應用程式架構以最小化對模型輸出的信任,對工具存取執行最小權限原則,並在元件之間維持清楚的安全邊界。
真實世界的關聯
這些概念可直接應用於各產業的正式環境 AI 系統。以下因素使本主題特別重要:
- 普遍性:此類漏洞影響所有主要模型供應商與部署配置
- 影響:成功利用可導致資料暴露、未授權動作與合規違反
- 持續性:底層的架構性質確保這些技術會隨著模型演進而仍保持相關性
- 法規:新興法規 (EU AI Act、NIST AI RMF) 日益要求組織評估並緩解這些風險
目前的研究
此領域的前沿研究包括:
- 形式化穩健性保證:為證明模型在有界對抗擾動下的行為,發展數學框架
- 大規模對抗性訓練:在安全訓練過程中讓模型接觸對抗性輸入,以提升穩健性的訓練流程
- 可解釋性導向的防禦:利用機制可解釋性理解攻擊為何能在神經元層級成功,進而實現針對性的防禦
- 標準化評估:HarmBench、JailbreakBench 等基準測試,能對攻擊與防禦的有效性進行系統化衡量
實作考量
架構模式
在實作與 LLM 互動的系統時,有幾種架構模式會影響整體應用程式的安全態勢:
閘道器模式:在使用者與 LLM 之間設置專用的 API 閘道器,負責認證、速率限制、輸入驗證與輸出過濾。這種設計讓安全控制集中化,但也形成單一故障點。
from dataclasses import dataclass
from typing import Optional
import time
@dataclass
class SecurityGateway:
"""Gateway pattern for securing LLM application access."""
input_classifier: object # ML-based input classifier
output_filter: object # Output content filter
rate_limiter: object # Rate limiting service
audit_logger: object # Audit trail logger
def process_request(self, user_id: str, message: str, session_id: str) -> dict:
"""Process a request through all security layers."""
request_id = self._generate_request_id()
# Layer 1: Rate limiting
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}
# Layer 2: Input classification
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"}
# Layer 3: LLM processing
response = self._call_llm(message, session_id)
# Layer 4: Output filtering
filtered = self.output_filter.filter(response)
if filtered.was_modified:
self.audit_logger.log(
request_id, "output_filtered",
user_id, filtered.reason
)
# Layer 5: Audit logging
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:
# LLM API call implementation
pass邊車 (Sidecar) 模式:安全元件以獨立服務的形式與 LLM 並行運作,各自負責特定的安全面向。這種方式提供更好的隔離與獨立擴展性,但會增加系統複雜度。
網格 (Mesh) 模式:對於多代理系統,每個代理都擁有自己的安全邊界,包含認證、授權與稽核。代理之間的通訊遵循零信任原則。
效能影響
安全措施不可避免地會增加延遲與運算開銷。理解這些取捨對正式環境部署至關重要:
| 安全層 | 典型延遲 | 運算成本 | 對使用者體驗的影響 |
|---|---|---|---|
| 關鍵字過濾 | <1ms | 可忽略 | 無 |
| 正規表達式過濾 | 1-5ms | 低 | 無 |
| ML 分類器 (小型) | 10-50ms | 中等 | 極小 |
| ML 分類器 (大型) | 50-200ms | 高 | 可察覺 |
| LLM 作為裁判 | 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."""
# Counters
total_requests: int = 0
blocked_requests: int = 0
filtered_outputs: int = 0
anomalous_sessions: int = 0
# Rate tracking
_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):
"""Record a request and its disposition."""
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:
"""Calculate the block rate over a time window."""
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:
"""Determine if current metrics warrant an alert."""
block_rate = self.get_block_rate()
# Alert if block rate exceeds threshold
if block_rate > 0.3: # >30% of requests blocked in last 5 min
return True
return FalseCI/CD 中的安全測試
將 AI 安全測試整合到開發流水線中,能在迴歸問題進入正式環境前及早發現:
- 單元層級測試:對照已知載荷測試個別安全元件 (分類器、過濾器)
- 整合測試:端到端測試完整的安全流水線
- 迴歸測試:維護一套先前發現的攻擊載荷,並驗證它們仍被封鎖
- 對抗性測試:定期將自動化紅隊工具 (Garak、Promptfoo) 作為部署流水線的一部分執行
新興趨勢
目前的研究方向
LLM 安全領域正在快速演進。可能形塑未來樣貌的關鍵研究方向包括:
-
LLM 行為的形式化驗證:研究人員正在探索數學框架,用以證明模型在對抗條件下的行為性質。儘管神經網路的完整形式化驗證仍屬難以處理,針對特定性質的有界驗證已展現潛力。
-
LLM 穩健性的對抗性訓練:除了標準的 RLHF,研究人員正在開發在安全訓練過程中明確讓模型接觸對抗性輸入的訓練流程,以提升對已知攻擊模式的抗性。
-
可解釋性導向的防禦:機制可解釋性研究讓防禦方能在神經元與電路層級理解特定攻擊為何能成功,進而推動更具針對性的防禦措施。
-
多代理安全:隨著 LLM 代理日漸普及,保護代理間通訊並在代理系統中維持信任邊界,已成為具有重大實務意義的活躍研究領域。
-
大規模自動化紅隊:NVIDIA 的 Garak、Microsoft 的 PyRIT,以及英國 AISI 的 Inspect 框架等工具,正讓前所未有規模的自動化安全測試成為可能,但自動化測試的品質與覆蓋率仍是尚未解決的挑戰。
將這些研究方向整合到正式環境系統中,將定義下一世代的 AI 安全實務。
進階考量
演進中的攻擊態勢
AI 安全態勢隨著攻防技術的進步而快速演進。以下數項趨勢形塑了目前的樣貌:
**模型能力的擴大會創造新的攻擊面。**隨著模型獲得工具使用、程式碼執行、網頁瀏覽與電腦使用等能力,每一項新能力都帶來早期純文字系統所不存在的潛在利用向量。隨著模型能力擴展,最小權限原則也愈發重要。
**安全訓練的改進必要但不足夠。**模型供應商透過 RLHF、DPO、憲法式 AI 及其他對齊技術大量投資於安全訓練。這些改進提高了成功攻擊的門檻,但並未消除根本漏洞:模型無法可靠地區分合法指令與對抗性指令,因為這種區分並未在架構中被表徵。
**自動化紅隊工具讓測試普及化。**NVIDIA 的 Garak、Microsoft 的 PyRIT、Promptfoo 等工具讓組織不具備深厚 AI 安全專業,也能進行自動化安全測試。然而,自動化工具只能攔截已知模式;新型攻擊與業務邏輯漏洞仍需人類的創造力與領域知識。
**法規壓力推動組織投資。**EU AI Act、NIST AI RMF 及產業特定法規日益要求組織評估並緩解 AI 特有風險。這種法規壓力正在推動 AI 安全計畫的投資,但許多組織仍處於建立成熟 AI 安全實務的早期階段。
跨領域的安全原則
下列安全原則適用於本課程所涵蓋的所有主題:
-
縱深防禦:任何單一防禦措施都不足以應對。層層堆疊多個獨立的防禦,使任何單層的失效都不會導致整個系統遭入侵。輸入分類、輸出過濾、行為監控與架構控制皆應到位。
-
假設已遭入侵:以任何單一元件皆可能被入侵的假設來設計系統。這種心態能帶來更好的隔離、監控與事件回應能力。當提示詞注入成功時,應透過架構控制將影響範圍降到最小。
-
最小權限:僅授予模型與代理完成其預期功能所需的最低能力。客戶服務聊天機器人不需要檔案系統存取或程式碼執行權限。過度的能力會放大成功利用的影響。
-
持續測試:AI 安全並非一次性的評估。模型會變動、防禦會演進、新攻擊技術會定期被發現。應將持續安全測試納入開發與部署生命週期的一部分。
-
預設安全:預設組態應是安全的。對具風險的能力應要求明確啟用,優先使用允許清單而非拒絕清單,並寧可偏向限制而非寬鬆。
與組織安全整合
AI 安全並非孤立存在——必須與組織更廣泛的安全計畫整合:
| 安全領域 | AI 特定整合 |
|---|---|
| 身分與存取 | API 金鑰管理、模型存取控制、AI 功能的使用者認證 |
| 資料保護 | 訓練資料分類、提示詞中的 PII、模型呼叫的資料駐留 |
| 應用程式安全 | AI 功能威脅建模、SAST/DAST 中的提示詞注入、安全 AI 設計模式 |
| 事件回應 | AI 專屬 playbook、模型行為監控、提示詞注入鑑識 |
| 合規 | AI 法規對應 (EU AI Act、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:
"""Assess the organization's AI security maturity."""
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 — Comprehensive guide to LLM security risks (owasp.org/www-project-top-10-for-large-language-model-applications)
- MITRE ATLAS — Adversarial Threat Landscape for AI Systems (atlas.mitre.org)
- Zou et al. 2023 — "Universal and Transferable Adversarial Attacks" (adapted for multimodal)
- Anthropic 2024 — "Many-shot Jailbreaking" technical report
- Inspect AI (UK AISI) — AI safety evaluations (github.com/UKGovernmentBEIS/inspect_ai)
針對本文所述的攻擊類型,最有效的防禦策略是什麼?
為何本文所述技術儘管模型供應商持續進行安全改進,卻仍能保持有效?