AI 紅隊工具清單 2026：18 個框架、掃描器與測試基準

「AI 紅隊工具」常被誤解成一張可以照排名安裝的清單。實際上，模型掃描器、攻擊編排框架、評估基準、護欄與治理框架解決的是不同問題；把它們混在一起，反而容易漏掉真正的提示注入、資料外洩或工具越權風險。本文保留原本「資安團隊用 Top 18 工具找出提示注入與法規風險」的搜尋意圖，改用 2026 年仍值得追蹤的 18 個工具／框架／基準，並清楚標示它們的角色。這不是絕對排名，也不代表一次跑完就能證明系統安全。

先給結論：不要安裝 18 個，先選一條測試路徑

若你只測一個模型，先從 DeepTeam、garak 或 PyRIT 選一個；要把測試放進 CI，Promptfoo 或 Inspect AI 通常比較容易版本化；要測 RAG 與工具型代理，加入 Giskard Scan、AgentDojo 或 Inspect 的 agent evals；要檢查輸入輸出邊界，搭配 LLM Guard、NeMo Guardrails 或 Meta 的護欄工具。最後用 OWASP 與 NIST 把發現的問題對應到風險與責任，而不是把工具名稱當成合規證書。

任何紅隊操作都應在自己擁有或明確獲得授權的測試端點執行。本文只提供分類、設定方向與防護流程，不放置可以直接濫用的攻擊 payload。

為什麼要把「2025 年版」更新成 2026 的分類？

這個領域的版本、模型供應商與攻擊面變化很快。原來以年份和「Top 18」為主的標題，容易讓讀者以為每個工具都在做相同的事；但官方文件已經把單回合模型測試、代理環境、評估基準與執行期護欄分成不同層次。選工具時應先問三個問題：要測模型、應用程式還是代理？需要自動產生案例，還是只要固定回歸集？結果要服務工程師、資安團隊還是治理／稽核人員？

18 個工具、框架與基準：先看角色，再看名稱

下表不是人氣排名，而是依用途整理。第 18 項是 OWASP 與 NIST 的雙基線，嚴格說不是可執行程式，但沒有它們，工具結果很難轉成風險決策。

#	工具／框架／基準	主要用途	適合情境與限制
1	DeepTeam	依漏洞類型產生單回合／多回合紅隊測試，整理 RiskAssessment。	適合想把漏洞、攻擊方法與評估結果分開管理的團隊；仍要自己接上模型回呼與人工複核。
2	garak	LLM vulnerability scanner，使用靜態、動態與自適應 probes 檢查多種失效行為。	適合模型／對話端點的廣泛初篩；結果是風險線索，不是完整應用層滲透測試。
3	Microsoft PyRIT	以 Python 編排自動與人工主導的生成式 AI 風險識別工作流。	適合需要多步、可擴充 connector 與人機協作的資安團隊；成本、權限和案例保存要自行治理。
4	Promptfoo redteam	以 YAML 定義 targets、plugins、strategies 與目的，產生、執行、報告紅隊測試。	適合開發流程與 CI；需固定 provider、評估器與測試版本，避免每次產生的案例不同而無法比較。
5	Giskard LLM Scan	由代理描述產生單回合／多回合情境，再以判定模型檢查安全與業務漏洞。	適合 RAG／agent 的領域化測試；需要控制生成與 judge 模型，避免機密內容外送。
6	Inspect AI	可組合 tasks、solvers、scorers 與 logs 的評估框架，並有 AgentDojo、AgentHarm、AgentThreatBench 等 eval。	適合要自己寫評估與長期保存 log 的工程團隊；不是一鍵 LLM 弱掃器。
7	OpenAI Evals	以資料集、eval class、版本與 metrics 建立可重現的模型／系統評估。	適合固定回歸集與模型比較；公開文件提醒仍須依 eval 類型設計 grading，不能直接當成安全掃描器。
8	AgentDojo	動態環境，用來評估代理面對 prompt injection 時的任務效用與防禦。	適合工具型代理與間接注入研究；它是基準環境，不能代替對自家工具權限的實測。
9	JailbreakBench	公開的 jailbreak robustness benchmark，包含威脅模型、資料集、評分與 leaderboard。	適合研究與模型防禦比較；公開資料不應直接複製到正式服務，也要留意 benchmark 與自家產品風險的落差。
10	HarmBench	標準化自動紅隊與 robust refusal 評估框架，可比較 red-teaming methods、模型與防禦。	適合研究、模型安全與拒答能力比較；不等於對企業 RAG、工具和個資流程的完整測試。
11	Meta CyberSecEval	PurpleLlama 的資安基準，涵蓋不安全程式碼、惡意請求、prompt injection、視覺注入與代理能力等測試套件。	適合檢查模型的網路安全能力與濫用傾向；應依版本讀取 README，不能把 benchmark 分數當作產品風險分數。
12	NVIDIA NeMo Evaluator	可擴充、可重現、可規模化的模型與 benchmark 評估平台。	適合集中管理大批模型評估；需要自行定義安全測試資料、scorer 與結果門檻。
13	IBM／LFAI ART	涵蓋 evasion、poisoning、extraction、inference 的機器學習對抗性安全工具箱。	適合傳統 ML、電腦視覺與模型安全研究；不是專為聊天提示注入設計，需搭配 LLM 應用工具。
14	Protect AI LLM Guard	輸入／輸出 scanners，例如 prompt injection、secrets、sensitive data、toxicity、bias 與 factual consistency。	適合放在 API 邊界做藍隊防護；scanner 通過不代表攻擊面已被完整探索。
15	NVIDIA NeMo Guardrails	以可程式化 rails 控制對話主題、輸入、輸出與工具互動。	適合把紅隊發現轉成執行期控制；要用獨立測試驗證護欄的誤擋與漏擋。
16	Meta Llama Guard／Prompt Guard	對輸入／輸出做安全分類與 prompt injection／jailbreak 防護的模型元件。	適合自架或可接受模型服務成本的產品；分類器本身也要做版本、語言與誤判測試。
17	Meta LlamaFirewall／CodeShield	針對代理安全、提示注入與不安全程式碼輸出的護欄與掃描元件。	適合工具型代理與程式碼產生流程；它們是防護配套，不是取代紅隊的攻擊產生器。
18	OWASP LLM Top 10／NIST AI RMF	用來分類提示注入、敏感資訊、過度代理、供應鏈與治理風險，並留下 Map／Measure／Manage 的證據。	適合建立範圍、報告與稽核對照；兩者是基線與方法，不是可執行掃描工具，也不構成法律意見。

怎麼依系統類型挑選？

你的系統	第一組工具	第二組驗證	不要忽略
純模型／聊天 API	DeepTeam、garak 或 PyRIT	HarmBench、JailbreakBench 或固定回歸集	多語言、PII、偏見、拒答品質與成本
RAG 問答	Giskard Scan、Promptfoo	自訂 Inspect task、OWASP 對照	文件注入、來源信任、租戶隔離與引用正確性
工具型代理	AgentDojo、Inspect agent evals、PyRIT	LlamaFirewall 或 NeMo Guardrails	最小權限、工具參數、越權與失敗復原
模型／訓練流程	ART、NeMo Evaluator、CyberSecEval	OpenAI Evals 或自訂 benchmark	資料投毒、模型抽取、版本漂移與供應鏈
小團隊 CI	Promptfoo 或 OpenAI Evals	LLM Guard 做輸入／輸出邊界檢查	固定 seed、版本鎖定、速率與金鑰隔離

一套可重複的 AI 紅隊工作流

1. 寫清楚範圍、授權和停止條件

建立獨立的測試端點、金鑰、資料集與日誌。列出可以測的模型、租戶、工具與時間窗；若出現真實個資、非預期外部副作用、費用超過上限或高風險內容，就停止並升級給負責人。不要把紅隊案例直接送到正式環境。

2. 先做威脅模型，再選工具

把產品能力拆成模型、提示、RAG、工具、權限、輸出與營運監控。對每個邊界寫「資產、攻擊面、預期防護、可接受失敗」，再選能觀察該層的工具。這能避免用模型掃描器去假裝完成代理權限測試。

3. 先小批量基線，再增加變形

第一輪只選少量、與產品最相關的漏洞，確認模型回呼、評估器、成本與資料保存都正常；第二輪才加入語言、格式、上下文、角色與多回合變形。文章不公開具體 payload，實際案例應放在受控測試庫。

4. 把自動結果與人工判讀分開

自動 judge 可以擴大覆蓋，但不能替代領域專家。每筆結果至少保留測試版本、模型／工具版本、漏洞分類、輸入輸出雜湊、評估理由、人工結論與風險等級。對醫療、金融、兒少或資安等場景，人工複核應是必要門檻。

5. 修補後重跑同一批案例

修補可能位於輸入正規化、系統提示、檢索邊界、工具授權、輸出過濾或護欄。把確認過的失敗案例加入版本化回歸集，再測一次原本的成功案例，確保沒有「修好注入卻擋掉正常工作」的回歸。

用設定檔建立最小可行測試

以下片段只展示設定邊界與測試流程，不含可濫用的攻擊內容。實際參數請以目前版本的官方文件為準。

# promptfoo redteam 的概念性設定
redteam:
  purpose: "檢查客服代理的提示注入、PII 與工具越權風險"
  plugins:
    - prompt-injection
    - pii
  strategies:
    - basic
targets:
  - id: staging-agent
    config:
      url: ${STAGING_AGENT_URL}

在 DeepTeam、PyRIT 或 garak 中也應採用相同原則：把測試環境、目標、漏洞範圍、案例數與停止條件寫入版本控制，並限制金鑰的模型與費用權限。不要把隱藏的正式系統提示、客戶資料或長期憑證寫進公開 repository。

如何處理提示注入與法規風險？

「法規風險」不是掃描器可以直接判定的分數。OWASP LLM Top 10 適合用來整理應用層的安全問題；NIST AI RMF 與 Generative AI Profile 則協助把風險、量測、管理與證據放入生命週期。若服務涉及歐盟或其他受監管市場，還要由法務與合規團隊確認適用範圍、資料位置、紀錄保存與通報責任。

觀察到的結果	技術處理	治理證據
提示注入成功	分隔不可信內容、輸入／輸出分類、限制工具權限、加入回歸案例	風險 ID、重現步驟、修補 commit、重測結果
PII 或機密外洩	資料最小化、遮罩、租戶隔離、輸出掃描與存取控管	資料流圖、保留期限、存取紀錄、事件升級人
代理過度授權	後端強制授權、工具 allowlist、人工確認與交易上限	權限矩陣、審批規則、失敗復原與演練紀錄
錯誤／偏見／傷害性輸出	領域資料、拒答政策、人工抽查、分語言與族群切片	評估 rubric、抽樣方法、申訴與修正流程