防護該放在哪裡——外掛 classifier 與模型內建防護

[[我也希望安全第一]]｜第 8／30 天

只是請它讀一篇資安文章，模型卻被換掉了

Fable 5 上線後，資安研究者很快發現一些奇怪情況：閱讀部落格、做 code review，甚至要求「寫得更安全」都可能觸發 guardrail。系統會暫停原本的 Fable 對話，顯示請求被標記為 cybersecurity 或 biology，再回退到能力較低的模型。

對產品團隊來說，這種架構很好理解。最強模型具備更高風險能力，就在入口前放一個分類器；請求落入敏感領域時拒絕、降級，或交給通過身分審核的使用者。安全規則可以獨立更新，不必每次重新訓練模型。

對使用者來說，感受完全不同。他沒有要求攻擊任何系統，只因為出現幾個資安詞彙，手上的工具就突然變笨了。

Guardrail 擋住的不只是風險，也可能是人買這個模型的理由。

外掛 classifier 像入口警衛

把簡化後的流程畫出來，外掛防護會是這樣：

request
   ↓
input classifier ── low risk ─→ frontier model ─→ output classifier ─→ response
   │                                  │
   ├─ uncertain ─→ fallback model     └─ flagged ─→ redact／refuse
   └─ high risk ─→ refuse／verified-access workflow

這個做法的優點很務實：

• classifier、policy 和主模型可以分開版本化。
• 高風險規則能快速修改，不必等下一次模型訓練。
• 每次攔截、降級和誤判都能留下相對清楚的 telemetry。
• 同一套入口政策可以套在多個模型上。

代價也直接。分類器通常只看有限的文字和 metadata，很容易把領域和意圖混在一起。「分析惡意程式」可能是在寫攻擊，也可能是 incident response。門口先擋掉後，主模型根本沒有機會理解完整脈絡。

Fable 5.1 後來把降低 false positive 當成產品更新的一部分。Anthropic 另一次官方更新表示，調整 biology safeguards 後，相關 fallback 在自家測試中減少約 85%。這不是旁枝末節，而是 guardrail 對正常工作造成的摩擦已經大到必須被當成產品指標。

把安全行為訓進模型，判斷可以更貼近脈絡

另一條路是讓主模型在 post-training 階段學會政策，把風險判斷和回答放進同一次推論：

request + policy context
          ↓
policy-trained model
   ├─ safe request      → helpful answer
   ├─ dual-use request  → bounded assistance
   └─ harmful request   → refuse／safe completion
          ↓
system policy + tool authorization + monitoring

這種模型有機會理解「同樣是漏洞程式碼，這次是在修補還是在部署攻擊」，也能用較自然的方式提供安全範圍內的協助。使用者不必因為碰到一個敏感關鍵字，就整段對話被切到另一個模型。

更新速度是它的弱點。模型學到的政策不像一條規則可以立刻改掉；行為會受 prompt、語言、上下文和新攻擊影響，也不容易精確說明是哪條 policy 造成拒答。

文章標題把兩條路寫成「外掛 vs 內建」，實際產品不會這麼乾淨。GPT-5.6 的官方 system card 描述的是 layered safeguards：模型訓練、監控、產品限制和分級發布一起工作，並沒有公開足夠細節讓外界把每一次拒答精確歸因到某個內部元件。因此這裡比較的是設計位置，不是宣稱 GPT-5.6 只靠模型內建防護。

不要只報一個 safety score

如果要比較兩套架構，我會先要求以下幾個數字分開看：

單獨把 attack success 壓低很容易：全部拒絕就好。只追 task success 也很容易：把 guardrail 關掉。真正的發布決策是在兩邊同時設門檻，而且高傷害切片不能被平均值蓋掉。

例如資安產品的正常請求成功率從 92% 掉到 61%，整體安全分數仍上升，對資安團隊來說也不能算成功。它可能會促使用戶換模型、關閉防護，或把整段工作搬到無法監控的環境。

上線以前，先用 shadow mode 看它想擋誰

一個新 classifier 不一定要第一天就拒絕請求。可以先在 shadow mode 裡只記錄 decision，不改變使用者看到的結果：

production request
      ├─→ current safeguard → actual response
      └─→ candidate classifier → log only

團隊再抽樣檢查候選分類器準備攔下哪些正常工作，尤其是少數語言、公司內部術語和 dual-use 任務。累積足夠資料後，先對少量帳號 canary；每次 policy、classifier、主模型和 fallback model 都綁定版本，才知道誤判是從哪次更新開始。

對高風險領域，還可以加入 verified access。但身分驗證不能替代意圖判斷：有公司信箱的人仍可能濫用，沒有漂亮職稱的人也可能在修真正的漏洞。它只是另一個訊號。

最後一列很容易被忽略。模型防護和 classifier 都是機率性元件；付款 API 的授權不該因為前面某一層判定「大概安全」就放行。

下一篇會面對這套設計的代價。每多一層分類、確認和權限限制，任務就可能更慢、更貴、更常卡住；每拿掉一層，agent 又多一條可以走的路。問題不會是選出一套完全不漏的 guardrail，而是哪些能力值得開、破壞半徑要壓到多小。

本篇的鎖

• 鎖是什麼：模型外的 classifier／policy，以及透過訓練形成的模型內安全行為。
• 想攔什麼：有害請求、越獄與高風險 dual-use 工作，同時保留合法用途。
• 破口在哪：外掛層容易把領域當意圖，模型內防護又較難快速更新與解釋；兩者都會有 false positive 和 false negative。
• 怎麼補：分開追 attack success、誤拒與 task success；新防護先跑 shadow mode 和分切片評估，真正的高風險動作仍交給外部授權。

參考與來源

• 主要案例原始報導：TechCrunch（2026-06-10）
• 後續修正：Anthropic：Improving Fable 5 Safeguards
• Fable 5.1 原始報導：TechCrunch（2026-09-01）
• 對照：GPT-5.6 System Card
• GPT-5.6 原始報導：TechCrunch（2026-07-09）