為了防御提示詞注入攻擊(prompt injection)，許多LLM都配備了防護欄，這些防護欄負責檢查和過濾輸入的提示詞，然而，這些防護欄本身通常也是基于AI的分類器，正如Mindgard的研究所示，它們在某些類型的攻擊面前同樣脆弱。

防護欄被譽為LLM的關鍵防御手段。從你的角度來看，關于防護欄在實際應用中的有效性，最大的誤解是什么?

如果退一步問任何安全專家：“我會放心地依賴Web應用防火墻(WAF)作為保護企業的唯一關鍵防御手段嗎?”答案(希望如此)將是否定的。防護欄的作用類似于防火墻，試圖檢測和阻止惡意提示詞。盡管它們是防御體系的一部分，但確保有效的防御需要部署的不僅僅是單一解決方案，另一方面，一個常見的誤解是，它們在面對稍微有動力的攻擊者時仍然有效。

防護欄使用AI模型進行檢測，而這些模型本身存在盲點。阻止“明顯”的惡意或有害指令是一回事，但當提示詞可以以極其多種組合方式(改變字母、單詞、改寫等)編寫時，人類可能能夠理解，但防護欄卻難以應對。

研究表明，使用表情符號和Unicode隱藏(smuggling)等簡單技術，繞過防護欄的成功率接近100%。為什么這些基本方法對那些本應檢測操縱行為的系統如此有效?

表情符號和Unicode標簽隱藏技術之所以如此有效，是因為它們利用了防護欄自然語言處理(NLP)管道中預處理和標記化階段的弱點。防護欄系統依賴于標記器將輸入文本分割并編碼為離散單元，以便模型進行分類，然而，當對抗性內容嵌入到復雜的Unicode結構中(如表情符號變化選擇器或標簽序列)時，標記器往往無法保留嵌入的語義。

例如，當文本被注入到表情符號的元數據中或使用Unicode標簽修飾符附加時，標記器可能會將序列折疊成一個單一的、無害的標記，或者完全丟棄它。結果，嵌入的內容從未以原始形式到達分類器，這意味著模型看到的是一個經過凈化的輸入，不再代表實際的提示詞，這導致了系統性的誤分類。

這些失敗并不一定是標記器中的錯誤，而是設計上的權衡，優先考慮了規范化和效率而非對抗性魯棒性。標準標記器并非為解釋或保留對抗性構造的Unicode序列中的語義意義而構建。除非防護欄融入了專門設計用于檢測或解包這些編碼的預處理層，否則它們仍然對嵌入的有效載荷視而不見。這凸顯了攻擊者編碼意義的方式與分類器處理它的方式之間的根本差距。

在對抗性機器學習中，擾動被設計為對人類來說不可察覺。這是否為開發可解釋或可理解的防御手段帶來了獨特的挑戰?

不可察覺的擾動確實為開發可解釋的防御手段帶來了獨特的挑戰。AI模型對數據的解釋方式與人類完全不同，對我們來說不會改變內容上下文或語義意義的擾動，可能會極大地改變AI模型的決策。這種脫節使得解釋為什么模型會無法分類我們憑直覺就能理解的文本變得困難。這種脫節反過來又降低了開發者基于對抗性擾動改進防御手段的有效性。

論文指出，防護欄檢測的內容與LLM理解的內容之間存在脫節。安全團隊應如何解決這種行為和訓練數據之間的根本不匹配?

核心問題在于，大多數防護欄都是作為獨立的NLP分類器實現的——通常是經過微調的輕量級模型，訓練數據經過精心挑選——而它們旨在保護的LLM則是在更廣泛、更多樣化的語料庫上訓練的。這導致了防護欄標記的內容與LLM如何解釋輸入之間的不匹配。我們的研究結果表明，經過Unicode、表情符號或對抗性擾動混淆的提示詞可以繞過分類器，但仍然可以被LLM解析和執行。當防護欄靜默失敗，允許語義完整的對抗性輸入通過時，這尤其成問題。

即使是新興的基于LLM的評估者，盡管前景看好，也受到類似限制。除非明確訓練以檢測對抗性操縱，并在具有代表性的威脅環境中進行評估，否則它們可能會繼承相同的盲點。

為了解決這個問題，安全團隊應超越靜態分類，實施動態、基于反饋的防御手段。防護欄應在實際LLM和應用接口存在的系統中進行測試。對輸入和輸出的運行時監控對于檢測行為偏差和新興攻擊模式至關重要。此外，將對抗性訓練和持續的紅隊演練納入開發周期，有助于在部署前暴露和修補弱點。如果沒有這種對齊，組織就可能部署提供虛假安全感的防護欄。

你認為LLM防護欄研究接下來應該朝哪個方向發展，特別是在期待更強大、多模態或自主模型的情況下?

當與其他防御策略和技術結合使用時，LLM防護欄可以最為有效，因此研究防護欄如何增強實際AI應用的整體防御姿態將是有益的。威脅建模是創建合適防御手段的關鍵，我們建議將建模的威脅直接映射到應用場景和防護欄配置/重點上。

我們觀察到，該領域的大量研究都是針對一組廣泛(且相當通用)的基準來評估模型的。雖然基準測試是確保防護欄之間更公平評估的好方法，但如果防護欄是在實際AI應用場景中針對有動機的攻擊者設計的、部署的和評估的，這些攻擊者旨在展示有意義的利用并利用更復雜的技術繞過檢測，那么該領域的研究將得到改進。