一個沒有人簽名的決策

昨天最後留了一個伏筆：護欄服務停機三小時，那三小時發生了什麼？

答案通常是「不知道」。因為在很多系統裡，護欄是這樣接的：

try:
    verdict = guardrail.check(prompt)
    if verdict.blocked:
        return refuse()
except Exception:
    pass  # 護欄掛了先不管，別擋到業務
return call_llm(prompt)

那行 pass 就是一個 fail-open 決策。它不是誰決定的，它是某天凌晨兩點為了讓 demo 跑起來而寫下的，然後就一直留在那裡。

今天要把這個決策從程式碼裡拉出來，放到架構圖上，並且說清楚誰該為它簽名。

定義

• fail-open（失效開放）：護欄無法回應時（timeout、5xx、連線失敗、配額用盡），流量直接放行給模型。優先保可用性。
• fail-closed（失效關閉）：護欄無法回應時，流量全部拒絕。優先保安全性。

這是資安領域的老問題——防火牆、WAF、DLP 都有同一個抉擇——但 LLM 護欄有兩個新特性讓它更難：

1. 護欄本身是機率模型，延遲分布比規則引擎寬得多，timeout 會比你想像的頻繁。
2. 護欄通常是外部服務（雲端 API 或另一個推論容器），故障域跟主模型不同。

決策矩陣

不要試圖為整個系統選一邊。依照攔截點與流量類型分開選，才是可維運的做法。

原則只有一條：下游會「動手」的路徑，一律 fail-closed。

fail-closed 不等於「全部拒絕」

很多人反對 fail-closed 是因為想像成「護欄一掛整個系統就停」。實務上 fail-closed 有階梯：

1. 降級到 L1：L2 分類器掛了，退回只跑規則引擎（Day 5 講的三層架構在這裡發揮作用），並把事件標記為「降級模式」。
2. 降級到固定回覆：對外客服直接回「系統維護中，請稍後再試」，不進模型。
3. 降級到人工：轉真人客服或排入佇列。
4. 完全拒絕：只留給工具呼叫這類不可逆路徑。

架構圖上要畫的是這個階梯，不是一個開關。

雲端線怎麼做

Model Armor 是託管服務，它掛不掛不是你能控制的，但你能控制的是：

• timeout 值：設太長，使用者等；設太短，誤判為失效的比率上升。這個值要用真實延遲分布訂，Day 12 實測後再回來調。
• 配額：Model Armor 有每分鐘的請求上限，配額用盡的行為要當成失效來處理，不能當成「跳過」。
• floor setting 的行為：組織層級的 floor setting 是強制套用，如果服務本身出問題，Vertex AI 端的行為是什麼？這點官方文件要仔細讀，Day 13 會實際測。

Model Armor 配額

地端線怎麼做

地端護欄是你自己的容器，故障模式你全知道，但也全部要自己處理：

• 健康檢查與熔斷：sidecar 要有 /healthz，閘道層對它做 circuit breaker——連續 N 次失敗就進降級模式，不要每個請求都等 timeout。
• 降級模式要能被觀察：降級期間的每一筆流量都要打上 guardrail_mode=degraded 的標籤進稽核日誌（Day 29），否則事後無法回答「那三小時發生了什麼」。
• 恢復要驗證：護欄容器重啟後先跑一組 smoke test（Day 6 語料庫裡抽 20 筆）確認判定正常，再解除降級。

誰簽名

這一題的答案不該是資安部門單方面決定的，因為它本質上是可用性與安全性之間的業務取捨。我在客戶那邊的做法：

1. 資安給出上面那張決策矩陣的建議版。
2. 各應用的業務負責人對自己的攔截點簽字確認。
3. 簽完的版本進變更管理，改動要走流程。

聽起來很官僚，但它換來的是：三個月後護欄真的掛了，沒有人需要在凌晨打電話問「現在該怎麼辦」。

本系列的設定

為了讓後面 26 天的實驗結果可以比較，本系列統一採用：

• 雲端線與地端線的輸入端：fail-closed，降級到 L1。
• 輸出端：fail-closed，降級到固定回覆。
• 工具呼叫：fail-closed，完全拒絕。
• 所有降級事件記錄進稽核日誌。

明天預告

Day 5：三層防禦——L1 規則、L2 小模型、L3 LLM-as-judge。為什麼不能只靠一個 guard model？三層各自負責什麼、延遲與成本怎麼分攤、什麼時候該開 L3？

追蹤 AId3fend

更多 AI 資安筆記：aid3fend.com