不對稱問題：AI安全措施主要給好人添麻煩

HuggingFace最近披露的一起安全事件，生動地展示了AI安全護欄在實際應用中的尷尬處境。當該團隊試圖利用AI輔助工具進行日誌取證分析時，他們首先嚐試了透過商業API訪問的頂尖模型，但很快便碰壁——因為分析過程需要提交大量的真實攻擊命令、利用載荷和C2元件，而這些請求紛紛被提供商的“安全護欄”攔截，因為這些護欄無法區分事件響應人員和真正的攻擊者。

無奈之下，HuggingFace轉而使用開源模型GLM 5.2，部署在自己的基礎設施上完成了取證工作。這一選擇無意中帶來了另一個好處：攻擊者資料及其涉及的憑據都沒有離開自己的環境。這一經歷揭示了一個值得提前規劃的巨大差距：攻擊者的小型模型既可能是透過越獄方式呼叫的託管模型，也可能是不受限制的開源模型；無論如何，攻擊者不受任何使用政策的約束，而防禦方的工作卻被託管模型的護欄所阻礙。

這並非首次在實際事件中遇到這一問題。研究還發現，攻擊者開始利用程式碼注入偽造的系統指令和觸發策略的內容，試圖擾亂自動化的AI輔助分析。例如，一個名為_index.js的有效載荷開頭包含了一大段JavaScript塊註釋，其中包含了虛假的系統指令和策略觸發內容。由於這些內容位於註釋內，不會影響JavaScript執行——直譯器會直接跳過。真正的惡意程式碼位於註釋之後，是一個包含大量字元編碼陣列和類ROT替換函式的try{eval(...)}包裝。

這種設計明確針對的是透過AI進行程式碼分析的工具：它透過給語言模型投餵看似敏感的內容，導致弱防護管線在到達真正惡意程式碼之前就產生拒絕行為、提示混淆、上下文汙染或過早分類。當然，這並非能神奇地繞過所有靜態檢測——YARA規則、熵檢測、抽象語法樹解析、字串提取、反混淆和行為規則依舊有效——但對於那些依賴LLM進行初步三分類的輕量級系統來說，這確實是一種實用的反分析技巧。

迄今為止，並沒有完美的解決方案。這些安全護欄確實能篩掉最明顯的惡意流量，迫使攻擊者付出更多努力。但這一現象並非LLM護欄所獨有：如同我們有子彈主機託管商、反作弊繞過、DRM移除工具、自動驗證碼解決器和地下0day經銷商一樣，未來也會出現未經審查的LLM提供商。這些工具人人都能獲取，但好人通常因為守法而無法使用，而網路犯罪分子則早已不在乎這些法律限制了。