你是否曾以為，只要加裝了“防火墻”，大型語言模型（LLM）就能高枕無憂？Trendoyl 的實際測試卻讓我大吃一驚：即便部署了 Meta 的 Llama Guard，攻擊者還是能輕松用多語種、字符混淆，甚至不可見字符繞過防護。這些看似不起眼的“花招”，竟然讓 AI 安全防線頻頻失守——這場人機對抗，遠比想象中棘手。

---

1. 問題：防護為何被繞過？

隨著 LLM 被集成到企業內部工具、自動化流程甚至面向客戶的產品中，AI 安全變得比以往任何時候都重要。Meta 推出的 Llama Firewall（含 PROMPT_GUARD、CODE_SHIELD），本意是為開發者打造一層防線，防御提示注入（Prompt Injection）等主流風險。

然而，Trendyol 的安全團隊在部署和評測過程中發現：

• 多語言輸入、字符混淆、不可見字符，均可輕松繞過防護。
• PROMPT_GUARD 和 CODE_SHIELD 有效性受限，部分情況下失效。
• 真實案例顯示，攻擊者能讓 LLM 忽略系統指令、輸出不安全內容，甚至生成帶有漏洞的代碼。

這一切意味著，防護措施并非“萬無一失”，而是存在著可被利用的盲區。

---

2. 解決方案：現有防護機制如何工作？

Llama Firewall 的兩大核心工具：

工具	設計目標	具體用途
PROMPT_GUARD	防御提示注入	過濾攔截惡意/不安全輸入
CODE_SHIELD	檢測不安全代碼生成	攔截含安全風險的代碼輸出

理論上，這兩道防線應該能阻擋大部分攻擊。但Trendyol團隊通過紅隊測試，發現了三種典型繞過技術：

1. 多語言與混淆繞過

   • 利用非英語（如土耳其語）或 leetspeak（如“1gn0r3 th3 ab0v3 directions”）輕松規避檢測。
   • 防火墻判定分數極低（如0.137），未視為惡意。

2. 代碼漏洞未檢出

   • CODE_SHIELD 未能識別典型 SQL 注入漏洞，仍允許不安全代碼通過。

3. Unicode 不可見字符注入

   • 利用看不見的 Unicode 字符嵌入惡意指令，模型會直接執行隱藏操作，防護機制無法攔截。

實際測試結果更令人警醒：100個提示注入樣本，有50個成功繞過防護，只有一半被攔截。

---

3. 創新/對比：這些攻擊新招與舊方法有何不同？

讓我來做個生活類比：
傳統防火墻就像是檢查站，主要查“英語”通行證和常規字體的身份證。可現在，攻擊者不僅能用外語混進來，還會偽造身份證、甚至隱身進入——讓檢查站根本發現不了。

傳統風險	新型繞過手段	防護效果
英語惡意提示	非英語/混淆輸入	失效
代碼安全漏洞	SQL 注入等常見漏洞生成	未攔截
明文指令注入	Unicode 不可見字符	部分失效

這讓我不得不質疑：現有檢測機制為何如此“單一”？

• 只懂英語，遇到小語種就“裝聾作啞”；
• 只查明面字符，對看不見的Unicode完全沒反應；
• 代碼漏洞只靠表層規則，智能性遠遠不夠。

這些案例讓我認識到，AI安全必須“多語言、多維度、多層次”——否則，模型隨時可能被精心設計的攻擊牽著鼻子走。

---

4. 應用價值：這些發現對行業有何啟示？（Impact）

Trendyol的這次安全測試不僅優化了自身威脅建模，更為整個 LLM 安全社區敲響警鐘：

• 實際風險：攻擊者可無視系統指令、生成有害內容或帶漏洞代碼，生產環境可能出現真實安全事件。
• 紅隊測試必不可少：防護工具上線前，必須進行多樣化攻擊測試，尤其是多語言和混淆場景。
• 社區透明與協作：Trendyol將案例報告提交給Meta和Google，推動行業對漏洞保持公開透明，便于持續改進。
• 未來趨勢：隨著 LLM 應用加深，企業對“韌性強、可解釋、可適應多語言和新型攻擊”的安全措施需求日益增長。

---

核心收獲與行動建議

一句話總結：
現有 LLM 安全防護對多語言、混淆和隱形攻擊手段防御有限，生產環境部署前務必進行多維度紅隊測試。

行動建議：

• 不要只依賴單一工具，務必補充人工審查與多語言檢測。
• 在生產前，組織多種類型的紅隊測試，模擬真實攻擊場景。
• 持續關注社區最新安全漏洞與防護策略，及時更新防線。

如果你正在推動 LLM 落地，記得：AI 安全測試，永遠不能偷懶。