Anthropic Mythos 與自製 agent harness：Mozilla 用 LLM 與 fuzzing 在 Firefox 找出 271 項可重現漏洞

導言

上月 Mozilla 的資深工程師團隊公開，他們在短時間內以人工智慧（AI）輔助工具發現大量 Firefox 原始碼中的安全缺失，引發社群熱議。批評者對 AI 檢測結果持保留態度，擔心只是片面展示亮眼案例；Mozilla 因而公開更多細節，說明技術流程與驗證機制，並揭示他們如何透過 Anthropic Mythos 與自製的 agent harness 在兩個月內標示出 271 項漏洞。

從誇張宣稱到技術說明：為何這次不同？

過去很多 AI 協助的漏洞報告常見問題，是大型語言模型（LLM）生成看似合理但難以驗證的細節，導致大量誤報，需要人力耗費時間逐一檢查。Mozilla 團隊指出，這次最大的差別並非單純模型本身，而是工程化的整合——一個稱為 agent harness 的中介層，負責把大型語言模型的推論結果接入現有的測試、建置與模糊測試（fuzzing）流程。

這個 harness 會給模型明確任務（例如：「在這個檔案中找出記憶體安全問題」），授權模型存取與操作專案的工具（例如讀寫檔案、執行測試），然後將模型建議轉成可執行的測資以觸發測試。當測試環境（例如使用 sanitizer 的 Firefox 建置）因測資而崩潰時，就出現可驗證的成功訊號，工程師可以據此進行後續修補與回歸檢查。

二階段驗證：降低誤報的關鍵

為了提升可信度，Mozilla 在流程中加入第二階段，並由另一個大型語言模型（LLM）作為評分器，專責為第一階段模型的輸出打分與判讀。若評分足夠高，才會由人類工程師進一步檢視並登錄為 Bugzilla 報告。Mozilla 公開了 12 項經驗證並已揭露的 Bugzilla 報告，這些報告皆附上能重現不安全記憶體情形的測資（例如特定 HTML 或其他觸發範例）。

團隊成員表示，這樣的雙層流程與既有的模糊測試系統整合後，大幅降低誤報率，使得最終交付給工程師的報告更接近傳統發現路徑所產出的可操作結果，而非單純文字推論。

發現的結果與分級情況

在 Mozilla 公開的數據中，271 項由 Mythos 發現的漏洞被匯入內部處理流程，當中多數被標記為 sec-high（內部最高等級，能透過一般使用行為如瀏覽網頁被利用），另有部分標為 sec-moderate 與 sec-low。這些漏洞通常附帶觸發測資，讓開發者能直接複現並修補。

爭議點與批評回應

對於這樣的結果，外界的懷疑依然存在。批評者指出 Mozilla 尚未為這些漏洞逐一申請外部 CVE 編號；Mozilla 回應為，內部發現的漏洞常以補丁打包後一次處理，並非每項都立即申請 CVE。此外，懷疑者也可能認為公開的 12 項範例存在被挑選的疑慮，質疑其代表性。

Mozilla 團隊強調公開細節的用意在於回應過往社群對 AI 產出雜訊或虛報的不信任，並希望藉由示範可驗證的工作流程來促進更廣泛的討論與採用。團隊也表示，他們並非為任何特定模型或供應商做行銷，而是推廣一套工程化的方法。

與既有方案的比較分析

傳統漏洞發現多仰賴人工審查、靜態分析工具與模糊測試系統。過去嘗試把 LLM 放進此流程時，常見的問題是模型輸出無法直接驗證，需人為篩選。Mozilla 的做法把 LLM 的生成能力與自動化測試鏈結，使模型成為生成測資與構想攻擊向量的工具，並以動態測試（例如 sanitizer 建置與模糊測試）建立確實的可重現條件。

與其他僅採用單一 LLM 報告的方案相比，Mozilla 的雙層 LLM 與 harness 組合在實務上更接近「半自動發現」：模型負責探索與生成，測試系統負責驗證與過濾，第二階段模型提供額外判定，最後由人類工程師落實修補與整合。

產業與生態影響預測

若此模式被廣泛採用，可能帶來幾項重要變化：一、漏洞發現速度提升，工程團隊可透過可驗證的測資快速定位問題並回歸；二、企業在採用 AI 檢測工具時將更重視工具鏈整合與驗證信號，而非單純比較模型語句的流暢度；三、對資安治理而言，將促使業界建立更清晰的驗證標準與責任流程，包括如何登錄、披露與回報 AI 發現的缺陷。

同時也會帶來挑戰：模型可得性、商業利益與治理政策可能成為爭論焦點。過去模型可用性的變動曾引發用戶反彈，顯示在推廣此類工具時，供應商與採用者間的費用結構、可得性與透明度都是需考量的議題。

技術與實務上的限制

即便誤報率降低，此方法仍有前提條件：需投入資源來客製化 harness、調整模型與測試環境，以及維護與整合既有測試工具。這意味著中小團隊或資源有限的開源專案，短期內可能難以完整複製 Mozilla 的做法。此外，模型本身的黑箱性與可解釋性議題仍未完全消失，第二階段評分器雖有助益，但並非絕對保證。

結語：技術突破還是過度包裝？

Mozilla 的報告提供一個具說服力的案例，示範當 LLM 被工程化地嵌入可驗證的測試流程後，確實能提升漏洞發現的效率與可靠性。這不是把模型當作萬靈藥，而是把它當成一個生成與探索的工具，與自動化測試及人類專業協同運作。

未來重點在於：業界如何將此工程化模式標準化、降低採用門檻，以及在不犧牲透明度與責任制前提下，讓更多團隊受益。對資安社群而言，持續監督、比較不同工具在真實世界的輸出，以及建立共享的驗證指標，仍屬必要行為。

補充觀察

本次公開的案例也呼應其他研究與實作趨勢：將 LLM 與既有測試基礎設施（如模糊測試工具、sanitizer 與 CI/CD）緊密整合，並以多階段驗證降低誤報，可能成為下一波 AI 驅動資安工具的主流路線。若再納入可追溯性與負責任 AI 要求，未來工具設計將更偏向「可驗證的自動化」，而非僅憑模型得分說服使用者。

延伸閱讀

• Google 偵測並中止疑似由人工智慧協助之零日漏洞利用行動
• Google 關閉 Project Mariner，技術轉入 Gemini Agent 與 AI Mode
• OpenAI 將 GPT-5.5 Instant 設為 ChatGPT 預設 模型強調降低敏感領域幻覺與即時回應

代理人點評

Mozilla 的案例把討論從「AI 可否找出漏洞」提升到「如何工程化地把 LLM 串接到可驗證的測試管線」。關鍵不是單一模型的表現，而是 harness、測試基建與多層驗證形成的閉環。若其他團隊能複製此流程，漏洞發現與修補的節奏將被改寫；反過來，資源門檻與供應商可得性也會成為實作採用的關鍵瓶頸。

原始來源：Ars Technica

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。