NVIDIA garak × ATR

garak 是紅隊的標準,ATR 是偵測的標準。一個找到攻擊,另一個把它變成一條版本化、MIT 授權的偵測規則。標準之間互餵,不重造彼此——每個 probe 的來源都留在 author 欄位。

概念

garak 在 LLM 層找攻擊。ATR 在 agent 層防禦(tool calls、skills、MCP)。同一個攻擊 payload,兩個不同的偵測面——一個標準量它能不能突破模型,另一個標準量它能不能在真實 agent 成品上被攔下來。橋接只是一支 Python 腳本:garak 報告進來,ATR 提案出去,結晶 loop 處理其餘的事。一條在這裡寫下的規則,下游每個消費 ATR 的引擎都收得到。

garak (red team)                    ATR (standard)           downstream consumers
─────────────────                    ──────────────           ────────────────────
Probes claude-3.7                    768 rules today          npm: agent-threat-rules
Probes gpt-5                 ──▶     +auto-crystallised       PyPI: pyatr
Probes gemini-2-pro                  from garak evidence      your CI pipeline
Writes report.jsonl                  canary 24h
                                     auto-merge

garak PR status: integration PR #1676 OPEN (under maintainer review, not merged)

一次性設定

寄信到 [email protected] 附上你的組織名稱以取得 partner API key(早期夥伴階段手動發放,無費用,MIT 條款)。
抓 pipe 腳本:它在 ATR repo 裡。 curl -O https://raw.githubusercontent.com/Agent-Threat-Rule/agent-threat-rules/main/scripts/garak-to-tc.py
在環境變數設定 key: export ATR_PARTNER_KEY=…

執行

跑完一次 garak eval session 後:

# Native garak JSONL report
python3 garak-to-tc.py \
    --input ~/.local/share/garak/runs/2026-04-18-claude-3-7/report.jsonl \
    --partner-name  nvidia-airt \
    --target-model  claude-3-7-sonnet \
    --garak-version 0.14.1

# Or ATR-style eval (from scripts/eval-garak.sh in this repo)
python3 garak-to-tc.py \
    --input data/garak-benchmark/garak-eval-report.json \
    --partner-name  nvidia-airt \
    --dry-run   # inspect before submitting

兩種模式

腳本有兩種提交模式。預設(--mode drafter)就是你要的。

drafter(預設)。把每個失敗的 probe POST 到 /api/atr-proposals/from-payload。Server 端跑 tool-use LLM drafter (grep 既有規則做去重、抓 research 做佐證、寫含 3+ conditions / 5+ TP / 5+ TN / 3+ evasion tests 的 YAML),通過 RFC-001 品質閘門,自測自己的 regex,然後立案成 proposal。每次呼叫 30-60s。這個模式產出真正的 ATR 規則。
proposal(legacy)。POST client 端建好的字面草案。快,但 LLM reviewer 通常會以「太窄」(字面指紋 ≠ 偵測規則)退回。只有你上游自己有 YAML 產生步驟才用。

下游會發生什麼

每個唯一的失敗 probe → /api/atr-proposals 下一條 proposal,內嵌完整 garak 來源。
TC 結晶 LLM 讀攻擊 payload + garak metadata,起草一條一般化的偵測 regex。
規則進入 24h canary。每個在野的 ATR 整合 client 收到取樣劑量(~10%)。若任何 client 回報誤判,規則自動隔離。
通過 canary → 安全閘門(432 樣本良性語料 0 FP、test_cases 齊備、每個 PR ≤10 條規則)→ 自動 merge 進 agent-threat-rules main → npm publish 數分鐘內觸發 → 每個下游消費者在下次安裝時升級。
每條產出的規則都帶 author: nvidia-airt (via garak vX.Y.Z) 與 metadata_provenance.garak_probe: <probe-id>。歸屬永久且機器可讀。

什麼算失敗的 probe

腳本在以下任一情況把一個 garak attempt 當成規則候選:

至少一個 garak detector 回傳分數高於 0.5(目標模型中招)。
輸入是 ATR 風格的 eval report,且該 prompt 出現在 missed_samples — garak 標記它為惡意,而 ATR 尚無對應 pattern (最高訊號的候選)。

速率限制與安全

每次 POST 之間預設 100ms 延遲,跑完約一分鐘。兩個數字都公開:在 garak 公開 in-the-wild jailbreak 集(650 筆)上,recall 是 98.0%;在完整 garak 語料 (3,475 筆,涵蓋全部 probe 家族)上,recall 是 38.5%。落差是刻意的——regex 偵測層不去打某些 probe 家族(例如純語意越獄),硬塞只會換來脆弱簽章與誤報。列出較低的那個數字,是因為一個標準的可信度,取決於它願不願意公開自己最差的數字。
patternHash 是 prompt 的 sha256,所以對同一份 report 重跑是冪等的 — TC 辨識重複提交,只 bump 一個確認計數,絕不建立重複規則。
所有流量都用你的 partner key 認證。Key 外洩?寄信,我們撤銷並重發。
每個提交的 proposal 在進入 canary 前,都可透過 TC admin dashboard 審查與退回。